This chapter covers Management Groups and Subscriptions, the top-level building blocks of Azure governance. Understanding how to organize and manage subscriptions within a management group hierarchy is critical for the AZ-104 exam, as it appears in roughly 10-15% of questions related to Identity Governance (Objective 1.2). You will learn the structure, inheritance rules, and how to apply Azure Policy and RBAC at scale using management groups.
Jump to a section
Think of an Azure tenant as a multinational corporation. The CEO (Global Administrator) sets company-wide policies, like 'no expense over $10,000 without VP approval.' The corporation has divisions: North America, Europe, Asia. Each division has a VP who can apply stricter policies within their division, like 'no expense over $5,000 without my approval.' Within each division, there are departments like Engineering, Sales, etc., each with a manager. The division VPs and department managers can create projects (resource groups) and assign resources, but they must follow policies from above. The CEO can delegate policy authority to division VPs, but cannot override a policy set at a higher level (policy inheritance is like corporate rules flowing down). The hierarchy allows the CEO to manage the entire company with a single policy, while giving VPs autonomy to tailor rules for their region. If a division violates a corporate policy, the CEO can audit via Azure Policy and compliance reports. This mirrors Management Groups: the root management group is the CEO; child management groups are divisions; subscriptions are departments; resource groups are projects. Azure Policy at the root applies to all, but can be overridden only by a more restrictive policy at a lower level (effective policy is the most restrictive). Just as a VP cannot allow expenses over $10,000 if the CEO forbids it, a subscription cannot relax a policy set at a higher management group.
What are Management Groups?
Management Groups are containers that help you manage access, policy, and compliance across multiple Azure subscriptions. They form a hierarchy that can be up to six levels deep (not including the root management group or the subscription level). The root management group is automatically created in each Azure AD tenant and is the top-level container. All subscriptions and management groups within the tenant are descendants of the root. You cannot move or delete the root management group.
Why Use Management Groups?
Without management groups, you would have to assign Azure Policy or RBAC roles to each subscription individually. With management groups, you assign policies and roles once at a high level, and they inherit down to all subscriptions and resource groups under that management group. This is essential for enterprises with hundreds of subscriptions. For example, you can enforce a policy that all resources must be in a specific region by assigning it to a management group containing all subscriptions.
Hierarchy and Inheritance
The hierarchy is: Root Management Group -> Child Management Groups (up to 6 levels) -> Subscriptions -> Resource Groups -> Resources.
Azure Policy and RBAC assignments at a management group level are inherited by all child management groups, subscriptions, resource groups, and resources.
Inheritance is additive for RBAC: a user assigned Contributor at the root inherits Contributor on everything below, unless explicitly denied.
For Azure Policy, inheritance follows the most restrictive effective policy. If a parent policy denies a resource type and a child policy allows it, the deny prevails. This is called "effective policy" or "cumulative effect."
Creating and Managing Management Groups
You can create management groups using the Azure portal, Azure PowerShell, Azure CLI, or ARM templates. Each management group must have a unique name within the tenant and a display name. The ID is a GUID.
Azure CLI example:
az account management-group create --name "Contoso" --display-name "Contoso"To add a subscription to a management group:
az account management-group subscription add --name "Contoso" --subscription "<subscription-id>"To move a subscription:
az account management-group subscription move --name "Contoso" --subscription "<subscription-id>" --destination "/providers/Microsoft.Management/managementGroups/NewGroup"Permissions and RBAC
To create management groups, you need the Management Group Contributor role at the root management group or at the parent management group. The Management Group Reader role allows viewing the hierarchy and assignments. The root management group has a special role: Management Group Administrator (built-in) that allows full control over the management group hierarchy, but not over subscriptions or resources within (unless also assigned other roles).
By default, the Global Administrator in Azure AD is assigned the User Access Administrator role at the root management group, which allows them to elevate access to manage all subscriptions. This is a security consideration: Global Admins can grant themselves any role on any subscription via the root.
Subscriptions
An Azure subscription is a logical container that links to an Azure AD tenant. It provides billing, access control, and resource limits. Every resource must be in a subscription. Subscriptions have service limits (e.g., 980 resource groups per subscription, 800 VM cores per region).
Subscriptions can be of different types: Pay-As-You-Go, Enterprise Agreement, Microsoft Customer Agreement, etc. For the exam, know that each subscription trusts only one Azure AD tenant, but a tenant can have multiple subscriptions.
Moving Subscriptions
You can move a subscription to a different management group as long as you have write permissions on both the subscription and the target management group. There are some restrictions:
The subscription cannot be moved if it has Azure Policy or RBAC assignments that conflict with the target hierarchy.
The subscription cannot be moved if it is part of an Azure Blueprint assignment.
Moving a subscription does not affect any existing resources or configurations.
Azure Policy at Management Group Level
Azure Policy definitions can be assigned at the management group level. When you assign a policy at a management group, it applies to all subscriptions and resource groups under that group. You can also create policy initiatives (groups of policy definitions) at the management group level.
Policy parameters can be used to customize assignments per child scope. For example, a policy that requires a tag 'CostCenter' can have different default values for different child management groups.
RBAC at Management Group Level
You can assign Azure RBAC roles (Owner, Contributor, Reader, etc.) at the management group scope. This grants permissions to all subscriptions under that management group. This is powerful for delegating administration. For example, you can assign a group of network administrators the Network Contributor role at a management group containing all networking subscriptions.
Azure Blueprints
Azure Blueprints allow you to define a repeatable set of Azure resources, policies, and RBAC assignments. Blueprints can be assigned to management groups or subscriptions. When assigned to a management group, the blueprint artifacts are applied to all subscriptions under that group. Blueprints support versioning and locking.
Defaults and Limits
Maximum depth of management group hierarchy: 6 levels (root is level 0, then 1-6).
Maximum number of management groups in a tenant: 10,000.
Maximum number of subscriptions per management group: unlimited.
A subscription can only belong to one management group at a time.
The root management group cannot be moved or deleted.
Management group names must be unique within the tenant.
The display name can be up to 90 characters.
Best Practices
Use a flat hierarchy (2-3 levels) to simplify management.
Align management groups with your organizational structure (e.g., by department, geography, or environment).
Apply common policies at the highest level possible.
Use RBAC at management group scope to delegate administrative responsibilities.
Avoid assigning roles to the root management group unless absolutely necessary (security risk).
Use Azure Policy initiatives to group related policies.
Exam Relevance
For AZ-104, you need to know:
How to create and manage management groups (portal, CLI, PowerShell).
How to move subscriptions between management groups.
Inheritance rules for Azure Policy and RBAC.
The difference between management groups and subscriptions.
The root management group and its special permissions.
The maximum hierarchy depth (6 levels).
The fact that management groups can contain both subscriptions and other management groups.
Common exam scenarios:
A company has multiple departments with separate subscriptions. They want to enforce a policy that all resources must be tagged with a department name. You create a management group for each department and assign the policy at the management group level.
A global administrator wants to delegate management of all subscriptions to a team. Instead of assigning roles to each subscription, assign the role at the root management group.
A subscription must be moved from one management group to another due to reorganization. You need to ensure no conflicting policies exist.
Verification Commands
Azure CLI:
# List management groups
az account management-group list
# Show hierarchy
az account management-group show --name "Contoso" --expand
# Get effective permissions
ez account management-group get-effective-permission --name "Contoso"PowerShell:
# Get management group
Get-AzManagementGroup -GroupName "Contoso"
# Move subscription
Move-AzSubscription -SubscriptionId "<sub-id>" -Destination "/providers/Microsoft.Management/managementGroups/NewGroup"Create a Management Group
In the Azure portal, navigate to Management Groups. Click 'Create' and provide a unique name (e.g., 'IT-Department') and a display name. The system generates a GUID as the ID. Alternatively, use Azure CLI: `az account management-group create --name 'IT-Department' --display-name 'IT Department'`. This creates the container. You must have **Management Group Contributor** permissions at the root or parent management group. The new management group appears as a child of the root by default, but you can specify a parent using `--parent` parameter. The creation is immediate and does not affect existing subscriptions.
Add Subscriptions to Management Group
Once the management group exists, you can add subscriptions. In the portal, select the management group, click 'Add subscription', and choose from the list. Using CLI: `az account management-group subscription add --name 'IT-Department' --subscription '<subscription-id>'`. The subscription moves from its current parent (which could be the root or another management group) to the new group. This action is reversible. The subscription retains all its resources, but now inherits policies and RBAC from the new management group hierarchy. Ensure no conflicting policies exist; otherwise, the move may fail.
Assign Azure Policy at Management Group
Navigate to Azure Policy in the portal. Click 'Assignments' and then 'Assign policy'. Set the scope to the management group (e.g., 'IT-Department'). Select a policy definition (e.g., 'Allowed locations'). Configure parameters (e.g., allowed regions). Click 'Assign'. This policy now applies to all subscriptions and resource groups under that management group. Inheritance means any new subscriptions added later also get the policy. The policy assignment can be excluded at child scopes (subscription or resource group) if needed, but the exclusion must be explicitly configured.
Assign RBAC Role at Management Group
Go to the management group in the portal. Click 'Access control (IAM)'. Click 'Add role assignment'. Select a role (e.g., 'Contributor'). Select a user, group, or service principal. Click 'Save'. The user now has Contributor permissions on all subscriptions and resource groups under that management group. This is efficient for delegating administration. For example, assign the 'Network Contributor' role to a network team at a management group containing all networking subscriptions. The user can manage virtual networks across subscriptions without needing access to each subscription individually.
Move a Subscription Between Management Groups
To move a subscription, you need write access on the subscription and the target management group. In the portal, go to the subscription, click 'Move' under 'Management groups', and select the new parent. Using CLI: `az account management-group subscription move --name 'IT-Department' --subscription '<sub-id>' --destination '/providers/Microsoft.Management/managementGroups/NewGroup'`. The move is immediate. The subscription's resources are unaffected, but it now inherits policies and roles from the new hierarchy. The move may fail if the subscription has a policy assignment that conflicts with the target management group's policies (e.g., a deny policy at the target that would block existing resources). You must resolve conflicts before moving.
Enterprise Scenario: Multinational Corporation with Regional Compliance
A global company with operations in North America, Europe, and Asia must comply with regional data residency laws. They create a management group hierarchy: Root -> Regions (NA, EU, ASIA) -> Departments (Engineering, Sales, etc.) -> Subscriptions. They assign Azure Policy at the Region management group to restrict resource locations to approved regions (e.g., EU group allows only West Europe and North Europe). They also assign RBAC roles at the Region level to regional IT teams, giving them Owner on all subscriptions in their region. This ensures compliance without micromanaging each subscription. A common problem: a global admin accidentally assigns a policy at the root that contradicts a regional policy (e.g., root allows all regions, but EU group denies non-EU). The effective policy is the most restrictive, so the EU deny wins. The global admin must understand inheritance to avoid confusion.
Scenario: Departmental Isolation with Centralized Billing
A large enterprise has separate IT departments for Development, Test, and Production. Each department has multiple subscriptions. The finance team wants a single billing view. They create management groups: Root -> Environments (Dev, Test, Prod) -> Departments. They assign a policy at the Environments group to enforce naming conventions (e.g., all resources must start with 'dev-', 'test-', or 'prod-'). They also assign a custom RBAC role at the Environments group to allow the finance team to read cost data across all subscriptions. The departments can still manage their own resources within the inherited constraints. Misconfiguration: if the finance team is assigned the 'Billing Reader' role at the root, they can see all billing data, but if they are assigned at the Environments group, they only see data for subscriptions under that group, which may be intended.
Scenario: Merger and Acquisition Integration
Company A acquires Company B. Company B has its own Azure subscriptions and management groups. To integrate, Company A creates a management group called 'Acquired' under its root and moves Company B's subscriptions into it. However, Company B had policies that conflict with Company A's policies (e.g., different allowed locations). The move fails because of policy conflicts. The solution: first, remove or modify conflicting policies on Company B's subscriptions or management groups, or adjust Company A's policies to allow exceptions. This requires careful planning. Performance: moving hundreds of subscriptions can take time, but there is no limit on batch moves. The key is to ensure no policy or RBAC conflicts exist at the target hierarchy.
What AZ-104 Tests
This topic falls under Objective 1.2: 'Manage Azure identities and governance.' Specifically, you need to be able to 'manage management groups and subscriptions.' The exam expects you to know how to create and manage management groups, move subscriptions, and understand inheritance of Azure Policy and RBAC. The exam also tests the root management group's special role (Global Admin gets User Access Administrator at root).
Common Wrong Answers
'Management groups can be nested up to 10 levels.' The correct maximum is 6 levels (plus root). Candidates often choose 10 because it's a common number in other contexts.
'Moving a subscription changes its billing ownership.' Moving a subscription does not change billing; it only changes the management hierarchy. Billing is tied to the billing account, not management groups.
'Azure Policy assigned at a management group overrides a policy assigned at a subscription.' Actually, the effective policy is the most restrictive. If a management group policy denies a resource and a subscription policy allows it, the deny wins. Candidates often think the assignment at the lower scope overrides, but that is only true for RBAC (additive), not for policy (cumulative with most restrictive).
'You need to be a Global Administrator to create management groups.' You need the Management Group Contributor role at the root or parent, not necessarily Global Admin. However, Global Admin can assign themselves that role.
Specific Numbers and Terms
Maximum management group depth: 6 levels.
Maximum management groups per tenant: 10,000.
Root management group name: 'Tenant Root Group' (display name) with ID as the tenant GUID.
Built-in roles: Management Group Contributor, Management Group Reader, Management Group Administrator.
The command az account management-group create is used.
The '--expand' flag with az account management-group show shows the hierarchy.
Edge Cases
A subscription can only belong to one management group at a time.
You cannot move a subscription if it has a policy assignment that conflicts with the target management group's policies. The exam may present a scenario where a move fails and ask you to identify the cause.
The root management group cannot be deleted or moved.
If you delete a management group, all child management groups and subscriptions are moved to its parent (usually root).
How to Eliminate Wrong Answers
For inheritance questions, remember: RBAC is additive (cumulative), Azure Policy is most restrictive (deny overrides allow).
For management group creation, look for the role requirement: Management Group Contributor, not Global Admin.
For subscription moves, check for policy conflicts first.
Always verify the depth limit: 6 levels, not 5 or 10.
Management groups can be nested up to 6 levels deep (root is level 0).
Azure Policy inheritance is cumulative and the most restrictive policy wins.
RBAC inheritance is additive; permissions accumulate across scopes.
To create a management group, you need the Management Group Contributor role at the root or parent.
Moving a subscription does not change its billing or resources; it only changes the management hierarchy.
The root management group cannot be moved or deleted.
Global Administrators are assigned User Access Administrator at the root management group by default.
A subscription can only belong to one management group at a time.
These come up on the exam all the time. Here's how to tell them apart.
Management Groups
Containers for organizing subscriptions and other management groups.
Provide a hierarchy for applying Azure Policy and RBAC at scale.
Can be nested up to 6 levels deep.
Do not have service limits (except max 10,000 per tenant).
No direct resource deployment; they only contain subscriptions and management groups.
Subscriptions
Containers for resources and resource groups.
Provide billing and access control boundaries.
Cannot be nested; they are leaf nodes in the hierarchy.
Have service limits (e.g., 980 resource groups, 800 VM cores per region).
Resources are deployed directly into a subscription.
Mistake
Management groups can be nested up to 10 levels.
Correct
The maximum depth is 6 levels (not including the root management group). Any deeper hierarchy is not allowed.
Mistake
Moving a subscription changes the billing account.
Correct
Moving a subscription only changes its management group parent. Billing is tied to the billing account (e.g., EA enrollment, MCA billing profile), which remains unchanged.
Mistake
Azure Policy assigned at a lower scope overrides a policy at a higher scope.
Correct
For Azure Policy, the effective policy is the most restrictive. If a higher-level policy denies a resource, a lower-level allow does not override it. Only RBAC is additive.
Mistake
Only Global Administrators can create management groups.
Correct
Any user with the Management Group Contributor role at the root or parent management group can create management groups. Global Administrators are not required, though they can assign themselves that role.
Mistake
A subscription can belong to multiple management groups.
Correct
A subscription can only be a child of one management group at a time. It cannot be in multiple management groups simultaneously.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The maximum depth is 6 levels, not including the root management group. The root is level 0, and you can have child management groups up to level 6. This means you can have a hierarchy like Root -> Level1 -> Level2 -> ... -> Level6. Attempting to create a level 7 will result in an error.
Yes, you can move a subscription as long as you have write permissions on the subscription and the target management group. The move is immediate. However, the move may fail if there are conflicting Azure Policy assignments (e.g., the target management group has a policy that denies resources currently in the subscription). You must resolve such conflicts before moving.
Azure Policy assignments at a management group are inherited by all child management groups, subscriptions, resource groups, and resources. If multiple policies apply, the effective policy is the most restrictive (deny overrides allow, audit overrides nothing). You can exclude child scopes from policy assignments, but you cannot override a deny with an allow at a lower scope.
To create or manage management groups, you need the Management Group Contributor role at the root or parent management group. To view the hierarchy, you need the Management Group Reader role. There is also a Management Group Administrator role that grants full control over the management group hierarchy, but not over subscriptions or resources.
Yes, you can delete a management group if you have the appropriate permissions. When you delete a management group, all child management groups and subscriptions are moved to the parent management group (usually the root). You cannot delete the root management group.
A management group is a container for organizing subscriptions and other management groups, used for policy and RBAC inheritance. A subscription is a container for resources and resource groups, used for billing and access control. Subscriptions are leaf nodes in the hierarchy; they cannot contain other subscriptions or management groups.
In the Azure portal, navigate to the management group, click 'Access control (IAM)', then 'Add role assignment'. Select a role (e.g., Contributor), select a user or group, and save. The role applies to all subscriptions and resource groups under that management group. You can also use Azure CLI: `az role assignment create --assignee <object-id> --role Contributor --scope /providers/Microsoft.Management/managementGroups/<group-name>`.
You've just covered Management Groups and Subscriptions — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?