AZ-104 sample questions — 25 answered and explained

Dynamic membership rules combine attribute expressions with logical operators, and the operator choice decides who matches.

With one department value per user, either-or membership is an -or of two equality checks on department. Joining them with -and requires one value to equal two strings, which matches nobody. Swapping one condition to jobTitle tests the wrong attribute. Using -ne with -or is true for every user, since nobody can equal both values. The -in operator with a list would also work, but it is not offered here.

1. Translate 'Sales or Marketing' into two equality expressions on department.
2. Join them with -or because a user only needs to satisfy one.
3. Check the edge cases: -and matches none, -ne with -or matches all.

Exam tip: Either-or membership on one attribute is -or of -eq expressions (or -in); -and on one single-valued attribute matches nobody.

Each bulk operation uses a fixed CSV template with its own required columns.

The Bulk invite template requires the email address to invite and the redirection URL the guest lands on after redemption; columns such as the invitation message and whether to send it are optional. An initial password belongs to the Bulk create template for members. A guest's UPN is generated from the invited address, and usage location is a licensing property. The tempting near-miss pairs the right email column with an optional column.

1. Recognize Bulk invite creates B2B guests, not members.
2. Recall its two required columns: email address to invite and redirection URL.
3. Treat the message text and send flag as optional columns.

Exam tip: A Bulk invite row needs the invitee's email address and a redirection URL.

Invitation domain allow and deny lists live in External collaboration settings; cross-tenant access settings work per Microsoft Entra organization.

The requirement is a domain allowlist for invitations that also covers partners who have no Microsoft Entra tenant. External collaboration settings provide collaboration restrictions that allow invitations only to specified domains, which fits. Cross-tenant access settings are configured per Microsoft Entra organization, so they can't express the partners that have no tenant. Conditional Access acts at sign-in, not at invitation. Guest user access restrictions govern what guests can read in the directory.

1. Note the control point is the invitation, filtered by domain.
2. Note some partners have no Microsoft Entra tenant, which rules out per-organization settings.
3. Configure 'Allow invitations only to the specified domains' in External collaboration settings.

Exam tip: Restrict which domains can be invited with the allow/deny list in External collaboration settings.

In a dynamic group, membership is computed from the rule; members can't be added or removed manually.

A group with a membership rule is dynamic, and Microsoft Entra ID doesn't let anyone add or remove its members by hand. To take the contractor out, correct his department attribute, or edit the rule (for example, add a condition that excludes him), and let it reprocess. A synchronized group is also read-only in the cloud, but its membership is managed in on-premises AD and it has no cloud rule. A role-assignable group limits who can manage members, but role-assignable groups can't be dynamic. A missing admin role is ruled out because you edit other groups.

1. Spot the membership rule: the group is dynamic.
2. Recall that dynamic group members can't be added or removed manually.
3. Rule out the other read-only causes: synced groups have no cloud rule, and role-assignable groups can't be dynamic.
4. Change the user's attribute or the rule, then wait for processing.

Exam tip: To get someone out of a dynamic group, change their attribute or the rule, not the member list.

Only security groups can contain devices and use Dynamic Device rules; Microsoft 365 groups are user-only.

Two choices must line up: the group type that can hold devices (security) and the membership type that evaluates device objects (Dynamic Device). Microsoft 365 groups contain users only, which rules out both of their combinations. A security group set to Dynamic User is the near-miss: right group type, but the rule evaluates users, and user and device attributes can't be mixed in one rule.

1. The members are devices, so the group must be a security group.
2. Device attributes need the Dynamic Device membership type.
3. Write a rule such as device.deviceOSType -eq "Windows".

Exam tip: Dynamic device membership requires a security group set to Dynamic Device.

For accounts synced from on-premises AD, password writeback pushes cloud SSPR changes back to Active Directory.

The symptom is a cloud reset that never reaches AD, which is the gap password writeback fills. Password hash synchronization is the tempting answer because it is also a password feature of Microsoft Entra Connect, but it runs the other way, from AD to the cloud. Seamless SSO handles sign-in convenience, and group-based licensing assigns products. Writeback also needs Microsoft Entra ID P1 (or Microsoft 365 Business Premium).

