AZ-104 Manage Azure Identities and Governance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Assign an initiative containing both policy definitions at the Corp management-group scope.

  Why this is correct

  Assigning an initiative containing both policy definitions at the Corp management-group scope is the most scalable and effective approach. Policy assignments made at a management-group scope are inherited by all child subscriptions and resource groups, meaning all 12 subscriptions plus any future subscriptions added to that management group automatically receive the same governance. Grouping the definitions into an initiative (policy set) also allows them to be assigned, evaluated, and reported on as a single compliance unit, reducing administrative overhead and ensuring consistent enforcement of both tag requirements and allowed locations across the entire department.

• ✓

  Create a policy exemption for the pilot subscription.

  Why this is correct

  Creating a policy exemption specifically for the pilot subscription is a valid way to allow that subscription to remain non-compliant without weakening the policy assignment for the other subscriptions. The exemption is scoped to that subscription and applies to the specific assigned initiative, so you can define it with an expiration date or as an indefinite waiver. This keeps the rest of the department under full enforcement, while the pilot is explicitly marked as exempt in compliance reports, allowing you to track the exception and remove it once the pilot is ready.

• ✗

  Assign the policies individually at each resource group.

  Why it's wrong here

  Assigning the two policy definitions individually at every resource group would be extremely inefficient and error-prone, especially across 12 subscriptions with potentially many resource groups. Each assignment must be created manually, and any new resource group or subscription would not be covered unless you remember to assign the policies again. Also, policy assignments at resource-group scope only affect resources within that resource group, meaning you'd need to repeat this across every resource group, and there is no inherited coverage for future subscriptions. This approach fragments compliance management, creates gaps, and increases the chance of missed assignments, unlike a single management-group-scoped initiative.

  When this WOULD be correct

  If the requirement was to apply different policies to different resource groups within a subscription, or if the policies needed to be scoped to specific resource groups only (e.g., for granular control), then assigning individually at each resource group would be correct.

• ✗

  Use the Owner role at the management-group scope.

  Why it's wrong here

  Assigning the Owner role at the management-group scope grants users full RBAC permissions to manage resources, roles, and access, but it does not enforce any required tags or restrict where resources can be deployed. RBAC is an authorization mechanism that controls who can perform actions, while Azure Policy is a governance mechanism that controls what resource configurations are allowed. An Owner could create resources in disallowed regions or with missing tags, and there is no automatic compliance evaluation or prevention. Therefore, RBAC cannot address the department's requirement to enforce tagging and location restrictions.

  When this WOULD be correct

  This option would be correct in a scenario where the question asks: 'You need to delegate full administrative control over all subscriptions under a management group to a new administrator. Which role should you assign at the management-group scope?'

• ✗

  Use a resource lock instead of Azure Policy.

  Why it's wrong here

  A resource lock (e.g., CanNotDelete or ReadOnly) is designed to prevent accidental deletion or modification of a resource, not to enforce governance rules like mandatory tags or allowed locations. Locks operate at the Azure Resource Manager control plane, blocking certain operations at the resource level, but they do not evaluate or correct resource properties during creation or after deployment. Azure Policy works differently: it audits or denies deployments that violate tag and location rules, continuously checking existing resources and flagging non-compliance. Thus, a resource lock cannot replace Azure Policy for this scenario.

  When this WOULD be correct

  A resource lock would be correct if the question required preventing accidental deletion or modification of critical resources, such as a production database, without needing to enforce policies on location or tags.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question