Manage Azure Identities and Governance →mediumMultiple ChoiceObjective-mapped

AZ-104 Manage Azure Identities and Governance Practice Question

Exhibit

Governance requirement:
- All current and future subscriptions under Corp must be restricted to East US and West US
- Deployments to any other region must be blocked
Current state:
- Contributors already have permission to create resources
- No region restriction is currently in place

Based on the exhibit, an administrator wants to prevent new Azure resources from being deployed in any region except East US and West US across the entire Corp hierarchy. What should the administrator configure?

⚠ Common exam trap

Watch out — candidates often confuse Azure Policy (which enforces rules on resource properties) with RBAC (which controls access) or resource locks (which prevent deletion), leading candidates to choose an option that addresses permissions rather than configuration compliance.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create and assign an Azure Policy at the Corp management group using the allowed locations rule.

Azure Policy is the correct tool to enforce governance rules across management groups. The 'allowed locations' built-in policy definition restricts resource deployment to specified regions. By assigning this policy at the Corp management group, the rule applies to all child subscriptions and resources, preventing deployment in any region except East US and West US.

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 a built-in RBAC role that denies deployments in unsupported regions.
Why it's wrong here
Built-in RBAC roles define what actions an identity can perform (e.g., write, delete, assign roles), but they do not evaluate the properties of a deployment such as the target Azure region. No built-in role denies deployments based on region, and even a custom role cannot natively check the 'location' property of a deployment request. Region enforcement is a resource-level constraint that requires Azure Policy, which can inspect the location of an incoming PUT request and deny it before the resource is provisioned.
When this WOULD be correct
If the question asked: 'An administrator wants to prevent a specific user from deploying resources in any region except East US and West US.' Then assigning a custom RBAC role with a deny action on unsupported regions would be correct.
✓
Create and assign an Azure Policy at the Corp management group using the allowed locations rule.
Why this is correct
Azure Policy is the correct tool for enforcing location compliance. Assigning the policy at the Corp management group ensures the restriction applies to all current and future child subscriptions, and a deny effect blocks noncompliant region deployments at creation time.
✗
Apply a CanNotDelete lock to the subscriptions.
Why it's wrong here
A CanNotDelete lock is an Azure Resource Manager lock that prevents deletion or modification of existing resources, but it does not govern new resource creation. Applying this lock to a subscription would block the subscription itself from being deleted, but it has no effect on whether a new VM, storage account, or other resource is created in a disallowed region. Locks are designed for protecting existing infrastructure, not for enforcing placement or configuration rules on future deployments.
When this WOULD be correct
If the question asked how to prevent accidental deletion of critical subscriptions or resource groups, applying a CanNotDelete lock at the subscription or resource group level would be correct.
✗
Use a resource tag named RegionApproved and require teams to set it manually.
Why it's wrong here
A resource tag named RegionApproved is metadata, not an enforcement mechanism. Even if you require the tag through a policy or naming convention, it does not evaluate the actual deployment region nor block the resource from being created. Manual tagging relies on human discipline and can be skipped or incorrectly applied, so it cannot prevent a user from choosing an unapproved Azure region at deployment time.
When this WOULD be correct
If the question asked for a method to track which resources are approved for deployment in specific regions without blocking deployments, or to report on compliance after the fact, then requiring a 'RegionApproved' tag 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.

✓Create and assign an Azure Policy at the Corp management group using the allowed locations rule.Correct answer▾

Why this is correct

Azure Policy is the correct tool for enforcing location compliance. Assigning the policy at the Corp management group ensures the restriction applies to all current and future child subscriptions, and a deny effect blocks noncompliant region deployments at creation time.

✗Assign a built-in RBAC role that denies deployments in unsupported regions.Wrong answer — click to see why▾

Why this is wrong here

RBAC roles control access to Azure resources (who can do what), not which regions are allowed for deployment. A built-in RBAC role cannot enforce region restrictions; Azure Policy is required for such governance.

★ When this WOULD be the correct answer

If the question asked: 'An administrator wants to prevent a specific user from deploying resources in any region except East US and West US.' Then assigning a custom RBAC role with a deny action on unsupported regions would be correct.

Why candidates choose this

Candidates may confuse RBAC's deny assignments with policy enforcement, thinking that a role can restrict deployment locations, when in fact RBAC only manages permissions, not resource properties.

✗Apply a CanNotDelete lock to the subscriptions.Wrong answer — click to see why▾

Why this is wrong here

A CanNotDelete lock prevents deletion of resources but does not restrict deployment regions; it cannot block resource creation in non-allowed regions.

★ When this WOULD be the correct answer

If the question asked how to prevent accidental deletion of critical subscriptions or resource groups, applying a CanNotDelete lock at the subscription or resource group level would be correct.

Why candidates choose this

Candidates may confuse locks with policy restrictions, thinking a lock can block all operations including creation, or they may misremember the purpose of CanNotDelete locks.

✗Use a resource tag named RegionApproved and require teams to set it manually.Wrong answer — click to see why▾

Why this is wrong here

Resource tags are not enforced; they rely on manual compliance and do not prevent deployment in unapproved regions. Azure Policy is required to enforce allowed locations across the management group hierarchy.

★ When this WOULD be the correct answer

If the question asked for a method to track which resources are approved for deployment in specific regions without blocking deployments, or to report on compliance after the fact, then requiring a 'RegionApproved' tag would be correct.

Why candidates choose this

Candidates may think tags can enforce governance because they are used for organization and cost tracking, but they lack the enforcement capability of Azure Policy.

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

AZ-104 Manage Azure Identities and Governance Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

Related to this question