1. Note the accounts are synchronized and the cloud reset doesn't reach AD.
2. Recall that hash sync flows AD to cloud only.
3. Enable password writeback (Microsoft Entra Connect or Cloud Sync) and turn it on in Password reset > On-premises integration.

Exam tip: SSPR for synced users needs password writeback; password hash sync only flows the other way.

Subnet-only access to a storage account can be built two ways: a service endpoint plus a virtual network rule on the storage firewall (public endpoint, no DNS change), or a private endpoint (private IP, needs private DNS).

Both the service-endpoint design and the private endpoint can restrict access to the subnet. The constraints decide: no DNS changes and the fewest new resources rule out the private endpoint, which relies on a private DNS zone and a new network interface. A service endpoint without the virtual network rule and Deny default leaves the account open. IP rules cannot hold private ranges, and same-region traffic is not matched by IP rules anyway.

1. List the workable designs: service endpoint plus virtual network rule, or private endpoint.
2. Apply the DNS constraint: a private endpoint needs private DNS, so it is out.
3. Check the remaining service endpoint option actually restricts access (Deny default plus virtual network rule).
4. Reject the IP rule because the firewall accepts only public ranges.

Exam tip: Subnet-only access without DNS changes = service endpoint + virtual network rule; private endpoints are the answer when traffic must use a private IP.

A private endpoint projects a storage account into a virtual network with a private IP address. Anything that can route to that VNet privately, including on-premises networks over VPN or ExpressRoute private peering, can then use the account without its public endpoint.

With public network access disabled, only private endpoints can carry traffic to the account. Service endpoints and IP rules act on the public endpoint, and service endpoints do not extend to on-premises sources. The privatelink DNS zone is part of a private endpoint design, but on its own it has nothing to resolve to; it complements the endpoint rather than replacing it. On-premises DNS must then resolve the account name to the private endpoint IP, typically by forwarding to Azure private DNS.

1. Note that the public endpoint is disabled.
2. Recall which features act on the public endpoint: IP rules and virtual network rules with service endpoints.
3. Recall that a privatelink DNS zone only resolves to a private endpoint that already exists.
4. Choose the private endpoint, reachable over private peering.

Exam tip: Public endpoint disabled or traffic must stay private from on-premises = private endpoint.

Portal data browsing (listing containers and blobs) is a data-plane request sent from the user's browser, so the storage firewall evaluates the user's public IP. A firewall denial surfaces in the portal as an authorization error.

The firewall now admits only the production subnet, so requests from the head office's public IP are rejected; the portal reports this as "not authorized", which tempts candidates toward RBAC changes. Adding an IP network rule for the office range fixes it while keeping the restriction. Opening all networks drops the restriction, the trusted services exception covers platform services, not browsers, and roles cannot override a network denial.

1. Notice the change that preceded the error: the firewall default moved to Deny.
2. Recall that portal data browsing originates from the user's browser IP.
3. Recognise that a network denial appears as an authorization error.
4. Allow the office's public range with an IP network rule.

Exam tip: A storage firewall blocks portal data browsing too; allow the admins' public IP range rather than reaching for RBAC.

Every SAS carries its own constraints as signed query parameters: permissions (sp), start and expiry (st, se), signed resource (sr), allowed protocol (spr) and allowed IP address or range (sip).

The sip parameter binds the token to a source address or range, so the vendor's token fails from anywhere else. spr, sr and se are real constraints on protocol, scope and time, which makes them plausible but not location controls. A storage firewall rule would also restrict by address, but it applies to every client of the account, not to one token.

1. Classify the requirement: restriction by request source address.
2. Map each parameter: spr protocol, sr scope, se expiry, sip source IP.
3. Choose sip with the vendor's range.

Exam tip: sip pins a SAS to a source IP or range; spr pins the protocol; se sets the expiry.

Storage firewall exceptions let listed Azure platform services (such as Azure Monitor and Azure Backup) reach an account whose network access is restricted, without opening it to other networks.

Two facts combine here. First, IP network rules have no effect on requests that originate in the same Azure region as the storage account, so adding service IP ranges would not restore delivery. Second, Azure Monitor is a trusted Microsoft service, so the firewall exception admits it while the deny-by-default posture stays in place. Opening all networks breaks the requirement, and RBAC cannot override a network denial.

