Microsoft AZ-104: Management Groups That Scale
Azure management groups are the governance hierarchy above subscriptions. They let platform teams apply Azure Policy, role assignments, and compliance conditions to groups of subscriptions instead of repeating configuration one subscription at a time. That makes the hierarchy a control-plane architecture decision: the shape of the tree determines what inherits, who can administer which scope, how new subscriptions are placed, and how easy it is to explain why a workload receives a particular policy.
Microsoft’s current Cloud Adoption Framework recommends a relatively simple management-group hierarchy aligned to the Azure landing zone operating model. The guidance emphasizes subscription democratization, policy-driven governance, and separation of platform resources from workload landing zones. A hierarchy should therefore express durable governance differences—not mirror the org chart, every environment, or every application team.
Management groups are a core platform pattern inside Azure Architecture in Practice.
Design from policy inheritance
Every subscription belongs beneath the tenant root management group, and governance applied at a parent management group can flow to descendants.
Azure governance becomes easier when the hierarchy reflects where policy and access should differ rather than where reporting lines happen to differ this quarter.
Before adding a new branch, identify the control that cannot be expressed cleanly through the existing hierarchy.
Keep the hierarchy shallow
Deep trees create more inheritance paths, more role scopes, and more places where policy exemptions or assignments can become difficult to reason about.
Use a small number of levels with broad, durable categories such as platform, landing zones, sandbox, decommissioned, and specific regulatory or sovereignty branches where the business requires them.
Landing-zone governance should remain understandable to workload owners who need to know which controls their subscription inherits.
Separate platform and workload subscriptions
Connectivity, identity, management, and security platform subscriptions usually have different owners and governance from application landing zones.
Microsoft’s current landing-zone architecture explicitly separates centralized platform resources from workload landing zones.
This allows platform teams to manage shared foundations while workload teams receive autonomy inside subscriptions governed by inherited policy.
Use subscriptions as the workload unit
Current Cloud Adoption Framework guidance treats subscriptions as foundational management boundaries and encourages subscription democratization.
Subscription design should therefore work with the management-group hierarchy rather than using management groups to compensate for an overstuffed shared subscription.
A new application environment often deserves a new subscription when isolation, ownership, policy, or lifecycle needs differ materially.
Apply policy high enough, access low enough
Azure Policy benefits from broad management-group assignment when the control is truly universal for descendants.
Human workload administration, however, is usually safer at subscription or resource-group scope.
Azure RBAC should avoid granting application teams broad management-group privileges merely because their workloads sit beneath that branch.
Protect the root and upper hierarchy
The root management group has tenant-wide inheritance implications.
Limit who can create or move management groups and subscriptions at upper scopes, and review root-level policy and RBAC changes like other high-impact control-plane changes.
Azure activity logs can help audit hierarchy moves and management-group operations.
Use hierarchy protection and subscription vending
Organizations should control who can create management groups and where new subscriptions are placed.
A subscription-vending process can create the subscription, place it in the correct management group, apply standard tags and access, and return the landing zone ready for the workload team.
This reduces the chance that new subscriptions remain at the root with missing governance.
Design for regulatory exceptions without cloning the tree
Some workloads need distinct sovereignty, geography, security, or compliance policies.
Create a separate management-group branch when those controls are durable across several subscriptions, not because one application has one temporary exception.
Use policy exemptions for bounded exceptions rather than proliferating permanent hierarchy branches.
Test moves before production reorganization
Moving a subscription changes its inherited policies and access context.
Subscription governance should include an impact review before moving production subscriptions between branches.
For AZ-104 and AZ-305, the durable model is simple hierarchy → subscription landing zones → broad policy inheritance → narrow access → controlled vending and moves.
Management groups should not be used as a cost-center mirror when tags, billing scopes, or Cost Management can answer the reporting question without changing governance. The hierarchy is too operationally important to become a reporting taxonomy that changes with finance organization.
Likewise, avoid one management group per application. That pattern creates a deep tree and makes platform policy harder to reason about. Application isolation normally belongs at subscription scope, while management groups express shared policy archetypes across many landing zones.
Platform teams should publish a diagram and a short decision table showing what each branch means, which policies are assigned, which roles are allowed, and which subscription types belong there. A hierarchy that requires tribal knowledge is not scalable.
Review the tree after major acquisitions, regulatory changes, or operating-model changes—but resist casual reshaping. The best hierarchy is stable enough that subscription vending, policy as code, and RBAC patterns can rely on it for years.
Policy architecture should make exceptions visible. If one workload needs a different control, prefer an exemption or a lower-scope policy override pattern where supported instead of creating a new branch for one temporary exception. Hierarchy changes should represent durable governance differences that several subscriptions share.
Management-group role assignments should remain rare. Broad platform roles can be appropriate for central security or networking teams, but application owners generally need access only to their landing-zone subscription. Keep high-scope role assignments in PIM where possible and review them regularly because one assignment can affect every descendant subscription.
Hierarchy moves deserve change control because inherited policies can begin or stop applying immediately after the move. Before relocating a subscription, compare current and target assignments, exemptions, RBAC, Defender settings, networking assumptions, and cost governance. Test high-impact moves in nonproduction first.
New subscriptions should not stay under the root longer than necessary. A vending workflow should place them in the intended management group and apply the standard baseline during creation. This reduces a dangerous period where the subscription exists without inherited policy.
Management-group names should describe governance intent rather than current organization charts. Terms such as Platform, Landing Zones, Sandbox, Decommissioned, Regulated, or Sovereign can remain stable through reorganizations. Department names often create pressure to restructure the tree whenever reporting lines change.
Policy as code becomes easier when the hierarchy is stable. Initiative assignments, exemptions, RBAC, and subscription placement can be versioned against known management-group IDs. Frequent hierarchy churn creates unnecessary deployment complexity and audit noise.
Cost and compliance reporting can still aggregate across management groups, but reporting alone should not drive the tree. Tags, Cost Management scopes, Resource Graph, and dashboards can solve many reporting needs without changing the policy inheritance structure.
Decommissioned subscriptions should have their own lifecycle path. Moving them to a dedicated management group can apply restrictive policy, remove ordinary workload administration, and make cleanup visible before final cancellation.
The hierarchy should also support mergers and acquisitions. Newly acquired subscriptions can enter a quarantine or transition branch with stricter controls while identity, networking, and workload ownership are assessed, then move into the normal landing-zone structure once the environment meets the enterprise baseline.
Platform teams should monitor hierarchy changes and policy drift. A management group added outside the supported process or a subscription moved manually can create a governance gap even when every individual resource looks compliant. Treat hierarchy state as part of platform configuration that should be continuously reconciled.
Hierarchy IDs should be treated as stable platform identifiers. Display names can change, but automation, Policy assignments, and references should use the immutable management-group ID where appropriate. Pick IDs carefully when the hierarchy is first created because changing naming conventions later is easier at the display layer than at the identifier layer.
Platform architecture should also define who may move subscriptions between management groups. A move can change inherited security, compliance, networking, and cost policy instantly. Restrict move permissions and require change evidence for production subscriptions.
Management groups should be included in disaster-recovery and tenant-recovery documentation even though they are global control-plane constructs. Teams need exported policy-as-code, hierarchy definitions, role assignments, and exception records so the governance model can be reconstructed or audited after a major administrative incident.
Keep upper-level assignments intentionally small. The closer a policy or role assignment is to the root, the more expensive a mistake becomes. Prefer tenant-wide controls only when every descendant truly needs them, and use lower branches for environment or workload-specific requirements.
The scalable outcome is a hierarchy that rarely changes because it models governance archetypes, while subscriptions move through that hierarchy as workloads are created, regulated, merged, suspended, or retired.
Azure Policy exemptions should be preferred over structural changes when one resource or subscription has an approved temporary exception. Exemptions preserve compliance visibility and can include expiry, while a new management-group branch can permanently complicate inheritance.
Review the root management group with extra caution. Because all subscriptions live below it, role or policy assignments at root scale globally. Use it only for controls the organization truly wants everywhere and keep the assignment set small enough to audit.
When management groups are created through automation, validate the intended parent explicitly. A scripting mistake that creates a branch at the wrong level can change inheritance for every subscription later placed there. Platform tests should compare the deployed hierarchy with the source-controlled target.
Management-group design is successful when new subscriptions can be classified quickly, platform controls apply predictably, workload teams understand their inherited guardrails, and the tree does not need restructuring every time the business reorganizes.