This chapter covers Azure Management Groups Hierarchy, a critical governance tool for organizing Azure subscriptions and applying policies at scale. Understanding management groups is essential for the AZ-900 exam, as it appears under Azure Architecture and Services (objective 2.1) and carries approximately 15-20% weight across all governance topics. You will learn how to structure management groups, how inheritance works, and how to use them with Azure Policy and RBAC to enforce compliance across your entire Azure estate.
Jump to a section
Imagine a large multinational corporation. The CEO at corporate headquarters (root management group) sets a company-wide policy: 'No employee may use unauthorized software.' This policy applies to every division (child management groups) and every department (subscriptions) below. Each division head can add their own additional policies, like 'All laptops must have antivirus software,' but they cannot override the CEO's policy. Now picture a division that ignores the CEO's policy and tries to allow unauthorized software. The corporate governance structure prevents that because the CEO's policy is inherited and enforced. In Azure, Management Groups work exactly like this: the root management group applies Azure Policy or RBAC at the top, and all child management groups and subscriptions inherit those settings. You can create a hierarchy of management groups (like divisions, regions, departments) to reflect your organization's structure. Each level can add its own policies, but they cannot block inherited policies. This enables centralized governance while allowing autonomy within boundaries. Without this hierarchy, you'd have to apply policies to each subscription individually—like a CEO personally visiting every department to enforce a rule. The mechanism of inheritance is powerful: it means a single policy at the root can govern thousands of subscriptions automatically.
What is Azure Management Groups Hierarchy and the Business Problem It Solves
Azure Management Groups are containers that help you manage access, policy, and compliance across multiple Azure subscriptions. The business problem is simple: as organizations grow, they may have tens, hundreds, or even thousands of subscriptions. Without a hierarchy, you would have to apply policies (like 'only allow resources in US regions') or role assignments (like 'give all finance users reader access') to each subscription individually. That's inefficient and error-prone. Management groups solve this by allowing you to apply governance at a high level and have it automatically inherited by all subscriptions underneath.
The hierarchy starts with a single root management group (the tenant root group) that is automatically created for every Azure Active Directory (Azure AD) tenant. You can then create child management groups under the root, and subscriptions under those management groups. The structure can be up to six levels deep (not counting the root). This allows you to mirror your organization's structure—by department, geography, environment (dev/test/prod), or any other logical grouping.
How It Works – Step-by-Step Mechanism
Root Management Group: Every Azure AD tenant has a root management group called "Tenant Root Group." It cannot be deleted or moved. All management groups and subscriptions are children of this root. By default, the root has no policies or RBAC assignments, but you can assign them.
Creating Child Management Groups: You create management groups under the root. For example, you might create "Sales," "Marketing," and "Engineering" management groups. Each of these can have further child management groups, e.g., "Engineering" could have "Dev," "Test," and "Prod."
Moving Subscriptions: Subscriptions are placed under management groups. A subscription can only be in one management group at a time. When you move a subscription, it inherits all policies and RBAC assignments from its new parent management group and all ancestors.
Inheritance: Policies and RBAC assignments applied at a management group are inherited by all child management groups and subscriptions. For example, if you assign the "Allowed Locations" policy at the root to restrict resources to US regions, every subscription under any management group will have that policy enforced. If you then assign a different policy at the "Engineering" management group (e.g., "Require SQL Server encryption"), it will apply to all subscriptions under Engineering, in addition to the inherited root policy.
Overriding and Exemptions: Child management groups cannot override inherited policies, but they can add additional policies. You can also create exemptions (e.g., for a specific subscription) to exclude it from a policy assignment. Exemptions are explicit and must be created at the level of the resource or subscription.
Key Components, Tiers, and Limits
Management Group: A container for subscriptions and other management groups. Each management group has a name, a display name, and a unique ID.
Root Management Group: The top-level container. It has the ID of the Azure AD tenant.
Subscriptions: Azure subscriptions are the billing and resource containers. They are placed under management groups.
Hierarchy Depth: Maximum of 6 levels (root counts as level 0, so you can have 5 child levels).
Number of Management Groups: You can create up to 10,000 management groups in a single directory.
Number of Subscriptions per Management Group: No hard limit, but performance considerations apply.
There is no cost for using management groups; they are a free feature of Azure. However, the number of policy assignments and RBAC assignments can affect performance.
How It Compares to On-Premises Equivalent
In an on-premises environment, managing multiple departments or business units often involves separate Active Directory OUs (Organizational Units) with Group Policy Objects (GPOs) applied at each level. Management groups are the cloud equivalent of OUs. Azure Policy is like GPOs but for Azure resources. The key difference is that on-premises GPOs are applied to computers and users, while Azure Policy applies to Azure resources. Also, on-premises GPO inheritance can be blocked or enforced, whereas Azure Policy inheritance is always enforced (cannot be blocked by child management groups).
Azure Portal and CLI Touchpoints
Azure Portal:
Navigate to "Management groups" under "All services" or search for it.
You can view the hierarchy tree, create new management groups, move subscriptions, and assign policies or RBAC roles.
The root management group is visible but cannot be deleted.
Azure CLI:
Create a management group: az account management-group create --name "MyGroup" --display-name "My Group"
List management groups: az account management-group list
Add a subscription to a management group: az account management-group subscription add --name "MyGroup" --subscription "subscription-id"
Move a subscription: az account management-group subscription move --name "NewGroup" --subscription "subscription-id"
PowerShell:
- New-AzManagementGroup -GroupName "MyGroup" -DisplayName "My Group"
- Get-AzManagementGroup
- Add-AzManagementGroupSubscription -GroupName "MyGroup" -SubscriptionId "subscription-id"
Concrete Business Scenarios
Scenario 1: Global Company with Regional Compliance A multinational company has operations in the US, EU, and Asia. They create management groups for each region: "Americas," "Europe," "Asia." At the root, they assign a policy that requires all resources to have a cost center tag. Then, on the "Europe" management group, they assign a policy that restricts data storage to EU regions (due to GDPR). Subscriptions for European projects automatically inherit both policies.
Scenario 2: Departmental Isolation A university has departments: IT, Research, and Admin. Each department has its own subscriptions. They create management groups for each department. The central IT team assigns the "Allowed Resource Types" policy at the root to restrict certain expensive VM sizes. The Research department management group adds a policy to require encryption on all storage accounts. The Admin department adds a policy to require MFA on all admin accounts. All subscriptions under those management groups inherit the root policy plus their department's policy.
Scenario 3: Environment Segmentation A software company uses separate subscriptions for development, testing, and production. They create management groups "Dev," "Test," and "Prod" under a "Workloads" management group. At the root, they assign a policy to deny any resource creation outside of approved regions. On the "Prod" management group, they assign a policy to require audit logging on all resources. Developers in Dev subscriptions can still create resources, but they must comply with the region restriction from the root.
Common Mistakes and How to Avoid Them
Too deep hierarchy: Exceeding 6 levels is not allowed. Plan your structure to be no more than 5 levels deep (plus root).
Moving subscriptions without understanding inheritance: When you move a subscription to a different management group, it immediately inherits all policies from the new parent. This could accidentally apply restrictive policies that break existing resources. Always test in a non-production environment.
Assigning policies at root without exemptions: If you assign a deny policy at root, it applies to all subscriptions. If you later need an exception, you must create an exemption at the subscription or resource group level. Plan for exemptions early.
Not using management groups at all: Many beginners skip management groups and apply policies per subscription. This becomes unmanageable as the number of subscriptions grows. Always use management groups from the start.
Integration with Azure Policy and RBAC
Azure Policy: Policies assigned at a management group are inherited. You can also use policy initiatives (groups of policies) at management group level.
RBAC: Role assignments at a management group grant permissions to all subscriptions underneath. For example, assign the "Reader" role to a security team at the root management group, and they can read all resources in every subscription.
Azure Blueprints: Blueprints can define a set of policies, RBAC assignments, and resource templates that can be applied to a management group or subscription. This is useful for creating consistent environments.
Limits to Remember
Maximum 10,000 management groups per directory.
Maximum 6 levels of hierarchy (including root).
Maximum 200 policy assignments per management group.
Maximum 500 role assignments per management group.
Subscription moves are limited to 15 per hour per tenant.
These limits are important for exam questions that ask about scalability.
Access the Management Groups blade
In the Azure portal, navigate to 'Management groups' by searching for it in the top search bar or finding it under 'All services' > 'Management + governance'. If you have never used management groups before, you will see a welcome screen. Click 'Start using management groups' to proceed. The portal will show the root management group, which is automatically created for your Azure AD tenant. Note: You must have at least Contributor or Owner permissions at the root level to manage management groups. If you don't see the root group, you may need to elevate access.
Create a new management group
Click '+ Create' or 'Add management group'. You will be prompted to enter a Management group ID (this is the unique identifier, cannot be changed later) and a Display name (friendly name). Optionally, you can set the parent management group. By default, it is placed under the root. For example, create a group with ID 'sales' and display name 'Sales Department'. After creation, it appears in the hierarchy tree. You can create multiple levels by setting the parent to an existing management group.
Add subscriptions to the management group
Select the management group you just created. In the details pane, click 'Add subscription'. A list of subscriptions you have access to appears. Select one or more subscriptions and click 'Save'. The subscriptions are now children of that management group. They will immediately inherit any policies or RBAC assignments from the management group and its ancestors. You can also move subscriptions between management groups by selecting the subscription and using the 'Move' option.
Assign an Azure Policy at the management group
Navigate to the management group, then under 'Policies' click 'Assign policy'. Choose a policy definition (e.g., 'Allowed locations') and set parameters (e.g., allow only 'East US' and 'West Europe'). Then assign the policy. This policy will be inherited by all subscriptions under this management group and any child management groups. You can also exclude specific child management groups or subscriptions from the assignment using the 'Exclusions' option.
Assign RBAC roles at the management group
Select the management group, then click 'Access control (IAM)'. Click '+ Add role assignment'. Choose a role (e.g., 'Reader') and select a user or group. This grants the role at the management group scope, meaning the user will have that role on all subscriptions under this management group. For example, assign the 'Contributor' role to a DevOps team at the 'Engineering' management group so they can manage all engineering subscriptions.
Scenario 1: Large Enterprise with Multiple Business Units
A global manufacturing company, Contoso Ltd., has five business units: Automotive, Aerospace, Consumer Goods, Healthcare, and Energy. Each business unit has its own IT team and multiple Azure subscriptions (10-20 each). Without management groups, Contoso's central IT team would have to apply compliance policies (like requiring encryption on all storage accounts) to each of the 100+ subscriptions individually. This is not only time-consuming but also prone to errors—a subscription might be missed, creating a compliance gap.
Contoso creates a management group for each business unit under the root. They assign a baseline policy at the root that requires all resources to have a 'CostCenter' tag. Then, on each business unit management group, they assign additional policies specific to that unit (e.g., Healthcare requires HIPAA compliance). The central IT team also assigns the 'Reader' role to the compliance team at the root, giving them visibility into all subscriptions. This setup ensures consistent governance across 100+ subscriptions with minimal administrative overhead.
Scenario 2: SaaS Startup with Environment Separation
A SaaS startup, CloudSoft, uses Azure for its multi-tenant application. They have separate subscriptions for development, testing, staging, and production for each of their three product lines: AppA, AppB, and AppC. That's 12 subscriptions total. Without management groups, each subscription's policies must be managed individually, leading to configuration drift.
CloudSoft creates a management group called 'CloudSoft' under the root. Under that, they create 'AppA', 'AppB', and 'AppC' management groups. Under each product management group, they create 'Dev', 'Test', 'Staging', and 'Prod' management groups. They then place the appropriate subscriptions into each leaf management group. At the 'CloudSoft' management group, they assign a policy to deny any resource creation outside of approved regions (US regions only). On each 'Prod' management group, they assign a policy to require audit logging and encryption. This ensures that all production subscriptions have the same security baseline, while development subscriptions are less restricted but still comply with regional restrictions.
What Goes Wrong When Set Up Incorrectly
A common mistake is creating a flat hierarchy (all subscriptions directly under root) and then moving subscriptions later without understanding inheritance. For example, if a subscription is moved from a management group with a 'Deny' policy to one without, the deny policy is removed, potentially allowing non-compliant resources. Another mistake is assigning roles at the root management group too broadly—giving 'Contributor' to all users can lead to accidental modifications. Also, forgetting to create exemptions for legitimate exceptions can block critical business operations. For instance, a policy that denies all VM sizes except standard_D2s_v3 might break a legacy application that requires a larger VM. Without an exemption, the application cannot be deployed.
Objective 2.1: Describe Azure Management Groups Hierarchy
The AZ-900 exam tests your understanding of management groups as a governance tool. Specifically, you need to know:
The purpose of management groups: to manage access, policy, and compliance across multiple subscriptions.
The hierarchy: root management group -> child management groups -> subscriptions.
Inheritance: policies and RBAC assignments are inherited from parent to child.
Limits: up to 10,000 management groups per directory, max 6 levels deep (including root).
The root management group is automatically created and cannot be deleted.
You must have appropriate permissions (Owner or Contributor) at the root to manage management groups.
Most Common Wrong Answers and Why Candidates Choose Them
"Management groups can be used to manage billing." This is wrong because billing is managed at the subscription level, not management groups. Management groups are for governance, not billing. Candidates confuse management groups with billing scopes (e.g., EA departments).
"Management groups can replace resource groups." Wrong. Resource groups are containers for resources within a subscription. Management groups contain subscriptions. They serve different purposes. Candidates think both are containers, but they operate at different levels.
"Inheritance can be blocked at child management groups." Wrong. In Azure, inheritance is automatic and cannot be blocked. This is different from on-premises Active Directory where GPO inheritance can be blocked. Candidates familiar with on-premises AD often choose this wrong answer.
"You can have up to 6 levels of management groups including the root." This is actually correct, but many candidates think it's 6 levels excluding root. The exam may phrase it as "6 levels deep" or "5 child levels." Read carefully.
Specific Terms and Values That Appear Verbatim on the Exam
"Root management group" or "Tenant root group"
"Inheritance"
"Up to 10,000 management groups per directory"
"Up to 6 levels" (including root)
"Azure Policy" and "RBAC" as what can be assigned at management group scope
"Subscriptions" are placed under management groups
Edge Cases and Tricky Distinctions
The exam may ask if you can assign a policy to a management group that has no subscriptions. Yes, you can, but it will have no effect until subscriptions are added.
You can move a subscription from one management group to another, but the subscription's resources are not affected—only governance changes.
Management groups are global to the Azure AD tenant, not regional.
You cannot nest management groups across tenants.
Memory Trick: The "Russian Doll" Model
Think of management groups as nesting dolls. The largest doll (root) contains smaller dolls (child management groups), which contain even smaller dolls (subscriptions). Any paint (policy or RBAC) applied to a larger doll automatically appears on all smaller dolls inside it. You cannot remove paint from a smaller doll that came from a larger doll. This helps remember inheritance and the inability to block it.
Decision Tree for Eliminating Wrong Answers
When you see a question about management groups:
If the answer mentions billing, eliminate it.
If it says inheritance can be blocked, eliminate it.
If it says management groups contain resource groups, eliminate it.
If it says management groups are used for RBAC and policy assignment, keep it.
If it mentions a limit of 10,000 or 6 levels, verify the exact number.
Management groups are containers for subscriptions that enable governance at scale via Azure Policy and RBAC.
The root management group is automatically created per Azure AD tenant and cannot be deleted.
Inheritance is automatic and cannot be blocked; policies and RBAC assignments flow from parent to child.
Maximum of 10,000 management groups per directory and 6 levels of hierarchy (including root).
Management groups are free and do not incur any cost.
You can assign Azure Policy and RBAC roles at management group scope.
Subscriptions can be moved between management groups, but must be in only one management group at a time.
These come up on the exam all the time. Here's how to tell them apart.
Management Groups
Contain subscriptions
Used for governance across multiple subscriptions
Inheritance of policies and RBAC
Hierarchy up to 6 levels
Free feature
Resource Groups
Contain resources (VMs, databases, etc.)
Used for organizing resources within a single subscription
No inheritance across resource groups
Flat structure (no nesting)
Free feature
Mistake
Management groups can be used to organize resources like resource groups.
Correct
Management groups contain subscriptions, not resources. Resource groups are within subscriptions. Management groups are for organizing subscriptions for governance.
Mistake
You can delete the root management group.
Correct
The root management group is automatically created and cannot be deleted. It is the top-level container for all management groups and subscriptions in the tenant.
Mistake
Inheritance from parent management groups can be blocked by child management groups.
Correct
Inheritance is automatic and cannot be blocked. Child management groups always inherit policies and RBAC assignments from their ancestors. You can only add additional assignments or create exemptions.
Mistake
Management groups are regional and can be used to enforce data residency.
Correct
Management groups are global to the Azure AD tenant. They are not region-specific. However, you can use Azure Policy assigned at a management group to restrict resources to specific regions.
Mistake
Each subscription must be in a management group.
Correct
Subscriptions can exist outside of a management group (directly under the root). However, best practice is to place every subscription in a management group for consistent governance.
You can create up to 10,000 management groups per Azure AD directory. This includes the root management group. The hierarchy can be up to 6 levels deep (including the root). These limits are important for exam questions about scalability.
Yes, you can assign Azure Policy at the management group scope. The policy will be inherited by all child management groups and subscriptions. This is a key feature for central governance. You can also assign policy initiatives (groups of policies) at the management group level.
When you move a subscription, it immediately inherits all policies and RBAC assignments from the new parent management group and its ancestors. It loses inheritance from the old parent. Existing resources are evaluated against the new policies. This can cause compliance changes, so always test in a non-production environment.
No, a subscription can only be in one management group at a time. However, it can be moved between management groups. The subscription's resources remain unchanged, but governance policies change.
No, management groups are a free feature in Azure. There is no cost associated with creating or using management groups. However, the policies and RBAC assignments you apply may incur costs if they enable other services (e.g., Azure Policy's compliance reporting may have costs).
To create or manage management groups, you need at least Contributor or Owner permissions at the root management group. The default Global Administrator in Azure AD has Owner permissions on the root. You can also grant specific users the 'Management Group Contributor' role.
No, the root management group is automatically created and cannot be deleted. It is the top-level container for all management groups and subscriptions in the tenant. You can rename it but not delete it.
You've just covered Azure Management Groups Hierarchy — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?