AZ-104 Manage Azure Identities and Governance Practice Question
A company has 18 Azure subscriptions. Production subscriptions must inherit stricter governance than sandbox subscriptions, and central IT wants one place to target future policy assignments to each group. What should the administrator do?
⚠ Common exam trap
Test-takers frequently confuse resource groups or tags as mechanisms for grouping subscriptions for policy inheritance, but only management groups provide the hierarchical structure needed to apply policies consistently across multiple subscriptions.
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 management groups for Prod and Sandbox, then move subscriptions into them
Management groups allow you to organize Azure subscriptions hierarchically and apply Azure Policy and role-based access control (RBAC) at the management group level, which is inherited by all subscriptions within that group. By creating separate management groups for Prod and Sandbox and moving the respective subscriptions into them, central IT can assign policy assignments once to each management group, ensuring stricter governance for production subscriptions and a lighter touch for sandbox subscriptions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create management groups for Prod and Sandbox, then move subscriptions into them
Why this is correct
Management groups create a hierarchy above subscriptions, so placing production subscriptions under a 'Prod' management group and others under 'Sandbox' allows you to assign Azure Policy definitions, role-based access control, and security controls at the management group level. Those assignments are inherited by every subscription in that group, minimizing duplicate configuration. This directly satisfies the requirement that production subscriptions inherit specific governance settings while sandbox subscriptions remain separate.
- ✗
Create resource groups named Prod and Sandbox in each subscription
Why it's wrong here
Resource groups are organizational containers that live inside a single subscription, not a parent entity for subscriptions. Creating resource groups named 'Prod' and 'Sandbox' in each of the 18 subscriptions only groups resources locally and does not create a shared governance layer above those subscriptions. Because policy and RBAC inheritance flows from management groups down through subscriptions to resource groups, this option fails to provide the required cross-subscription inheritance.
When this WOULD be correct
If the question required grouping resources within a single subscription for role-based access control or resource management, and the goal was to apply policies at the resource group level rather than across subscriptions, creating resource groups named Prod and Sandbox would be appropriate.
- ✗
Use tags on subscriptions to separate production from sandbox
Why it's wrong here
Tags on subscriptions are only metadata for organization, billing, or reporting; they do not establish an inheritance relationship. No Azure Policy, RBAC role assignment, or lock applied to a subscription is automatically inherited by another subscription based on a tag value. Even if both production subscriptions carry the same tag, you would still have to configure every governance control individually on each subscription, so tags cannot satisfy the inheritance requirement.
- ✗
Apply a CanNotDelete lock to each subscription
Why it's wrong here
A CanNotDelete lock at subscription scope prevents the entire set of resources in that subscription from being deleted, but it is an operational safeguard rather than a governance boundary. Locks only affect delete operations; they do not enable selective inheritance of policies or permissions to child resources. Applying this lock to each production subscription would protect them from accidental deletion but would not centralize configuration or separate production from sandbox environments.
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 management groups for Prod and Sandbox, then move subscriptions into themCorrect answer▾
Why this is correct
Management groups create a hierarchy above subscriptions, so placing production subscriptions under a 'Prod' management group and others under 'Sandbox' allows you to assign Azure Policy definitions, role-based access control, and security controls at the management group level. Those assignments are inherited by every subscription in that group, minimizing duplicate configuration. This directly satisfies the requirement that production subscriptions inherit specific governance settings while sandbox subscriptions remain separate.
✗Create resource groups named Prod and Sandbox in each subscriptionWrong answer — click to see why▾
Why this is wrong here
Resource groups are organizational containers within a single subscription, not across subscriptions. They cannot be used to centrally target policy assignments across multiple subscriptions, as policies applied to a resource group only affect resources within that specific subscription's resource group.
★ When this WOULD be the correct answer
If the question required grouping resources within a single subscription for role-based access control or resource management, and the goal was to apply policies at the resource group level rather than across subscriptions, creating resource groups named Prod and Sandbox would be appropriate.
Why candidates choose this
Candidates may confuse resource groups with management groups, thinking that resource groups can span subscriptions or serve the same hierarchical grouping purpose for policy inheritance across subscriptions.
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?”
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Dynamic Membership Groups
Key term
RBAC
RBAC is a method of restricting network access based on the roles of individual users within an organization, where permissions are assigned to roles rather than to individuals directly.
Key term
Azure Policy
Azure Policy is a service in Microsoft Azure that lets you create, assign, and manage rules to ensure your resources stay compliant with your company standards and service-level agreements.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.