AZ-104 Manage Azure Identities and Governance Practice Question
A company wants development and production workloads for the same application to have separate budgets, separate subscription administrators, and different access controls. The central IT team still wants to apply the same security policies to both environments. What is the best design?
⚠ Common exam trap
Candidates often confuse resource groups with management groups, thinking that resource groups can provide the same policy inheritance and administrative isolation as subscriptions, but resource groups lack subscription-level billing separation and independent RBAC administration.
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 a separate subscription for dev and prod, then place both subscriptions under the same management group
It uses separate subscriptions for development and production, which provides independent budget tracking, subscription-level role assignments, and separate administrators. Placing both subscriptions under the same management group allows the central IT team to apply consistent Azure Policy and RBAC security policies across both environments via the management group hierarchy, ensuring governance without compromising isolation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use one subscription and separate the environments with tags only
Why it's wrong here
Tags are key-value metadata used for cost allocation, inventory, and automation, but they are not an enforcement boundary: Azure RBAC does not evaluate tag values when determining whether a user can manage a resource. With a single subscription, dev and prod share the same billing account, subscription quota, and subscription-level role assignments, so a user with Contributor rights could modify resources regardless of their tag. Even if Azure Policy forces tagging, it does not provide independent budgets, administrators, or fault isolation, so tags alone cannot satisfy the isolation requirement.
When this WOULD be correct
If the question required only cost tracking and resource organization without separate administration or budgets, and the company wanted to use a single subscription with minimal overhead, then using tags to distinguish environments would be sufficient.
- ✗
Use one management group and two resource groups, one for dev and one for prod
Why it's wrong here
Resource groups are logical containers within a single subscription, so dev and prod would still share the same subscription-level billing account, quota, and any subscription-scoped role assignments such as Owners. Azure Policy inherited from the management group can enforce tagging or location, but it cannot separate budgets, isolate service quotas, or prevent subscription administrators from accessing both resource groups. A resource group is a management boundary, not a billing or security boundary, so this design fails to meet the requirement for independent dev and prod environments.
When this WOULD be correct
If the requirement was only to organize resources with different tags and apply the same policies, but without needing separate budgets or subscription administrators, then using one subscription with separate resource groups under a management group would be sufficient.
- ✓
Create a separate subscription for dev and prod, then place both subscriptions under the same management group
Why this is correct
Separate subscriptions create independent billing scopes, quota limits, and RBAC administration boundaries, so production and development can each have their own Owner, budget, and outage isolation. Placing both subscriptions under the same management group lets you inherit Azure Policy, Azure RBAC, and tag governance centrally, ensuring consistent compliance and tagging without merging the dev and prod administrative or cost boundaries. This reflects the Azure best practice of using subscriptions as isolation boundaries and management groups as policy and governance containers.
- ✗
Put production in a management group and development in a resource group
Why it's wrong here
A management group and a resource group are at different levels of the Azure hierarchy: management groups may contain subscriptions, and subscriptions contain resource groups. Placing production in a management group and development in a resource group means they are not peer environments, so policies, budgets, and RBAC would have to be configured at structurally different scopes, making governance inconsistent and potentially leaving development without a proper management-group context. This violates the hierarchical model and does not create separate billing or administrative boundaries for the two workloads.
When this WOULD be correct
If the question required applying different policies to production and development environments without needing separate budgets or subscription administrators, and the environments were within the same subscription, then using a management group for production (with a dedicated policy) and a resource group for development (with a different policy) could be a valid approach to enforce distinct access controls.
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 a separate subscription for dev and prod, then place both subscriptions under the same management groupCorrect answer▾
Why this is correct
Separate subscriptions create independent billing scopes, quota limits, and RBAC administration boundaries, so production and development can each have their own Owner, budget, and outage isolation. Placing both subscriptions under the same management group lets you inherit Azure Policy, Azure RBAC, and tag governance centrally, ensuring consistent compliance and tagging without merging the dev and prod administrative or cost boundaries. This reflects the Azure best practice of using subscriptions as isolation boundaries and management groups as policy and governance containers.
✗Use one subscription and separate the environments with tags onlyWrong answer — click to see why▾
Why this is wrong here
Tags alone cannot enforce separate budgets, subscription administrators, or access controls; they are metadata only and do not provide administrative isolation or separate billing.
★ When this WOULD be the correct answer
If the question required only cost tracking and resource organization without separate administration or budgets, and the company wanted to use a single subscription with minimal overhead, then using tags to distinguish environments would be sufficient.
Why candidates choose this
Candidates may think tags are a flexible way to organize resources and assume they can be used for access control and billing, but tags lack the isolation and administrative boundaries that subscriptions provide.
✗Use one management group and two resource groups, one for dev and one for prodWrong answer — click to see why▾
Why this is wrong here
Resource groups cannot enforce separate budgets, subscription administrators, or access controls; they share the same subscription-level policies and RBAC. Management groups provide policy inheritance, but this option lacks separate subscriptions for independent administration.
★ When this WOULD be the correct answer
If the requirement was only to organize resources with different tags and apply the same policies, but without needing separate budgets or subscription administrators, then using one subscription with separate resource groups under a management group would be sufficient.
Why candidates choose this
Candidates may think resource groups provide sufficient separation for environments, overlooking that subscription-level features like billing and admin roles are not isolated at the resource group level.
✗Put production in a management group and development in a resource groupWrong answer — click to see why▾
Why this is wrong here
Putting production in a management group and development in a resource group is invalid because management groups and resource groups are hierarchical containers at different levels; you cannot place a resource group inside a management group in this manner, and it does not provide separate subscription-level administration or budgets.
★ When this WOULD be the correct answer
If the question required applying different policies to production and development environments without needing separate budgets or subscription administrators, and the environments were within the same subscription, then using a management group for production (with a dedicated policy) and a resource group for development (with a different policy) could be a valid approach to enforce distinct access controls.
Why candidates choose this
Candidates may confuse management groups and resource groups as interchangeable containers for organizing workloads, or think that placing environments in different container types automatically provides separation of administration and budgets.
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
Privileged Identity Management (PIM)
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
Subscription
A subscription is a payment model where you pay a recurring fee to access a product or service instead of buying it once and owning it forever.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.