4.1 Management Group & Subscription Hierarchy Design
Key Takeaways
- A single Microsoft Entra tenant supports up to 10,000 management groups and a management group tree up to 6 levels deep, not counting the root level or the subscription level
- Management groups are a governance boundary (Azure Policy and RBAC inheritance); subscriptions are a billing, quota, and deployment boundary — never confuse the two purposes on the exam
- Every management group or subscription has exactly one parent but can have many children; Azure Policy and role assignments made at a management group cascade down to every child scope beneath it
- The Azure landing zone reference architecture splits management groups into a Platform branch (Identity, Management, Connectivity subscriptions) and a Landing Zones branch (Corp and Online), which is the default answer pattern for large multi-subscription design questions
- Design subscriptions around a hard boundary you actually need (environment isolation, per-subscription quota limits, or a distinct billing owner) — do not create a subscription for every team just to mirror the org chart
Why This Topic Matters
"Recommend a structure for management groups, subscriptions, and resource groups, and a strategy for resource tagging" is the first bullet under the Design governance functional group inside Domain 1 (Design identity, governance, and monitoring solutions, 25-30% of AZ-305). This bullet is split across two sections here because it packs two genuinely different design decisions into one sentence: how you nest management groups and subscriptions (this section), and how you organize resource groups and tags underneath them (section 4.2). Expect scenario questions that describe an enterprise with dozens or hundreds of subscriptions across business units, environments, and regions, then ask you to pick the correct grouping structure. Getting the hierarchy wrong is expensive to unwind later, because policy and RBAC assignments, cost reporting, and delegated administration all depend on it.
The Resource Hierarchy
Azure Resource Manager organizes everything into four nested levels:
| Level | Scope | Primary purpose |
|---|---|---|
| Microsoft Entra tenant (directory) | Organization-wide | Identity boundary; owns the root management group automatically |
| Management group | Groups subscriptions (and other management groups) | Apply Azure Policy and RBAC once, inherited down the tree |
| Subscription | Billing + deployment boundary | Cost boundary, service quota boundary, and the highest scope most Azure RBAC roles can be assigned at directly for resources |
| Resource group | Groups resources with a shared lifecycle | Deploy, manage, and delete related resources together |
The most important exam distinction: a management group is a governance container — it has no billing relationship and cannot own resources directly. A subscription is a billing and quota container. If a question describes a requirement about cost allocation, chargeback, or per-service quota limits, the answer usually involves subscription design. If the requirement is about applying a rule (or an access grant) consistently across many subscriptions, the answer involves management group design.
Management Group Limits and Inheritance
| Limit | Value |
|---|---|
| Management groups per Microsoft Entra directory | 10,000 |
| Maximum management group tree depth | 6 levels (excludes the root level and the subscription level) |
| Parents per management group or subscription | Exactly 1 |
| Children per management group | Unlimited |
| Subscriptions per management group | Unlimited |
Every tenant gets an automatically created, non-deletable root management group that sits directly under the tenant. Any Azure Policy assignment or RBAC role assignment made at a management group is inherited by every management group, subscription, resource group, and resource beneath it — a lower scope cannot opt out of an inherited assignment except through an explicit Azure Policy exemption. Design implication: put the broadest, organization-wide controls (for example, "deny public IP addresses on storage accounts" or "require the Owner role to be time-bound") as high in the tree as possible, and push narrower, team-specific controls down to the individual landing-zone or workload subscription.
Subscription Design Strategies
There is no single correct subscription model — the exam expects you to match the strategy to the stated requirement:
| Strategy | When to use it | Trade-off |
|---|---|---|
| By environment (Dev/Test/Prod) | Need hard isolation of quotas and blast radius between environments | Simple, but can multiply subscription count quickly across many apps |
| By business unit / department | Departments need separate billing ownership and cost accountability | Clean chargeback, but governance must be re-applied consistently across units via management groups |
| By workload criticality | A mission-critical workload needs its own service quotas so noisy neighbors in other apps cannot exhaust limits | Isolates scale limits, at the cost of more subscriptions to govern |
| By region / data residency | Regulatory or data-sovereignty requirements tie data to a geography | Required when law dictates it; otherwise adds operational overhead |
Most real enterprise designs, and most exam-correct answers, combine dimensions: environment nested inside workload, inside business unit, inside a landing-zone management group.
The Azure Landing Zone Pattern
When a scenario describes an enterprise adopting Azure at scale with centralized, policy-driven governance, the expected answer is the Azure landing zone conceptual architecture from the Microsoft Cloud Adoption Framework (CAF), which organizes management groups like this:
- Tenant Root Group
- Platform management group
- Identity subscription (domain controllers, Microsoft Entra Connect/Cloud Sync)
- Management subscription (Log Analytics, Azure Monitor, automation)
- Connectivity subscription (hub virtual network, ExpressRoute/VPN gateways, Azure Firewall)
- Landing zones management group
- Corp (workloads needing connectivity back to on-premises)
- Online (internet-facing workloads with no forced tunneling)
- Sandbox management group (experimentation, no production connectivity)
- Decommissioned management group (subscriptions pending closure)
- Platform management group
This separation lets the platform team apply strict, centrally owned policy to Identity/Management/Connectivity while application teams retain flexibility inside their landing-zone subscriptions, subject to the policies inherited from above.
Common Exam Traps
- Treating a management group as a billing boundary — it is not; only subscriptions carry cost.
- Assuming you can nest management groups arbitrarily deep — the limit is 6 levels, and CAF guidance recommends using far fewer (typically 3-4) to keep governance simple.
- Designing one subscription per team to mirror the org chart, which multiplies operational overhead without a real isolation requirement behind it.
- Forgetting that a resource group belongs to exactly one subscription — you cannot span a resource group across subscriptions to "simplify" cross-subscription grouping; tags are the tool for that (covered next).
A company is redesigning its Azure environment for 180 subscriptions spread across 5 business units, each running Dev, Test, and Prod workloads. The security team wants a single Azure Policy assignment that automatically applies to every current and future subscription in the company without being reapplied manually. Where should this policy be assigned?
Which statement correctly distinguishes a management group from a subscription in Azure's resource hierarchy?
A management group tree in a single Microsoft Entra tenant currently has 5 levels beneath the root management group. The platform team wants to add one more nested level for a newly acquired subsidiary. Is this within Azure's supported limits?