1. Identify the blocked caller: Azure Monitor writing logs from the same region.
2. Recall that IP rules do not apply to same-region Azure traffic.
3. Recall that Azure Monitor is on the trusted services list.
4. Enable the trusted services exception and keep the Deny default.

Exam tip: Same-region Azure services cannot be admitted with IP rules; use the trusted services exception (or virtual network or resource instance rules).

Outputs are the deployment's return values. A Bicep output can reference a deployed resource's runtime properties (for example publicIp.properties.dnsSettings.fqdn), and pipelines read them from the deployment result.

Only an output both reads the value Azure generated and hands it back to the caller. A variable or a default parameter value is computed or guessed before deployment and is never returned. A tag does not exist as a deployment result and could not be set from a value that does not yet exist. The pipeline then reads the output with 'az deployment group show --query properties.outputs'.

1. Note the direction of data: from the deployment back to the caller.
2. Recall that only outputs are returned in the deployment result.
3. Reference the resource symbolically so the output reads its runtime property.

Exam tip: Values flow in through parameters and out through outputs.

A Bicep module is a Bicep file deployed from another Bicep file. It takes parameters and returns outputs, so a shared definition is written once and reused by many deployments, from a local path, a Bicep registry or a template spec.

Reuse across teams with team-specific values is exactly what modules do. Copy loops repeat resources within a single file, outputs return values rather than definitions, and deployment scripts run imperative code instead of providing a reusable declarative unit.

1. Identify the need: one definition, many consuming files, different inputs.
2. Match it to modules: a callable file with parameters and outputs.
3. Publish the module to a registry or template spec if teams deploy from separate repositories.

Exam tip: Reuse a definition across Bicep files with modules; repeat it inside one file with loops.

The Bicep CLI converts in both directions: 'build' compiles Bicep to ARM JSON, and 'decompile' translates ARM JSON into Bicep. Decompilation is best-effort, so the output should be reviewed and cleaned up.

'az bicep decompile' is the documented JSON-to-Bicep conversion. Build is the reverse operation, generate-params produces a parameter file, and publish uploads a module to a registry. After decompiling, review the warnings, rebuild the file and run what-if before trusting it.

1. Run 'az bicep decompile --file azuredeploy.json' to generate azuredeploy.bicep.
2. Review the generated Bicep for warnings and awkward constructs, because decompilation is best-effort.
3. Validate the result with a what-if deployment before replacing the JSON template.

Exam tip: Decompile means JSON to Bicep; build means Bicep to JSON.

There are two export paths. Exporting from a resource group or resource generates a template from the current state of the resources (a snapshot that includes manual changes). Saving from deployment history returns the exact template that was used, which reflects only what that deployment set.

The deciding detail is the manual changes after the original deployment. Only an export from the resource group captures current state. Both history options (portal Deployments and az deployment group export) return the original template, so they miss the later changes. What-if never produces a template. Exported templates usually need cleanup and added parameters before reuse.

1. Notice that the requirement is the current state, not the original deployment.
2. Recall that history exports return the template as it was deployed.
3. Export from the resource group (or az group export) to capture the live configuration, then parameterise it.

Exam tip: Current state: export from the resource group. Original intent: save from deployment history.

A template spec stores an ARM template or Bicep file as an Azure resource (Microsoft.Resources/templateSpecs) with named versions. Access is governed by Azure RBAC, and users deploy it by resource ID from the portal, CLI, PowerShell or as a module reference.

Template specs meet every requirement: versioned, RBAC-controlled, and hosted by Azure without storage accounts or SAS tokens. Blob storage with SAS is the classic linked-template approach that the constraint excludes. A Git repository is versioned but governed by Azure DevOps permissions. A deployIfNotExists policy deploys only to remediate compliance, not as a shared template catalogue.

1. List the requirements: versions, Azure RBAC, no storage or SAS dependency.
2. Eliminate storage-based sharing because of the SAS constraint.
3. Choose template specs, which are versioned Azure resources secured with RBAC.

