Management groups: govern fifty subscriptions without configuring fifty
One subscription is easy to govern. Fifty is a nightmare if you configure each by hand. Management groups are the layer above subscriptions where you set a rule once and let inheritance push it to all of them.
A small shop has one Azure subscription; an enterprise has dozens. The moment you have more than a handful, a question turns painful: how do you make sure every subscription follows the same policies and access rules without editing each one — and re-editing every time you add another? Management groups are the answer. Microsoft describes them as providing "a governance scope above subscriptions," where "the governance conditions that you apply cascade by inheritance to all associated subscriptions." Set it once, up high; it flows down.
The whole idea in one word: inheritance
Assign an Azure Policy or an RBAC role at a management group, and it applies to every subscription beneath it — and everything in those subscriptions. The docs' own example: put a policy on a management group that limits VM creation to authorized regions, and it applies to all nested management groups, subscriptions, and resources. Crucially, a subscription owner cannot override a policy set above them, which is exactly what makes it governance rather than a suggestion. One assignment high in the tree governs everything under it.
The same trick works for access. Instead of scripting a role assignment across forty subscriptions, you make one role assignment on the management group above them, and it inherits down to all of them. Governance and access, set once, applied everywhere below.
Management groups sit at the top of Azure's organizing hierarchy: management group → subscription → resource group → resource. Each level inherits policy and access from the one above. Management groups can even nest — up to six levels deep — so you can model an org: a top group for company-wide rules, children for Corp and Online or for prod and non-prod, each tightening as you go down.
The root management group
Every Entra tenant has a single top-level root management group that everything folds up into — all your management groups and subscriptions ultimately sit beneath it, and new subscriptions default there when created. That makes it powerful and dangerous in equal measure: anything assigned at the root applies to every resource in the tenant. Microsoft is blunt about it — assignments at the root scope should be "must have" only. It is the place for the handful of universal, non-negotiable rules, and nothing else.
Set the rule once, high in the tree, and every subscription beneath it complies — whether it existed yesterday or gets created tomorrow.
A few facts worth carrying
- Each management group and each subscription has exactly one parent, so there is a single, unambiguous hierarchy — no resource inherits conflicting rules from two directions.
- A management group tree can be up to six levels deep (below the root), which is plenty to model even a large organization.
- New subscriptions land in the root group by default; part of good governance is moving them under the right management group so they inherit the correct policy and access from day one.
Where it fits
This is the top of the story that subscriptions and resource groups tell. A landing zone — a governed Azure estate — is essentially a management-group hierarchy with policy and access assigned at the right levels, so every workload that lands inherits the guardrails automatically. When an interviewer asks how you would enforce standards across an organization's Azure, "a management-group hierarchy with policy and RBAC assigned high and inherited down, so a new subscription is governed the moment it is created" is the answer of someone who has run Azure at scale, not just built in one subscription.