Free AZ-104 practice test

The two most common causes of group-based licensing errors are: (1) insufficient license seats — if the tenant has fewer available licenses than group members, some users will receive an error; and (2) missing usage location — Microsoft requires that a user's 'Usage location' attribute be set before a license with location-restricted services (like Microsoft 365 E5) can be assigned. Guest users CAN receive group-based licenses if usage location is set and licenses are available. Both dynamic and assigned membership groups support group-based licensing. Conflicting service plans can cause errors in some scenarios but are less common than the two selected; the question asks for the MOST common. MFA has no bearing on license assignment.

Creating a custom RBAC role that includes only the required AKS actions (e.g., Microsoft.ContainerService/*) and assigning it at the resource group scope adheres precisely to least privilege — the user can only perform the specific operations needed and only within the targeted resource group. Option A is incorrect because Contributor grants broad permissions over ALL resource types in the resource group, violating least privilege. Option D is incorrect because Owner at subscription scope is far too broad, and deny assignments cannot be created by regular administrators — they are only set by Azure Blueprints/managed applications. Option C is incorrect because assigning even a scoped built-in AKS role at the subscription level grants access across all resource groups in the subscription, unnecessarily broadening scope.

When group-based licensing is configured, Microsoft Entra ID attempts to assign a license to every member. If there are not enough available licenses in the tenant, some users will be left unassigned and the portal reports a licensing error for those users. This is the most common real-world cause of partial assignment failures. Option A is incorrect because guest users CAN receive group-based licenses. Option C is incorrect because group-based licensing supports both security groups AND Microsoft 365 groups. Option B is incorrect because the License Administrator role is sufficient to assign licenses, and failures are visible in the portal rather than silent.

Azure Policy evaluates all applicable policies at every scope in the hierarchy. The 'Deny' effect is more restrictive than 'Audit'. When policies with different effects apply, Azure Policy does NOT override higher-scoped policies with lower-scoped ones — the Deny at the management group blocks the deployment regardless of the Audit policy at the subscription. The subscription-level Audit policy does not cancel or override the parent Deny. Option A is incorrect because lower-scope assignments never override higher-scope assignments with a more restrictive effect. Option C is incorrect in its framing; while both policies do evaluate, the end result is a denial, not an audit followed by a denial as separate sequential steps. Option D is incorrect because policy exemptions are explicit objects and are not automatically granted to subscription owners.

The 'Modify' effect is specifically designed to add, update, or remove tags (and other properties) on resources, and it supports remediation tasks to bring existing non-compliant resources into compliance. — Option B is incorrect because the 'Append' effect can add tags to new resources at creation time but does NOT support remediation tasks for existing resources; it cannot modify already-deployed resources. — Option C is incorrect because 'DeployIfNotExists' is used to deploy linked or dependent resources (like diagnostics settings), not to modify properties of the resource itself, and is more complex and inappropriate for simple tag enforcement. — Option D is incorrect because the 'Deny' effect only prevents future non-compliant deployments; it does not remediate existing resources, and a remediation task on a Deny policy would not delete resources.

Blob versioning automatically creates and retains a new version of a blob each time it is overwritten or deleted. This requires no custom scripting; Azure manages version creation transparently. An administrator can restore a previous version by copying it over the current version. Blob snapshots are read-only copies of a blob at a specific moment, but they must be created manually or via a lifecycle policy that only moves/deletes them — snapshots are not created automatically on every overwrite. Container soft delete retains deleted containers, not overwritten blobs. Point-in-time restore for block blobs allows restoration of a container or account to a prior state but requires blob versioning or change feed to be enabled first — it is a higher-level recovery mechanism, not the feature that 'automatically captures overwrites'.

Blobs in the archive tier are stored offline and cannot be read directly. They must first be rehydrated (moved or copied) to an online tier (hot or cool). Standard-priority rehydration can take up to 15 hours, while high-priority rehydration typically completes in under 1 hour for objects under 10 GB. Copying to a new storage account is not required; rehydration can be done within the same account. Archived blobs cannot be read with any type of SAS token because the data is offline — the SAS grants permission but the data is not accessible until rehydrated. Deleting and re-uploading from a backup is unnecessary and destructive if a backup is not readily available.

Azure Blob Storage supports container soft delete (separate from blob soft delete). When container soft delete is enabled, a deleted container and all its contents are retained for the configured retention period and can be restored using the 'Undelete container' API/portal operation. The question states soft delete is enabled, which covers container soft delete as well. The container is not permanently deleted immediately — this would only be true if soft delete were not enabled. Blob versioning does not protect against container deletion; it preserves historical versions of individual blobs but does not automatically restore a deleted container. The fourth option describes the behavior of blob soft delete without container soft delete — if only blob-level soft delete were configured (not container soft delete), blobs would be retained but the container itself would be gone; however, in modern storage accounts, enabling soft delete typically covers both blobs and containers, and the question implies soft delete is enabled, so the container is also soft-deleted and recoverable.

A service SAS linked to a stored access policy inherits the policy's permissions and expiry. To immediately revoke that SAS, you simply delete or modify the stored access policy — this invalidates all SAS tokens linked to it without rotating account keys. This satisfies both requirements: revocability and no key rotation. An account SAS with a short expiry does not allow on-demand revocation; you must wait for it to expire. A user delegation SAS is revoked by revoking the Azure AD principal's permissions or the delegation key, not through a stored access policy — it also requires Azure AD integration which the question does not specify. Rotating key1 would revoke service SAS tokens signed with key1, but the question explicitly forbids rotating keys. Embedding a SAS with a fixed expiry in a connection string also provides no on-demand revocation path.

ACI container local filesystems are ephemeral and destroyed on restart. Mounting an Azure Files share as a volume provides persistent storage that survives container group restarts and can be shared across containers, which is the supported and recommended approach for ACI data persistence. — Increasing CPU and memory affects compute resources but has no effect on storage persistence. — Setting the restart policy to 'Always' ensures the container restarts on failure but does not change the fact that the local filesystem is wiped on each restart — data still won't persist. — Using a multi-container group to copy files between containers does not help because all containers in the group share the same ephemeral lifecycle; data is still lost when the group restarts.

Premium SSD v1 (P30) provides 5,000 IOPS at a predictable, relatively low cost per GB for a 1 TB disk and is the most cost-effective option for high-IOPS workloads among the standard managed disk tiers. Option D (Standard HDD) offers very low IOPS (up to 500) making it cost-inefficient for IOPS-intensive workloads. Option C (Standard SSD E30) offers up to 500 IOPS — better than HDD for reliability but still significantly lower IOPS than Premium SSD at a not-proportionally-lower price for this use case. Option B (Ultra Disk) provides extremely high IOPS but at a much higher cost, and when analyzing IOPS per dollar for a standard 1 TB 5000-IOPS configuration, Premium SSD v1 P30 (which already delivers 5000 IOPS) is more cost-efficient than Ultra Disk for the same IOPS level.

The Custom Script Extension downloads and executes scripts (PowerShell, Bash, etc.) on a VM after deployment, making it the standard mechanism to run post-provisioning scripts directly from an ARM template without additional orchestration tools. — Azure Monitor Agent extension collects telemetry (logs, metrics) and sends it to a Log Analytics workspace; it does not execute arbitrary scripts. — The DSC extension applies PowerShell Desired State Configuration documents to enforce a configuration state, which is declarative and requires a MOF/configuration document — not the same as running an imperative script. — Azure Policy Guest Configuration audits or enforces OS-level settings through policy assignments, not through on-demand script execution at deployment time.

The 'JsonADDomainExtension' (Microsoft.Compute/virtualMachines/extensions with type 'JsonADDomainExtension') is the purpose-built VM extension for joining Azure VMs to an Active Directory domain. It runs automatically after VM provisioning as part of the ARM deployment. Referencing the domain join password from Azure Key Vault using a Key Vault parameter reference in the parameters file means the password is retrieved at deployment time from Key Vault and never stored in plain text in any template or parameter file. Together, these two approaches satisfy both requirements. The Custom Script Extension running Add-Computer can work functionally, but it is a less reliable and more complex approach than the purpose-built JsonADDomainExtension, and it doesn't address the credential security requirement on its own. Passing the password as a secureString parameter with a default value is incorrect because: (a) default values in templates are visible in template source, and (b) secureString without Key Vault reference still requires the value to be passed at deploy time, risking exposure in deployment history. Azure AD DS is a different service from on-premises AD and would not join the VM to the on-premises domain.

ACR Tasks supports base image update triggers, which automatically detect when a base image is updated in the registry and trigger a rebuild of any dependent images that reference that base image. This is exactly the feature designed for this scenario. Geo-replication replicates images across Azure regions for lower-latency pulls — it has no automated build trigger capability. Content trust with Notary v2 is about image signing and verification for supply chain security — it does not trigger builds. An ACR webhook can notify external systems when an image is pushed, but a webhook alone cannot detect base image relationships or trigger dependent image builds — it would require significant custom pipeline logic that is not built into the webhook feature itself.

To allow spoke VNets to use the hub's VPN Gateway (gateway transit), two peering settings must be configured: (1) 'Allow gateway transit' must be enabled on the hub-to-spoke peering (hub side), which allows the hub to share its gateway with spokes, and (2) 'Use remote gateway' must be enabled on the spoke-to-hub peering (spoke side), which tells the spoke to use the remote (hub) gateway for routing. Both settings together enable transitive connectivity to on-premises. Deploying a separate VPN Gateway in each spoke (option C) is costly, defeats the hub-spoke purpose, and is not required. VNet-to-VNet connectivity (option D) is a different connectivity model and doesn't solve gateway transit. A UDR pointing to the VPN Gateway's public IP (option E) is incorrect — the next hop for a UDR to use a VPN Gateway would reference the gateway's private IP or use 'Virtual Network Gateway' next hop type, and even then, gateway transit settings handle this automatically. BGP (option F) is about route advertisement to on-premises, not about enabling spoke-to-gateway connectivity.

NSG rules are evaluated in ascending priority order (lowest number = highest priority). Rule 100 (Allow, port 443) is evaluated before rule 200 (Deny, port 443). Since rule 100 matches first, the traffic is allowed and evaluation stops — rule 200 is never reached (option A is correct). — Option C is incorrect: rule 200 would only apply if no earlier rule matched; rule 100 takes precedence. Option B is incorrect: while rule 65000 does not cover internet traffic, the evaluation never reaches it because rule 100 already allows the traffic. Option D is incorrect: the actual Azure default rule for inbound is 65500 'DenyAllInBound', which denies all traffic not matched by prior rules — there is no default rule that allows all inbound traffic from any source.

The health probe interval (how often the probe checks) combined with the unhealthy threshold (how many consecutive failures before marking unhealthy) directly controls the detection latency before a VM is removed from rotation (option B). Reducing the probe interval and/or threshold reduces the window during which traffic is sent to a failed instance. — Option C is incorrect: idle timeout governs how long TCP connections are kept alive when idle; it has no effect on health detection or VM removal. Option A is incorrect: Floating IP (also known as Direct Server Return) changes how the destination IP is presented to the backend VM; it has nothing to do with health monitoring. Option D is incorrect: an NSG blocking traffic to the failed VM would prevent legitimate traffic from reaching it but does not interact with the Load Balancer's health probe mechanism and could cause unintended connectivity issues.

Packet Capture (Option D) records actual network packets flowing through a VM's NIC to a storage account or file, making it ideal for forensic traffic analysis. Connection Monitor (Option F) is designed for recurring synthetic connectivity tests — you can configure probes from a VM to an external HTTPS endpoint on a schedule and receive alerts when connectivity degrades. IP Flow Verify (Option B) evaluates NSG rules for a specific 5-tuple (source IP, destination IP, source port, destination port, protocol) and returns whether the traffic is allowed or denied and which rule is responsible. — Option A is wrong: Network Performance Monitor (now part of Connection Monitor) measures latency/packet loss on network paths but does not capture raw packets for forensic use. — Option C is wrong: Traffic Analytics processes NSG Flow Logs to provide aggregate traffic pattern insights across a network, not real-time or scheduled endpoint reachability tests. — Option E is wrong: Next Hop determines the routing path (next hop type and IP) for traffic from a VM, which is used for routing troubleshooting, not NSG rule evaluation.

Azure Resource Graph (ARG) is the correct tool for querying Azure Policy compliance state changes over time. ARG exposes the 'policyStates' resource type and retains historical compliance state data, allowing queries for state transitions over up to 90 days. This is the purpose-built solution for policy compliance history queries at scale. Option A is incorrect because Azure Monitor platform metrics do not include policy compliance state data; there is no 'Microsoft.PolicyInsights' metrics namespace for compliance state transitions. Option B is partially plausible — the Activity Log does record some PolicyInsights events — but compliance state change events (non-compliant transitions) are not reliably recorded as Activity Log operations; Activity Logs capture control-plane write operations, not the policy evaluation engine's compliance determinations. Option D is incorrect because the 'AzureActivity' table in Log Analytics contains Azure Activity Log data, which, as noted, does not capture detailed policy compliance state transitions.

Enabling a diagnostic setting on each Key Vault to send AuditEvent (resource) logs to a Log Analytics workspace captures all data-plane and administrative operations performed on the Key Vault. Configuring the Log Analytics workspace retention to 730 days (2 years) satisfies the 2-year retention requirement. Together these two meet both logging and retention requirements. Microsoft Defender for Key Vault provides threat detection alerts for suspicious activity but does not provide a comprehensive queryable log of all administrative operations — it is a security layer, not a full audit log solution. An activity log alert rule triggers notifications for specific events but does not store logs for queryability or long-term retention. Soft delete and purge protection protect against accidental or malicious deletion of Key Vault objects but have nothing to do with audit logging or retention. A subscription-level diagnostic setting captures Azure Activity Log entries (control-plane) but does not capture Key Vault resource/data-plane logs.