Exam tip: Sharing templates with Azure RBAC and versions: template specs.

Azure PowerShell has one deployment cmdlet per scope: New-AzResourceGroupDeployment (resource group), New-AzDeployment (subscription), New-AzManagementGroupDeployment and New-AzTenantDeployment.

Deploying into a resource group is New-AzResourceGroupDeployment. Test-AzResourceGroupDeployment is the tempting near-twin, but it only validates. New-AzDeployment targets the subscription scope, and New-AzTemplateSpec stores the template for later deployment rather than deploying it.

1. Identify the scope: an existing resource group.
2. Pick the New- cmdlet for that scope, not the Test- validation cmdlet.
3. Supply -ResourceGroupName and -TemplateFile (plus -TemplateParameterFile if needed).

Exam tip: Resource group deployments in PowerShell: New-AzResourceGroupDeployment.

"Allow forwarded traffic" on a peering controls whether the VNet accepts traffic that did not originate in the directly peered VNet but was relayed through it, such as spoke-to-spoke packets an NVA or Azure Firewall in the hub forwards.

The capture proves the routing and the appliance work; the packets are dropped on entry to Spoke2 because their source is Spoke1, not the hub. Enabling "Allow forwarded traffic" on Spoke2's peering to the hub admits them (Spoke1's peering needs the same for return traffic). The gateway options govern gateway sharing, not relayed traffic. IP forwarding belongs on the appliance, where it is already enabled.

1. Trace the path: Spoke1, UDR, hub NVA, Spoke2.
2. Note where packets stop: after leaving the appliance, before reaching Spoke2.
3. Notice the source address belongs to Spoke1, a network not directly peered with Spoke2.
4. Enable "Allow forwarded traffic" on the receiving spoke's peering to the hub (and on the other spoke for replies).

Exam tip: Relayed spoke-to-spoke traffic needs "Allow forwarded traffic" on the peering of the VNet that receives it.

Public IPs are Standard (v1 or v2) or the retired Basic SKU (retired 30 September 2025). Standard IPs are always static and secure by default, and can be zonal or zone-redundant; a zonal IP shares fate with its zone. Standard v2 IPs are always zone-redundant but currently work only with the Standard v2 NAT gateway.

Only a Standard zone-redundant IP meets both requirements. A zonal Standard IP fails when its zone fails. Standard v2 looks ideal on paper because it is zone-redundant, but it cannot be zonal at all and currently cannot be attached to a VM NIC. Every Standard IP is static, so the address also stays the same through stop and deallocate.

1. Rule out the retired Basic SKU: Standard IPs (v1 and v2) are the only choices and are always static.
2. Match the zone requirement: zone-redundant survives a zone failure; zonal does not.
3. Check the target resource: a VM NIC takes a Standard (v1) IP, while Standard v2 currently works only with the v2 NAT gateway and is zone-redundant only.

Exam tip: For a VM: Standard SKU, static, zone-redundant; zonal shares its zone's fate and Standard v2 is for the v2 NAT gateway.

A subnet's address range can be changed only when no resources are deployed in it. Growing a busy subnet means moving or deleting what is attached, or creating a new larger subnet and migrating to it.

The 40 NICs are the blocker, so the subnet must be emptied first. Peering sync is about VNet address-space changes, not subnet edits within the space. NSG and route table associations and delegation settings do not block the change. In practice, creating a new larger subnet and migrating is often less disruptive than emptying the old one.

1. Confirm the new range fits the VNet space and overlaps no other subnet (it does).
2. Check what is deployed in the subnet: 40 NICs.
3. Move or delete them, change the range, then redeploy, or migrate to a new larger subnet instead.
4. Size subnets with growth headroom to avoid this.

Exam tip: You can change a subnet's address range only when the subnet is empty.

Subnet delegation designates a subnet for a specific Azure PaaS service (App Service regional VNet integration, Azure Container Instances, Azure NetApp Files, and others). The delegated service gains permission to deploy service-specific resources into the subnet, and Azure enforces the dedication.

Regional VNet integration explicitly requires a subnet delegated to Microsoft.Web/serverFarms. Service endpoints solve a different problem (identifying subnet traffic to PaaS firewalls). ASGs group NICs for NSG rules and cannot be applied to subnets. The UDR distractor cites a system-generated next hop type that administrators cannot create.

