Azure Subscriptions vs. Management Groups: The Governance Hierarchy

An Azure subscription is a logical container that ties a set of resources to billing and access control — it’s what generates your invoice and defines who can do what within it. A management group sits one level above subscriptions purely for governance: it lets you apply the same policy and role assignments to many subscriptions at once, with settings flowing down automatically to everything nested underneath. Neither replaces the other — subscriptions handle money and access, management groups handle scale.

The full hierarchy, top to bottom

Azure organizes everything into four nested levels, from broadest governance scope to the narrowest deployed item:

Management groups → subscriptions → resource groups → resources

Settings applied at any level flow down to everything beneath it. A policy assigned at a management group reaches every subscription in that group, every resource group in those subscriptions, and every resource in those groups — without being reapplied anywhere along the way. That downward inheritance is the entire point of putting management groups above subscriptions instead of just configuring each subscription independently.

Two structural facts matter here: a subscription can sit under only one management group at a time (never several simultaneously), and subscriptions themselves can’t be nested inside each other — nesting is a management-group-only capability.

What a subscription actually does

A subscription provides authenticated and authorized access to Azure services and serves three separate practical roles at once:

• Billing boundary. Everything deployed inside a subscription rolls up into one invoice. If you need separate, independent invoices for two departments, you need two subscriptions — no lower-level construct produces a separate bill.
• Access-management boundary. Role-based access control (RBAC) and Azure Policy can be assigned at the subscription level, applying to everything inside it.
• Quota boundary. Azure enforces many default service limits — maximum virtual machines per region, maximum virtual networks, and similar caps — at the subscription level. If a growing workload starts bumping into those ceilings, you have two options: request a quota increase from Microsoft, or provision an additional subscription to get a fresh set of limits.

Organizations typically hold one of several subscription types, such as an Enterprise Agreement (EA) subscription negotiated directly with Microsoft, alongside pay-as-you-go and other offer types — the specific type doesn’t change the billing/access/quota roles described above, just the commercial terms behind them.

What a management group actually does

A management group exists to solve one problem: applying consistent governance across many subscriptions without configuring each one by hand. Assign a policy or an RBAC role at the management group level, and every subscription nested beneath it inherits that assignment automatically — including subscriptions added to the group later, with no extra configuration required.

Every Microsoft Entra ID tenant gets exactly one root management group, created automatically the first time management groups are enabled. It sits at the very top of the hierarchy — nothing exists above it — and every other management group and subscription in that tenant ultimately rolls up into it. It can’t be deleted.

Below the root, management groups can be nested to model an organization’s real structure: business units, regions, or compliance tiers. Azure supports up to six levels of nested management groups, not counting the root level or the subscription level itself. That’s a hard ceiling worth memorizing, since it comes up directly on the exam.

Subscriptions vs. management groups at a glance

	Subscription	Management group
Role	Billing, access, and quota boundary	Governance scope above subscriptions
Generates an invoice	Yes	No
Contains	Resource groups and resources	Subscriptions and/or other management groups
Nesting	Cannot be nested inside another subscription	Can be nested up to six levels deep (below the root)
Policy/RBAC assignment	Yes, applies to everything inside it	Yes, inherited by every subscription and management group beneath it
Per-tenant minimum	Zero or more	Exactly one root management group, always present

Designing the hierarchy: two patterns worth knowing cold

Most real-world designs combine both layers rather than choosing one:

Separate subscriptions under a shared management group. When departments, subsidiaries, or campuses each need independent billing and independent day-to-day resource management, give each one its own subscription. Then place all of those subscriptions under one management group so headquarters can enforce a single security baseline, tagging standard, or spending policy without touching each subscription individually. This is the standard pattern for any scenario that asks for “separate invoices, consistent governance.”

Nested management groups for exceptions. Sometimes one part of the organization needs stricter rules than the baseline — a subsidiary in a regulated industry, for example. Rather than applying the stricter policy everywhere (over-restricting units that don’t need it) or configuring it manually on each affected subscription (unreliable and easy to forget), nest a child management group containing just that subsidiary’s subscription(s) underneath the parent group. Assign the company-wide baseline at the parent and the additional stricter policy at the child — the child inherits the parent’s baseline and adds its own extra layer on top.

How the AZ-900 exam tests this

• “Separate invoices, one security policy” scenarios. Whenever a stem wants independent billing per unit and centrally enforced governance, the answer is separate subscriptions per unit, grouped under one shared management group — not a single subscription with resource groups, and not fully separate accounts with no shared governance layer.
• Hierarchy ordering and naming questions. Expect direct recall of the four-level order (management groups → subscriptions → resource groups → resources) and of what sits at each layer — a common trap answer reverses the order or slots resource groups above subscriptions.
• The six-level depth fact. Questions test the exact nesting limit for management groups (six, not counting root or subscription), often alongside a distractor claiming unlimited depth or a much smaller number.
• Quota-exhaustion scenarios. A subscription approaches a resource limit (VM count, virtual network count), and the question asks what to do. The pattern always resolves to either requesting a quota increase or provisioning an additional subscription — never deleting the subscription, never an automatic account upgrade.
• Root management group identification. A scenario describes what gets created automatically at the top of the hierarchy the first time management groups are enabled — the answer is the single root management group, not a root resource group or a free-tier subscription.
• Layered-exception designs. More advanced scenarios need a baseline policy company-wide plus a stricter policy for just one subsidiary. The answer is a nested child management group under the parent, with the baseline at the parent and the extra restriction at the child — applying everything at the root would over-restrict every subsidiary, not just the one that needs it.

Quick reference

• A subscription is Azure’s billing boundary, access-control boundary, and quota boundary, all at once.
• A management group sits above subscriptions purely to apply policy and RBAC across many of them at once, via inheritance.
• The full hierarchy, broadest to narrowest: management groups → subscriptions → resource groups → resources.
• Every tenant has exactly one root management group, created automatically, and it can’t be deleted.
• Management groups nest up to six levels deep, not counting the root or subscription level.
• A subscription belongs to exactly one management group at a time; subscriptions themselves can’t be nested.
• Common pattern: one subscription per business unit for independent billing, all grouped under one management group for shared governance, with nested child groups layering on stricter rules for specific units.

Once the hierarchy is solid, the next layer down is worth locking in too — see Azure resource groups explained for how resources are organized inside a subscription, and how Azure Policy governance actually enforces the rules assigned at each of these scopes. Then test what you’ve learned with AZ-900 practice questions covering the full governance hierarchy.