Management Group Hierarchy¶

The management group hierarchy is the governance backbone of an Azure tenant. It determines where policies are applied, which teams can access which subscriptions, and how budgets and compliance are reported. Getting the structure right at the start avoids expensive reorganisation later.

The hierarchy¶

The hierarchy follows the CAF enterprise-scale pattern with an intermediate root below the Azure tenant root. This is deliberate — assigning policies and roles at the mg-intermediate-root level rather than the Azure tenant root group gives full control without granting permissions above the tenant boundary.

Tenant Root Group  (Azure-managed, not touched)
└── intermediate-root
    ├── platform
    │   ├── connectivity
    │   ├── identity
    │   └── management
    ├── landingzones
    │   └── online
    ├── sandboxes
    ├── quarantine
    └── decommissioned

What each management group is for¶

Intermediate Root¶

The top of the controlled hierarchy. Policies and role assignments placed here inherit to every subscription in the tenant. Used for organisation-wide baselines only — tagging standards, Defender for Cloud enablement, and platform team access.

mg-platform¶

Groups all platform subscriptions that provide shared services to the rest of the organisation. The platform team manages these subscriptions directly. Child MGs map to CAF platform archetypes.

Child MG	Purpose	Subscription
`mg-connectivity`	Hub networking — ExpressRoute, VPN, DNS, firewalls	`connectivity-prod-westeu`
`mg-identity`	Identity services — Entra ID, AD DS	(reserved)
`mg-management`	Central logging, monitoring, backup	(reserved)

mg-landingzones¶

Parent for all workload subscriptions. Workload teams land here. Child MGs differentiate governance posture by workload type.

Child MG	Purpose	Governance posture
`mg-online`	Internet-facing workloads	Stricter egress, WAF required
(mg-corp)	Internal workloads	No public IPs, private endpoints required

mg-sandboxes¶

Isolated developer and experimentation subscriptions. Looser policy enforcement to enable learning and prototyping. No production data permitted. Subscriptions here should be short-lived.

mg-quarantine¶

Restricted area for subscriptions under investigation or with suspected policy violations. Highly restrictive deny policies applied to limit blast radius. Move here before deciding whether to remediate or decommission.

mg-decommissioned¶

Final placement for subscriptions being retired. Policies prevent new resource creation. Resources should be deleted before the subscription is cancelled.

Role assignments at management group scope¶

Role assignments placed at a management group scope are inherited by every child management group, subscription, resource group, and resource beneath it. This is the mechanism that gives the platform team consistent access across all subscriptions without per-subscription grants.

Tip

Assign roles at the highest appropriate scope. A single Owner grant at mg-intermediate-root gives the platform engineering group access to every subscription that exists now and any that are added in the future — without touching individual subscriptions.

Naming convention¶

All management groups follow the mg-{name} prefix. The name value (the immutable Azure identifier) is always lowercase with hyphens. The display_name is the human-readable label shown in the portal.

Warning

The management group name field is immutable in Azure. Changing it destroys the management group and removes all RBAC assignments scoped to it. Child management groups are moved to the tenant root automatically by Azure. Plan the hierarchy carefully before creating groups.