1. Create or choose an empty subnet with room for scale-out, because each app instance uses an address from it.
2. On the subnet, set Delegation to Microsoft.Web/serverFarms.
3. Configure VNet integration on the App Service app and select that delegated subnet.
4. Note that a delegated subnet is reserved: other resource types may be blocked from deploying into it.

Exam tip: Subnet delegation dedicates a subnet to a PaaS service — App Service regional VNet integration needs Microsoft.Web/serverFarms.

Azure manages private IP addresses and delivers them to the guest by DHCP. To pin an address you set the NIC's IP configuration to static in Azure; editing the address inside the operating system desynchronises the guest from the platform and usually breaks connectivity.

A static assignment on the NIC's IP configuration reserves the address in Azure and keeps the guest on DHCP, the supported pattern. The public-IP option fixes the wrong address. A DNS record names an address but does not assign it. Azure never reads addresses from the guest OS, so restarting keeps the broken state.

1. Revert the in-guest change so the adapter obtains its address automatically.
2. Open the VM's network interface, then IP configurations, then the ipconfig.
3. Change private IP assignment from Dynamic to Static and enter 10.0.1.10 (unused and inside the subnet's usable range).
4. Save; the VM keeps receiving 10.0.1.10 through Azure DHCP.

Exam tip: Pin private IPs on the Azure NIC's IP configuration, never inside the guest OS.

Log Analytics is the query experience for Azure Monitor Logs. KQL queries filter, correlate, and summarize records across workspace tables, supporting operators for time filtering and aggregation such as summarize count() by Computer.

The Azure Monitor Agent delivers guest event logs to a Log Analytics workspace, and filtering by level, restricting to 24 hours and summarizing by computer is a standard KQL query. Metrics explorer reads only metrics, the activity log has no guest OS events, and Run command works per VM rather than across the fleet.

1. Open the Log Analytics workspace and select Logs to open the query editor.
2. Write a KQL query against the event table filtering on error level and a 24-hour time range.
3. Add a summarize count() by Computer clause to group results per machine and run the query.

Exam tip: Anything stored in a Log Analytics workspace is answered with a KQL query in the Logs experience.

Metric alert rules support static thresholds (a fixed value you choose) and dynamic thresholds (machine-learning boundaries derived from the metric's historical behavior, including seasonality). Dynamic thresholds suit metrics with regular patterns that a single number cannot capture.

Traffic with strong hourly and weekly seasonality is the use case for dynamic thresholds: the model learns the expected band for each period and flags deviations, so it needs the least ongoing tuning. A static metric threshold and a log search alert with a fixed threshold both work technically but share the single-number problem the scenario describes; an activity log alert watches management operations, not metric values.

1. Create a new alert rule scoped to the web app and select the Requests metric as the signal.
2. In the condition, set the threshold type to Dynamic and choose the sensitivity (low, medium, or high).
3. Set the evaluation frequency and lookback window, attach an action group, assign a severity, and create the rule.

Exam tip: Choose dynamic thresholds for metrics with seasonal patterns; static thresholds fit metrics with a known fixed acceptable limit.

Action groups decouple what fires (the alert rule and its condition) from who is told and what runs (notifications like email, SMS, push, and voice, plus actions like webhooks, Azure Functions, Logic Apps, and Automation runbooks). Many alert rules can reference one action group.

A single action group holding the email, SMS, and webhook entries is the reusable unit the scenario describes; each of the ten alert rules simply references it, and future contact changes happen in one place. Ten duplicate groups multiply maintenance, an alert processing rule can attach an existing action group but cannot itself define the notification targets, and alert rules cannot hold email, SMS or webhook targets directly - their actions are references to action groups.

1. In Azure Monitor, open Alerts and create a new action group in the appropriate resource group.
2. Add notification entries for the team's email and SMS, and an action entry for the remediation webhook URI.
3. Edit each of the ten alert rules (or create new ones) and select this action group under Actions.

Exam tip: Define notifications and automated actions once in an action group and reference it from every alert rule that needs them.