AZ-104 Manage Azure Identities and Governance Practice Question
Your company has multiple applications deployed across separate production and nonproduction subscriptions. Finance wants cost reporting by application, and each app team should manage only its own resources. Which two design choices best satisfy both requirements? Select two.
⚠ Common exam trap
It's easy for candidates to confuse management groups with resource groups for access control, assuming a single management group can isolate app teams, but management groups do not provide RBAC boundaries for individual applications—they are for hierarchical policy management, not resource isolation.
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
✓
Place each application's Azure resources in a dedicated resource group.
Resource groups are the logical container for grouping Azure resources by application, enabling each app team to manage its own resources via Azure RBAC at the resource group scope. Option B is correct because tagging resources with an application or cost-center identifier allows Azure Cost Management to filter and report costs by application, satisfying the finance requirement for cost reporting by application.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Place each application's Azure resources in a dedicated resource group.
Why this is correct
A dedicated resource group per application is the correct administrative boundary because Azure RBAC roles (such as Contributor) can be assigned at that scope to grant the app team permissions only on that application's resources. Resource groups also provide independent lifecycle management, policy assignment, and lock scopes, so you can manage, monitor, and delete an application's resources as a single unit without affecting other apps. This gives granular access control and deployment isolation while keeping all resources under the same subscription.
- ✓
Tag each resource with an application or cost-center identifier.
Why this is correct
Tagging each resource with an application or cost-center identifier is a flexible metadata-based approach that enables cost allocation and reporting without altering access control. Cost Management can group and filter by standard tag keys to produce chargeback reports per application or cost center, even when resources span multiple resource groups or subscriptions. Tags are not an access boundary, but they complement resource groups by providing an independent dimension for financial tracking, and they can be enforced via Azure Policy.
- ✗
Create one subscription per virtual machine to simplify chargeback reporting.
Why it's wrong here
Creating one subscription per virtual machine is an extreme form of subscription sprawl that adds significant management overhead and quickly hits subscription limits (typically 25 per directory, expandable to 50). Subscriptions are a cost-management and administrative boundary, but they are not granular enough for per-VM chargeback, and each extra subscription adds separate RBAC, policy, and naming complexity. This approach does not scale for multiple applications or workloads and fails to provide a practical, centralized cost reporting mechanism.
When this WOULD be correct
In a scenario where each application requires strict administrative isolation, separate billing, and independent policy enforcement, and the number of applications is small (e.g., under 10), creating a dedicated subscription per application could be correct.
- ✗
Use resource names only for cost reporting because names are always unique and queryable.
Why it's wrong here
Using resource names alone for cost reporting is unreliable because resource names are not a standardized metadata dimension and are not inherently structured for grouping costs. Names are not guaranteed to be unique across resource types (e.g., two different VM names can exist in different resource groups), and they may change during lifecycle operations, which breaks historical cost tracking. Azure Cost Management does not natively aggregate by resource name as a governance control, so names cannot replace tags or resource group scopes for consistent, queryable cost allocation.
When this WOULD be correct
If the question asked for a simple way to identify resources in a small, single-subscription environment where naming conventions are strictly enforced and no automated cost aggregation is required, using resource names might be acceptable.
- ✗
Place all applications in one management group and use it as the access boundary for each app team.
Why it's wrong here
A management group is a container for subscriptions and is used to apply governance like Azure Policy and RBAC across all subscriptions it includes—it cannot create access boundaries for individual applications that live inside a shared subscription. If all applications are in one management group, assigning access at that scope would grant permissions to every resource in every subscription, not just one app's resources. To separate app-team access, you must use resource groups (or separate subscriptions) because management groups only provide coarse-grained, subscription-topology-level controls.
When this WOULD be correct
If the requirement was to apply common policies (e.g., allowed regions) across multiple subscriptions for all applications, and cost reporting was handled separately via tags, then a single management group 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.
✓Place each application's Azure resources in a dedicated resource group.Correct answer▾
Why this is correct
A dedicated resource group per application is the correct administrative boundary because Azure RBAC roles (such as Contributor) can be assigned at that scope to grant the app team permissions only on that application's resources. Resource groups also provide independent lifecycle management, policy assignment, and lock scopes, so you can manage, monitor, and delete an application's resources as a single unit without affecting other apps. This gives granular access control and deployment isolation while keeping all resources under the same subscription.
✗Create one subscription per virtual machine to simplify chargeback reporting.Wrong answer — click to see why▾
Why this is wrong here
Creating one subscription per virtual machine is impractical and violates Azure subscription limits (max 10,000 VMs per subscription) and cost reporting best practices; subscriptions are not granular enough for per-app reporting.
★ When this WOULD be the correct answer
In a scenario where each application requires strict administrative isolation, separate billing, and independent policy enforcement, and the number of applications is small (e.g., under 10), creating a dedicated subscription per application could be correct.
Why candidates choose this
Candidates may think that a separate subscription provides the ultimate isolation and simplifies chargeback, not realizing that resource groups and tags achieve the same goals more efficiently and without hitting subscription limits.
✗Use resource names only for cost reporting because names are always unique and queryable.Wrong answer — click to see why▾
Why this is wrong here
Resource names are not guaranteed to be unique across subscriptions or resource groups, and they lack the structured querying and filtering capabilities of tags, making them unreliable for accurate cost reporting.
★ When this WOULD be the correct answer
If the question asked for a simple way to identify resources in a small, single-subscription environment where naming conventions are strictly enforced and no automated cost aggregation is required, using resource names might be acceptable.
Why candidates choose this
Candidates may think resource names are sufficient because they are familiar with naming conventions and underestimate the need for scalable, queryable metadata like tags for cross-subscription reporting.
✗Place all applications in one management group and use it as the access boundary for each app team.Wrong answer — click to see why▾
Why this is wrong here
Placing all applications in one management group does not provide per-application cost reporting or isolate access for each app team; management groups are for policy and compliance inheritance, not granular RBAC or cost allocation.
★ When this WOULD be the correct answer
If the requirement was to apply common policies (e.g., allowed regions) across multiple subscriptions for all applications, and cost reporting was handled separately via tags, then a single management group would be correct.
Why candidates choose this
Candidates may confuse management groups with resource groups, thinking they can serve as access boundaries and cost centers, but management groups lack built-in cost aggregation and RBAC scoping for individual applications.
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
Scope
In IT, scope defines the boundaries, goals, and deliverables of a project, assessment, or engagement, specifying what is included and what is excluded.
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.
About these practice questions
One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.