AZ-104 · Manage Azure identities and governance · Updated August 7, 2026
The Azure Resource Hierarchy: Management Groups, Subscriptions, and Resource Groups
Azure organizes everything you deploy into four nested scopes: management groups, subscriptions, resource groups, and resources, from broadest to narrowest. Understanding this hierarchy matters for a very concrete reason: both Azure RBAC role assignments and Azure Policy assignments inherit downward through it. Assign a role or a policy at a management group, and every subscription, resource group, and resource beneath it inherits that assignment automatically. Get the hierarchy wrong and you either under-scope a grant (repeating the same assignment dozens of times) or over-scope it (accidentally handing access or restrictions to things that were never supposed to have them).
The four levels
Management groups sit above subscriptions and exist purely to organize subscriptions for unified access and policy management at scale. A management group doesn’t hold resources directly; it holds subscriptions and other management groups.
Subscriptions are the billing and access boundary underneath management groups. A subscription groups resources for billing purposes and is itself a container that resource groups sit inside.
Resource groups are containers inside a subscription that hold related resources meant to share a lifecycle, typically resources you’d deploy, update, and delete together.
Resources are the actual deployed items: virtual machines, storage accounts, virtual networks, databases, and so on. Every resource belongs to exactly one resource group.
Settings applied at a higher level cascade down: a policy applied at the subscription level reaches every resource group and resource inside that subscription; a policy applied at one resource group only affects that group, not sibling resource groups in the same subscription.
The management group tree specifically
This is the detail that trips people up: the “management group hierarchy” is narrower than the full four-level scope chain. A management group tree is built from management groups and subscriptions only. It has:
- A single root: the Tenant Root Group, created automatically the first time anyone in the tenant starts using management groups. Its display name is “Tenant root group” by default, and its ID matches the Microsoft Entra tenant ID. Every subscription and management group folds up into this one root, and new subscriptions default there automatically when created.
- Up to six levels of depth beneath the root. This limit doesn’t count the root level itself or the subscription level at the bottom, so the practical maximum path is root, then up to six nested management groups, then a subscription.
- Single-parent structure: every management group and subscription has exactly one parent, though a management group can have many children.
- 10,000 management groups per directory, as an upper bound on how many you can create tenant-wide.
Resource groups and resources are not nodes in this tree at all. They live below the subscription, the bottom rung of the management group hierarchy proper. This is the distinction the exam cares about: when a question asks what the management group hierarchy consists of, the answer is management groups and subscriptions, full stop. Resource groups are a separate container one level further down, inside a subscription, and they never appear as children in a management group’s own structure the way a child management group or child subscription would.
The Tenant Root Group and access to it
Because the Tenant Root Group sits above everything, an assignment made there is tenant-wide, reaching every management group, subscription, resource group, and resource in the directory. Microsoft deliberately makes that root group inaccessible by default: nobody, including a Microsoft Entra Global Administrator, has standing access to manage it. A Global Administrator must explicitly use the Elevate Access action, which grants them User Access Administrator at the root management group; only then can they assign any Azure role to themselves or others at that scope. This friction is intentional, and it’s a favorite AZ-104 scenario precisely because it’s counterintuitive that the most powerful identity role in the tenant doesn’t automatically carry Azure resource access.
Because everything folds up to the root, Microsoft’s own guidance is to treat role and policy assignments at that scope as “must have” only, since any mistake there propagates everywhere beneath it.
How inheritance actually works for RBAC and Policy
For Azure RBAC, a role assigned at a management group applies to every subscription, resource group, and resource nested beneath it, even though the role itself might not define actions specific to management groups. Assigning “Virtual Machine Contributor” at a management group grants no rights on the management group object itself, but it inherits down and grants VM management rights on every VM in every subscription underneath.
For Azure Policy, the same inheritance applies: a policy or initiative assigned at a management group evaluates every resource in every subscription and resource group beneath it, with the option to exclude specific subscopes. One nuance: while a policy can be assigned at the management group level, actual evaluation of individual resources only happens at the subscription level and below; the management group scope is where the assignment lives, not where compliance gets checked.
Resource groups: a container, not a hierarchy node
A resource group is purely a management convenience: a container for resources that share a lifecycle, letting you deploy, update, or delete them together. A few structural facts matter here:
- Every resource belongs to exactly one resource group, though resources inside a group can be relocated to a different region without moving the group itself.
- A resource group has its own region, but that only determines where the resource group’s own metadata is stored; the resources inside it can live in different regions than the group itself (though same-region placement is recommended for resiliency).
- Resource groups can be used as an RBAC and Policy scope just like any other level, and resource locks can also be applied at the resource group level.
- Tags applied to a resource group are not automatically inherited by the resources inside it. Tagging is a separate mechanism from the scope hierarchy entirely.
- Deleting a resource group deletes every resource inside it.
Because a resource group is a container for resources, not for subscriptions or other resource groups, it cannot be a parent in the management-group sense. That’s the core structural difference the exam tests when it distinguishes the “management group hierarchy” from the full “resource scope hierarchy”: the former is management groups and subscriptions; the latter adds resource groups and resources underneath, but those two lower levels never behave like management group nodes.
Quick comparison
| Management group | Subscription | Resource group | |
|---|---|---|---|
| Can contain | Management groups, subscriptions | Resource groups, resources | Resources only |
| Max nesting depth | 6 levels below root | N/A (bottom of MG tree) | N/A (flat, holds resources) |
| Part of the management group tree | Yes | Yes | No |
| Typical use | Org-wide policy/RBAC at scale | Billing + access boundary | Lifecycle grouping of related resources |
| RBAC/Policy scope | Yes | Yes | Yes |
How the AZ-104 exam tests this
- The depth-limit recall. A stem asks how many levels a management group hierarchy can nest, sometimes phrased as a maximum or as “not counting the root or subscription level.” The answer is six.
- The “is X part of the management group tree” trap. A stem lists management groups, subscriptions, and resource groups and asks which one sits outside the management group hierarchy. Resource groups are the answer; they’re a subscription-level container, not a management-group-tree node.
- The Tenant Root Group access scenario. A stem describes a Global Administrator who cannot assign a role at the top of the hierarchy and asks what they need to do first. The answer is Elevate Access, which grants User Access Administrator at the root management group, not simply “use their Global Administrator role” (that role alone doesn’t carry Azure resource permissions).
- The inheritance-placement question. A stem describes needing one role assignment or one policy to cover many subscriptions with minimal management overhead, and asks where to place it. The answer is at the management group level that’s the common parent of those subscriptions, not at each subscription individually.
- The single-parent constraint. A stem tests whether a subscription or management group can report to two parents simultaneously. It can’t; every node in the tree has exactly one parent.
For how a role assignment placed at any of these scopes actually gets evaluated, see Azure RBAC built-in roles, and for how resource-state rules layer on top of this same scope structure, see Azure Policy vs. Azure RBAC.