Azure Resource Hierarchy Explained

The Azure resource hierarchy has four levels of scope: management groups, subscriptions, resource groups and resources. Settings applied at a higher level, such as role assignments and policy, flow down to everything below it, and they never flow up or sideways. The decision rule is to assign at the highest level that matches the requirement, and no higher: one rule for many subscriptions belongs on a management group, one rule for one application belongs on its resource group.

The four levels, top to bottom

Microsoft describes Azure as having four levels of management scope. Above the first of them sits the tenant, the Microsoft Entra directory that every subscription trusts.

The management group layer is optional in small estates, but it always exists: every directory has one root management group (named “Tenant root group” by default, with the tenant ID as its ID), and new subscriptions land there automatically. The root cannot be moved or deleted. Nobody has default access to it; a Global Administrator can elevate themselves to the User Access Administrator role on it.

Facts about each level that exams ask for

Management groups. A tree supports up to six levels of depth, not counting the root level or the subscription level. A directory supports 10,000 management groups. Each management group and each subscription has exactly one parent, and a management group can have many children. All subscriptions in one hierarchy must trust the same Entra tenant. These numbers come from the management groups overview.

Resource groups. Each resource exists in exactly one resource group, and you can move it to another group later. The resource group has its own location, which is where its metadata is stored, but the resources in it may be in other regions. Deleting a resource group deletes every resource in it. Tags on a resource group are not inherited by its resources. A resource group can hold up to 800 instances of a given resource type, with some types exempt.

Resources. A resource can talk to resources in other groups, for example a web app using a database that lives in a different resource group. Group membership is about lifecycle and management, not about network reachability.

What inherits and what does not

Inheritance applies to the things that are assigned at a scope: Azure RBAC role assignments, Azure Policy assignments and resource locks. A lock on a resource group applies to its resources; a policy on a management group applies to every subscription beneath it. These tools are compared in Azure Policy vs RBAC vs locks, and the role side is covered in Azure RBAC vs Entra roles.

Tags are the exception that trips people. A tag on a resource group describes the group itself; its resources do not pick it up. If every resource needs the tag, the usual answer is an Azure Policy that adds or requires it, not a tag on the container.

Worked example: one estate, three levels of rule

A company runs two product teams, each with a production and a development subscription. Four subscriptions total.

1. Create a management group Products and two child groups, Prod and Dev. Move the production subscriptions under Prod and the development ones under Dev. Depth used: two levels below the root.
2. The security team needs the Reader role on everything. One assignment on the Products group gives Reader on all four subscriptions and everything inside them.
3. Policy requires that resources may only be deployed in West Europe and North Europe. Assign it on Products; no subscription owner can switch it off for their own subscription.
4. Production must be protected from accidental deletion. Put a CanNotDelete lock on the production resource groups (a lock inherits to the resources inside), not on the development ones.
5. Team A’s developers need to create resources only for their own application. Give Contributor on the single resource group rg-teamA-dev, not on the subscription.

Four rules, four different scopes, and none of them needed a per-resource assignment. For the full design discussion, including landing zones, read Azure governance design.

Which exams test this

AZ-900 wants you to name and order the levels. AZ-104 wants you to operate them: create, move, assign. AZ-305 wants you to design the tree for an organization and justify it. The outlines were checked against the published skills lists; Microsoft updates its exams on a schedule, so re-check the current outline before you book.

How exam questions are built around this

• “Apply to all current and future subscriptions.” This points to a management group, often the root or a child that holds them all. Per-subscription assignments miss future subscriptions.
• “Least privilege” with a hierarchy. The narrowest scope that still covers the requirement wins. Subscription-level Contributor is a wrong answer when one resource group is named.
• Moving things. A resource moves between resource groups; a subscription moves between management groups. A resource cannot be in two groups, and a subscription cannot have two parents.
• Resource group location. The group’s region does not restrict where its resources go. Watch for options that claim it does.
• Deletion. “Remove everything in this project at once” points at deleting the resource group, which is why resources with the same lifecycle belong together.
• Depth. The six-level limit excludes the root level and the subscription level, so a question that counts them differently is testing exactly that detail.

Practice questions

Go deeper

• Organize your resources with management groups (Microsoft Learn)
• What is Azure Resource Manager? Scope and resource groups (Microsoft Learn)
• Next topics: Azure governance design, Azure Policy vs RBAC vs locks, ARM vs Bicep vs Terraform, which deploy to these scopes.
• How to study for certification exams