Management Group
A container above subscriptions used to organize multiple subscriptions under a shared hierarchy, allowing RBAC roles and Azure Policies to be applied once and inherited down to every subscription and resource group beneath it.
Management Group
Management Groups let you govern many subscriptions at once — apply a policy or role assignment at the top, and it cascades down automatically.
Why It Matters in Production
CRED groups its prod, staging, and sandbox subscriptions under a single management group so a company-wide policy (like "deny public IP creation") is enforced everywhere without repeating the assignment per subscription.
az account management-group create --name cred-prod-mgTipKeep the management group hierarchy shallow (3-4 levels max) — deep nesting makes policy inheritance hard to reason about during incident response.
Frequently Asked Questions
Why would an organization need Management Groups instead of just applying policy per subscription?
Subscriptions in Azure are billing and scaling boundaries, but a company with dozens of subscriptions (per team, per environment, per business unit) would need to duplicate every RBAC assignment and Azure Policy across each one without Management Groups. A Management Group hierarchy lets you assign a policy or role once at a parent level — for example 'deny public storage accounts' — and have it inherit automatically down to every subscription and resource group beneath it.
What's a common pitfall when designing a Management Group hierarchy?
Over-nesting the hierarchy (five or six levels deep to mirror an org chart) makes policy inheritance hard to reason about and slows down troubleshooting when a resource unexpectedly inherits a restrictive policy. Microsoft's own guidance favors a shallow hierarchy — typically root, then a handful of top-level groups like platform, landing zones, and sandbox — with policy assigned at the fewest levels necessary rather than mirroring internal team structure exactly.