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.

How the hierarchy is managed¶

The whole hierarchy is Terraform in t0-azure-management-groups, one file per group. It's Tier 0: moving a group or subscription changes what it inherits from mg-intermediate-root.

Any engineer can write a change and open an MR. CI plans it with a read-only identity.
A senior engineer reviews and merges, checks the saved plan, then activates (tier 0) Management Groups in PIM and gives CI's write identity Management Group Contributor for 30 minutes.
CI applies the saved plan and cleans up after itself. Azure removes the access when the 30 minutes end.

No pipeline holds write access to the hierarchy between applies.

How to make a change: Manage Management Groups
Why it works this way: Tier 0 Just-in-Time CI Apply

This project never assigns roles

Management Group Contributor can't grant access, so role_assignments stays empty on every group. Role assignments at management groups are made by the projects that own them (for example azure-privileged-access-grants), not here.

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.

High scope means high tier

Inheritance cuts both ways. Owner, User Access Administrator or unconditioned Role Based Access Control Administrator at the tenant root or mg-intermediate-root is Tier 0: it reaches every subscription. Grant the narrowest role at the lowest scope that works, through PIM. See Role Tier Mapping.

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.