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 allowed-locations policy at the management group or subscription scope.

  Why this is correct

  An allowed-locations policy assignment at the management group or subscription scope is correct because Azure Policy evaluates the location property of each resource during deployment and can deny any request that specifies a non-approved region. Policy inheritance means the restriction applies to all child subscriptions and resource groups without requiring additional assignments, and it does not depend on the contributor role assignment the team already has. Because the team is a Contributor, they can create resources anywhere within the subscription; only a policy can intercept and block that action based on the region.

• ✗

  Create a custom RBAC role that blocks resources deployed outside approved regions.

  Why it's wrong here

  A custom RBAC role that attempts to block resources outside approved regions cannot work because RBAC permissions are based on actions (such as Microsoft.Resources/deployments/write) and do not inspect resource properties like location during evaluation. Even with deny assignments or custom roles, you cannot express a condition that says 'this deployment is allowed only if the region is X' purely through role-based permissions. Azure Policy is the service that performs property-based evaluation and is the appropriate mechanism for this requirement.

  When this WOULD be correct

  A question where the organization wants to restrict deployment actions for a specific team (e.g., deny create/update operations on resources outside approved regions) and the solution must use role-based access control, not policy. For example: 'You need to prevent a specific user group from deploying resources in unapproved regions using a custom role.'

• ✓

  Assign a policy that enforces the Environment tag on new resources.

  Why this is correct

  Assigning a policy that enforces the Environment tag on new resources (using effects such as deny, append, or modify) is a correct governance action because tags are metadata stored on the resource itself and are fully inspectable by Azure Policy. For example, a policy with the deny effect can reject deployments that omit the tag, while the append or modify effect can automatically add the tag after creation. This works independently of RBAC, so even users with Contributor rights cannot bypass the tagging requirement.

• ✗

  Add a CanNotDelete lock to every resource group.

  Why it's wrong here

  Adding a CanNotDelete lock to every resource group is wrong here because locks are designed to prevent accidental deletion or modification of critical resources, not to enforce deployment-time compliance rules like allowed regions or required tags. A lock does not evaluate the properties of a newly deployed resource; it operates after the resource exists and cannot inspect the deployment request itself. Contributor users would still be able to create resources in any region, and the lock would not add the Environment tag or reject an unapproved location.

  When this WOULD be correct

  In a scenario where the organization wants to prevent accidental deletion of critical resources, such as production databases, a CanNotDelete lock should be applied at the resource group level to protect against deletion by users with Contributor permissions.

• ✗

  Grant User Access Administrator to the deployment team.

  Why it's wrong here

  Granting User Access Administrator to the deployment team is incorrect because that role only manages Azure RBAC role assignments and does not enforce any governance or compliance requirements on resource deployments. It would give the team the ability to grant themselves or others additional permissions, making governance worse, but it would not restrict the region or validate tags. Since the team already has Contributor, they can create resources; adding User Access Administrator does nothing to constrain where or how they do it.

  When this WOULD be correct

  In a scenario where a team needs to manage role assignments for other users (e.g., delegate role administration) but should not have full access to resources, User Access Administrator would be correct.

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