This chapter covers Azure Subscription and Management Group Design, a core topic in Identity Governance (Objective 1.2) for the AZ-305 exam. Understanding how to structure management groups and subscriptions is critical because it directly impacts policy enforcement, cost management, and access control across an enterprise Azure estate. Expect approximately 10-15% of exam questions to touch on management group hierarchy, subscription strategies, and policy inheritance, often in scenario-based questions that require you to recommend the most appropriate design.
Jump to a section
Imagine a multinational corporation with thousands of employees. The CEO at the top defines global policies like 'all employees must complete annual compliance training.' This is analogous to an Azure management group at the root level, which can apply policies to all subscriptions beneath it. The company is divided into divisions (e.g., North America, Europe), each with its own director who can enforce additional policies specific to their region, but cannot override the CEO's policies. These divisions are like child management groups. Within each division, there are departments (e.g., Sales, IT), each with its own budget and subscriptions. The department heads (subscription owners) can manage resources within their budget but must comply with all policies from above. The CEO can delegate administration: the North America director can manage user access within their division but cannot touch Europe. Similarly, Azure RBAC can be assigned at management group scope, and permissions are inherited downward. If the CEO wants to block all employees from using a specific software, she sets a policy at the top, and it automatically applies to every division, department, and employee. If a department head tries to create a resource that violates that policy, the system denies it—just as an employee cannot override a company-wide mandate. This hierarchical structure ensures consistent governance, cost management, and security across the entire organization, while allowing flexibility at lower levels.
What Are Azure Management Groups and Subscriptions?
Azure Management Groups are containers that help you manage access, policy, and compliance across multiple subscriptions. They form a single hierarchy that can go up to six levels deep (excluding the root level). Subscriptions are the next level down and are the fundamental unit of billing, access control, and resource management. Each subscription is associated with a single Azure Active Directory tenant. Resources are deployed into resource groups within a subscription.
Why Management Groups Exist
Before management groups, each subscription had to be managed independently. If an organization had hundreds of subscriptions, applying a common policy (e.g., 'deny all public IP addresses') required manual configuration in each subscription. Management groups solve this by allowing you to apply Azure Policy and RBAC assignments at a higher scope, which automatically inherits down to all child management groups and subscriptions.
How the Hierarchy Works Internally
The hierarchy starts with the root management group, which is automatically created for each Azure AD tenant. You cannot delete the root management group. All subscriptions within the tenant are children of the root group by default. You can create child management groups under the root, and then move subscriptions into them. The hierarchy is a tree structure: each management group can have multiple children, but only one parent. The maximum depth is six levels (root + five child levels).
When you assign a policy at a management group, it applies to all subscriptions and resource groups within that management group. Policy evaluation is additive: effective policies are the union of all policies from the management group chain. However, if a policy is defined with a specific effect (e.g., Deny), it cannot be overridden by a child scope unless the policy definition allows exemptions. RBAC assignments also inherit; a user granted 'Reader' role at a management group can read all resources in all subscriptions under that group.
Key Components, Values, Defaults
Root Management Group: Automatically created, cannot be deleted or moved. Its ID is the tenant ID. All subscriptions are initially placed under it.
Maximum Depth: 6 levels (root + 5). This includes the root, so you can have at most 5 custom levels below root.
Management Group Count: Up to 10,000 management groups per directory.
Subscription Count: Up to 10,000 subscriptions per Azure AD tenant (soft limit, can be increased by request).
Policy Inheritance: Policies applied at higher scopes are inherited by all lower scopes. Exclusions can be made using policy exemptions (not exclusions) at child scopes.
RBAC Inheritance: Permissions assigned at a management group scope are inherited by all child subscriptions and resource groups. However, RBAC assignments are not inherited across management groups at the same level; they only flow downward.
Configuration and Verification Commands
You can create management groups using the Azure portal, Azure CLI, PowerShell, or REST API. Here are common CLI commands:
# Create a management group
az account management-group create --name "MyGroup" --display-name "My Management Group"
# Add a subscription to a management group
az account management-group subscription add --name "MyGroup" --subscription "<subscription-id>"
# List management groups
az account management-group list
# View hierarchy
az account management-group show --name "MyGroup" --expandPowerShell equivalent:
New-AzManagementGroup -GroupId "MyGroup" -DisplayName "My Management Group"
New-AzManagementGroupSubscription -GroupId "MyGroup" -SubscriptionId "<subscription-id>"
Get-AzManagementGroupInteraction with Related Technologies
Azure Policy: Policies can be assigned at management group, subscription, or resource group scope. Assigning at management group is recommended for baseline policies (e.g., allowed regions, resource types).
RBAC: Role assignments at management group scope grant access to all resources under that group. This is useful for central IT teams that need visibility across multiple subscriptions.
Azure Blueprints: Blueprints can define policies, RBAC assignments, and resource templates. They can be assigned to management groups to enforce a standard environment.
Cost Management: Budgets and cost alerts can be set at management group scope to track spending across multiple subscriptions.
Azure AD: Management groups are scoped to a single Azure AD tenant. Cross-tenant management is not possible natively.
Subscription Design Strategies
The AZ-305 exam tests your ability to recommend subscription designs based on business requirements. Common patterns include:
Application-Type Separation: Different subscriptions for production, development, and test environments.
Departmental Separation: Subscriptions per department (e.g., HR, Finance) to isolate billing and access.
Geographic Separation: Subscriptions per region to comply with data residency requirements.
Environment Separation: Subscriptions for different stages (dev, test, prod) within a single application.
Each subscription has its own limits (e.g., 980 resource groups per subscription, 250 storage accounts per subscription). For large-scale deployments, you may need multiple subscriptions to stay within limits.
Management Group Design Best Practices
Keep the hierarchy simple: Avoid deep nesting beyond 3-4 levels to reduce complexity.
Use a standard naming convention: Include the organization, department, and environment in the management group name.
Assign policies at the highest feasible scope: For example, assign a 'deny public IP' policy at the root management group to enforce across all subscriptions.
Use RBAC at management group scope for central teams: Grant the 'Global Administrator' role at the root management group sparingly.
Plan for subscription migration: Moving subscriptions between management groups is possible, but policies and RBAC assignments will change. Plan for a transition period.
Common Pitfalls
Exceeding the 6-level depth: If you try to create a management group deeper than 6 levels, the operation fails.
Moving a subscription without understanding policy impact: Existing resources that violate new policies may be marked as non-compliant but are not automatically deleted unless the policy effect is 'DeployIfNotExists'.
Assuming RBAC inheritance across management group siblings: A role assigned at one child management group does not apply to another child at the same level.
Forgetting that the root management group cannot be deleted: You must manage it carefully because all subscriptions inherit from it.
Design the Management Group Hierarchy
Start by analyzing the organization's structure. Determine the top-level management groups based on business units, geographies, or environments. For example, create a 'Prod' and 'NonProd' management group at level 1. Under 'NonProd', create 'Dev' and 'Test' at level 2. Ensure the total depth does not exceed 6 levels. Document the hierarchy and obtain stakeholder approval. Use a naming convention like 'mg-{org}-{dept}-{env}' for clarity. Avoid creating too many levels; 3-4 levels are typical for most enterprises.
Create Management Groups and Assign Policies
Using Azure CLI, PowerShell, or portal, create the management groups in a top-down order. Start with the root group (already exists). Create child groups under it. For each management group, assign mandatory Azure Policy definitions. For example, assign the 'Allowed Locations' policy at the root to restrict all subscriptions to a set of regions. Use policy initiatives for complex requirements. Verify inheritance by checking policy compliance in a test subscription. Remember that policies assigned at higher scopes cannot be overridden by lower scopes unless exemptions are used.
Assign RBAC Roles at Management Group Scope
Identify central teams that need access across multiple subscriptions. Assign roles like 'Reader' or 'Contributor' at the appropriate management group scope. For example, grant the 'Security Reader' role to the security team at the root management group so they can audit all subscriptions. Use Azure AD Privileged Identity Management (PIM) for time-bound assignments. Avoid assigning 'Owner' at root unless absolutely necessary. Document all role assignments for audit purposes. Remember that RBAC inheritance is downward only; a role assigned at a child group does not apply to siblings.
Create Subscriptions and Move Them into Groups
Create subscriptions using the Azure portal, EA portal, or programmatically via the Subscription API. Each subscription is automatically placed under the root management group. Move subscriptions to the appropriate child management group using the Azure portal or CLI command: `az account management-group subscription add --name "<mg-name>" --subscription "<sub-id>"`. After moving, verify that policies and RBAC assignments from the new parent apply. Note that moving a subscription may affect existing resources if new policies conflict; resources become non-compliant but are not deleted.
Implement Subscription Governance with Policy and Budgets
Within each subscription, create resource groups and assign additional policies at subscription scope if needed. Set up budgets at management group scope to track spending across subscriptions. Use Azure Cost Management to create budgets and alerts. For example, create a budget at the 'Prod' management group with a $100,000 monthly limit and email alerts when spending reaches 80%. Configure Azure Policy for resource tagging to enforce cost allocation. Use Azure Blueprints to deploy consistent environments across multiple subscriptions under a management group.
Enterprise Scenario 1: Multinational Corporation with Regional Compliance
A global company with operations in North America, Europe, and Asia needs to enforce data residency requirements. They create a root management group for the entire company. Under it, they create three child management groups: 'NA', 'EU', and 'Asia'. At each regional group, they assign a policy that restricts allowed regions to only the respective continent's Azure regions (e.g., 'EU' group allows only West Europe and North Europe). Subscriptions for each region are placed under the corresponding management group. A central IT team is granted 'Reader' role at the root group to have visibility across all regions, while regional admins are granted 'Contributor' at their respective regional group. This design ensures compliance without duplicating policy assignments. A common mistake is to assign region-restriction policies at the subscription level, which becomes unmanageable at scale. By using management groups, the company reduces policy assignments from hundreds to just three.
Enterprise Scenario 2: Large Enterprise with Application Lifecycle Management
A software company has hundreds of applications, each with dev, test, and production environments. They create a management group hierarchy: Root -> 'NonProd' and 'Prod'. Under 'NonProd', they create 'Dev' and 'Test' groups. Under 'Prod', they create groups per business unit. Each application team gets its own subscription within the appropriate group. Policies such as 'deny public IP' and 'require encryption' are assigned at the 'Prod' group to ensure production environments are secure. Development teams have more relaxed policies under 'NonProd'. Budgets are set at the 'Prod' group to track production costs. The challenge is subscription limits: each subscription has a maximum of 980 resource groups; for large applications, they may need multiple subscriptions. They use Azure Blueprints to standardize resource groups and policies across subscriptions. Misconfiguration often occurs when a subscription is moved from 'NonProd' to 'Prod' without updating policies; existing resources may become non-compliant, but the move is allowed. The team must plan for a transition window and remediate non-compliant resources.
Performance and Scale Considerations
Management groups themselves have no performance impact on resources. However, policy evaluation is performed at resource creation and update time. Deep hierarchies (6 levels) can increase policy evaluation time slightly, but this is negligible. The main scale consideration is the number of subscriptions: up to 10,000 per tenant. For organizations exceeding this, multiple tenants are required. Management group operations (create, move) are asynchronous and can take a few minutes to propagate. RBAC assignments at management group scope do not affect authentication performance. When moving a subscription, policy compliance status may take up to 30 minutes to update. Always test the move in a non-production environment first.
AZ-305 Objective 1.2: Identity Governance
The exam expects you to recommend an appropriate Azure management group and subscription design based on business requirements. Specific objectives include:
Design a management group hierarchy for policy and RBAC inheritance.
Recommend subscription design for cost management, security, and scale.
Understand the relationship between management groups, subscriptions, and Azure AD.
Common Wrong Answers and Why Candidates Choose Them
'Create a management group for each subscription': This is wrong because management groups are meant to group multiple subscriptions. Creating one management group per subscription defeats the purpose. Candidates choose this because they think it provides granular control, but it adds complexity without benefit.
'Assign policies at the subscription level for maximum control': While possible, this is not scalable. The exam favors centralized policy assignment at management group scope. Candidates may think subscription-level is more precise, but the question usually asks for a solution that minimizes administrative overhead.
'Use Azure Blueprints instead of management groups': Blueprints are complementary, not a replacement. They can be assigned to management groups, but they don't replace the hierarchy. Candidates confuse the two.
'Management groups can be nested up to 10 levels': The actual limit is 6 levels (root + 5). The exam tests this exact number. Candidates often misremember as 10.
Specific Numbers and Terms
6 levels: Maximum depth of management group hierarchy.
10,000: Maximum management groups per directory.
10,000: Maximum subscriptions per directory (soft limit).
Root management group: Cannot be deleted or moved; ID is tenant ID.
Inheritance: Policies and RBAC are inherited downward.
Exemption: Used to exclude a child scope from a policy; not 'exclusion'.
Edge Cases and Exceptions
Moving a subscription between management groups: Allowed, but policies from the new parent apply. Existing resources may become non-compliant but are not deleted.
Policy effect 'DeployIfNotExists': Can automatically remediate non-compliant resources when a subscription is moved.
Root management group administrator: Users with 'Global Administrator' in Azure AD have full access to the root management group by default. This can be restricted using Azure RBAC.
How to Eliminate Wrong Answers
If the question asks for 'minimal administrative effort', choose solutions that assign policies at the highest feasible scope (management group).
If the question mentions 'different regulatory requirements per region', use separate management groups per region with region-specific policies.
If the question says 'departments need their own billing', recommend separate subscriptions per department, possibly under a shared management group.
Look for keywords like 'inherit', 'baseline', 'centralized' — these point to management groups.
Management groups provide a hierarchy up to 6 levels deep (root + 5).
Policies and RBAC assignments at management group scope are inherited by all child subscriptions.
The root management group is created automatically and cannot be deleted.
Maximum of 10,000 management groups and 10,000 subscriptions per Azure AD tenant.
Use management groups to enforce baseline policies across multiple subscriptions with minimal administrative effort.
Subscription design should consider billing, security, and resource limits; use separate subscriptions for environments or departments.
Moving a subscription between management groups does not delete resources but may cause policy non-compliance.
Azure Blueprints can be assigned to management groups to deploy consistent environments.
These come up on the exam all the time. Here's how to tell them apart.
Management Group
Container for multiple subscriptions; forms a hierarchy.
Used to apply policies and RBAC at scale.
Cannot host resources directly; only subscriptions.
Maximum of 10,000 per directory.
Depth limited to 6 levels.
Subscription
Container for resource groups; billing boundary.
Each subscription has its own limits (e.g., 980 resource groups).
Resources are deployed into resource groups within a subscription.
Maximum of 10,000 per directory (soft limit).
No depth limit; flat structure.
Mistake
Management groups can be nested up to 10 levels deep.
Correct
The maximum depth is 6 levels, including the root. Attempting to create a 7th level will fail.
Mistake
Policies assigned at a management group can be overridden by a child subscription.
Correct
Policies with 'Deny' effect cannot be overridden; they are inherited and enforced. Only exemptions can exclude a child scope.
Mistake
Moving a subscription to a different management group automatically remediates non-compliant resources.
Correct
Resources become non-compliant if they violate new policies, but they are not automatically changed unless a 'DeployIfNotExists' policy is assigned.
Mistake
RBAC assignments at a management group apply to all subscriptions in the tenant.
Correct
RBAC assignments only apply to subscriptions that are direct or indirect children of that management group. Subscriptions under different branches do not inherit.
Mistake
You can delete the root management group.
Correct
The root management group is automatically created and cannot be deleted. You can only manage its children and assignments.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You can create up to 10,000 management groups per Azure AD directory. This is a hard limit. The hierarchy can be up to 6 levels deep, including the root. If you need more than 10,000, you must use multiple directories.
Yes, you can assign Azure Policy definitions and initiatives at management group scope. These policies are inherited by all subscriptions and resource groups within that management group. This is a best practice for enforcing baseline compliance across the organization.
Existing resources remain unchanged. However, if the new management group has policies that the resources do not comply with, they will be marked as non-compliant. Policies with 'DeployIfNotExists' effect can automatically remediate non-compliant resources, but 'Deny' policies only block new creation or updates.
No. Each Azure AD tenant has exactly one root management group, created automatically. You cannot create additional root groups. All management groups and subscriptions are children of this root.
Assign an RBAC role to the user at the management group scope. For example, assign the 'Reader' role at the root management group to give read-only access to all subscriptions in the tenant. This is more efficient than assigning the role in each subscription.
A management group is a container for subscriptions that helps manage governance, policy, and access across multiple subscriptions. A subscription is a billing and resource container where you create resource groups and deploy resources. Subscriptions are children of management groups.
No, management groups do not provide separate billing. Billing is per subscription. However, you can use management groups to organize subscriptions for cost reporting and apply budgets at the management group scope to track aggregate costs.
You've just covered Azure Subscription and Management Group Design — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?