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.
New to cloud? CAMPUX is a free, build-first course. Start here →
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. And 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 what an interviewer is listening for: evidence you think in hierarchies and inheritance rather than one subscription at a time.
Questions people also ask
What is a management group in Azure?
A container that sits above subscriptions in Azure's hierarchy. You assign a policy or a role to a management group once, and every subscription beneath it inherits that assignment automatically, including subscriptions added later. It exists so an organization governs many subscriptions from one place instead of configuring each one by hand.
What is the difference between a management group and a subscription?
A subscription is a billing and resource boundary; a management group is a governance boundary above subscriptions and holds no resources or invoices of its own. You put subscriptions inside a management group so policy and RBAC assigned at that group cascade down to every subscription, and every resource group and resource, it contains.
How many levels deep can an Azure management group hierarchy be?
Up to six levels below the root management group. That is enough to model a large organization: a top group for company-wide rules, child groups for divisions like Corp and Online or for prod and non-prod, each one tightening the rules as you move down toward individual subscriptions.
What is the root management group in Azure?
The single top-level group that every Entra tenant has by default. All management groups and subscriptions in the tenant ultimately sit beneath it, and new subscriptions land there automatically when created. Because assignments at the root apply to every resource in the tenant, Microsoft recommends putting only must-have, non-negotiable rules there.
Can a subscription belong to more than one management group?
No. Each subscription, and each management group, has exactly one parent, so there is a single unambiguous hierarchy. That matters because it means no resource ever inherits conflicting policy or access from two different branches of the tree — the path from root to resource is always one path, not several.