Azure Resource Hierarchy: Mastering the Structure (AZ-900)

The Azure resource hierarchy is a four-level logical structure consisting of Management Groups, Subscriptions, Resource Groups, and Resources. This hierarchy enables organized governance, where permissions (RBAC) and policies applied at higher levels are inherited by all nested child elements, ensuring consistent security and compliance across an entire cloud environment.

What is the logical flow of the Azure resource hierarchy?

Think of the Azure resource hierarchy as a set of Russian nesting dolls. At the very top, you have the Root Management Group, which acts as the umbrella for everything in your tenant. Below that, you can create multiple Management Groups to organize your subscriptions into a logical structure based on your company's departments or environments (like Production vs. Development).

Moving down the chain, you hit Subscriptions, which are primarily used for billing and quota limits. Inside each subscription, you'll find Resource Groups—logical containers that hold the actual 'stuff' you deploy. Finally, at the bottom, you have the Resources themselves, such as Virtual Machines, Azure SQL databases, or Storage Accounts. For the AZ-900 exam, you must understand that this flow is strictly linear: Management Group > Subscription > Resource Group > Resource.

How does inheritance work for RBAC and Azure Policy?

This is where the real power of the hierarchy kicks in. Azure uses a top-down inheritance model for Role-Based Access Control (RBAC) and Azure Policy. If you assign a user the 'Contributor' role at the Management Group level, that user automatically has Contributor rights to every subscription, resource group, and individual resource nested beneath it. You don't have to manually assign permissions 1,000 times; you do it once at the top, and it flows down.

Azure Policy works similarly. If you apply a policy at the subscription level that mandates all resources must be deployed in the 'East US' region, any resource group created within that subscription must follow that rule. This prevents 'shadow IT' and ensures your cloud spend doesn't spiral out of control. When we design our practice exams at Cert Sensei, we focus heavily on these inheritance scenarios because they are frequent traps on the actual Microsoft exam.

Why are Management Groups critical for corporate environments?

In a small setup, a single subscription might suffice. But in a corporate environment with 500 developers and three different business units, that's a recipe for disaster. Management Groups allow you to apply governance at scale. For example, you can create a 'Finance' Management Group and a 'Marketing' Management Group. You can then apply different security policies to each without affecting the other.

This structure allows IT administrators to delegate control. You can give the Finance lead full control over their specific Management Group while keeping the Root Management Group locked down to a few global admins. This separation of concerns is a core tenet of the Well-Architected Framework and a key topic you'll encounter in the Azure Fundamentals curriculum.

How should you organize your subscriptions and resource groups?

The biggest mistake I see students make is treating a Resource Group like a folder for 'similar things.' Instead, you should organize Resource Groups based on the lifecycle of the application. If a web app consists of a VM, a database, and a virtual network that are all created and deleted together, put them in one Resource Group. This makes cleanup a breeze—just delete the group, and everything inside vanishes.

When it comes to subscriptions, use them to manage billing boundaries or to avoid hitting Azure subscription limits. If you're studying for the AZ-900, remember that while a resource can only belong to one resource group, a subscription can contain thousands of them. To truly master this, we recommend using the custom quiz builder at Cert Sensei to filter for governance domains and drill down on these organizational strategies.

What happens when you move resources between resource groups?

Moving a resource might seem simple, but it has implications. When you move a resource from Resource Group A to Resource Group B, the Resource ID changes. If you have scripts, automation, or third-party tools that reference that specific Resource ID, they will break. You'll need to update those references immediately to avoid downtime.

Not all resources can be moved. Some services have strict dependencies that lock them to their original group. Before you initiate a move in the Azure Portal, always check the 'Move' validation process. On the exam, you might be asked about the impact of these moves—remember that while RBAC permissions at the resource level move with the resource, permissions assigned at the Resource Group level do not.

How can you validate your knowledge of Azure governance?

Reading the documentation is a start, but you won't know if you're ready until you're tested under pressure. The AZ-900 exam doesn't just ask you to define these terms; it gives you a scenario and asks you to choose the best organizational structure. This requires a deep, intuitive understanding of how the hierarchy functions in the real world.

To bridge that gap, we provide 1,000 expert-curated Microsoft Azure Fundamentals practice questions. We don't just tell you if you're wrong; we provide detailed expert reasoning for every answer so you understand the 'why' behind the 'what.' Combined with our domain-level analytics, you can see exactly where you're struggling—whether it's RBAC inheritance or subscription limits—and pivot your study time to where it actually matters.

❓ Frequently Asked Questions