Academmia

Azure Management Hierarchy: Management Groups, Subscriptions, Resource Groups, and Resources

az-900•beginner•

Azure architecture and services

Azure Management Hierarchy: Management Groups, Subscriptions, Resource Groups, and Resources

Short Summary

In this lesson, you’ll learn how Azure organizes resources using a simple hierarchy of scopes. You’ll understand what each level is mainly used for (governance, boundaries for management, and lifecycle organization). You’ll also see how access and governance settings can inherit from higher scopes to lower ones.

Learning Objectives

By the end of this lesson, you will be able to:

  • List the Azure scope hierarchy from highest to lowest.
  • Describe what management groups are used for and when they matter.
  • Explain what a subscription is commonly used for in organization and cost tracking.
  • Distinguish the purpose of a resource group versus a resource.
  • Predict how Azure role-based access control (Azure RBAC) and Azure Policy assignments can inherit down the hierarchy.

Core Concepts

What “scope” means in Azure

A scope is the boundary where you apply management settings like access control and governance rules. The scope you choose determines how widely the setting applies, and child scopes can inherit from parent scopes.

The hierarchy (highest to lowest)

Azure commonly describes four management scopes:

Management groups → Subscriptions → Resource groups → Resources

Management groups

A management group is a container for subscriptions. It exists above subscriptions to help organizations manage governance (policy, compliance rules, and access) across many subscriptions in a consistent way. Management groups can be nested to form a hierarchy.

Subscriptions

A subscription is a core boundary for organizing Azure usage. It’s commonly used as a boundary for things like access management, cost tracking, and service limits (quotas).

Resource groups

A resource group is a logical container inside a subscription that holds related resources for a solution. Resource groups are mainly about lifecycle coordination: resources that should be deployed, updated, and deleted together often belong together in one resource group.

Resources

A resource is the actual thing you deploy, such as a Virtual Machine (VM), a storage account, or a database. Resources live under a subscription and are typically placed in a resource group.

Inheritance: why the hierarchy matters

Governance and access assignments are scope-based:

  • Azure RBAC can be assigned at management group, subscription, resource group, or resource scope, and lower scopes inherit role permissions from higher scopes.
  • Management groups are specifically designed so that conditions applied at the management group scope can cascade to descendant subscriptions and beyond.

A practical rule of thumb: apply governance at the highest scope that matches your intent, and keep exceptions deliberate.

Practical Understanding

Practical Situation 1: “I need the order in my head, fast”

You’re reading documentation, and you keep mixing up whether resource groups sit above subscriptions or the other way around.

How to think about it: Start with the broadest scope and move downward: management groups group subscriptions, subscriptions contain resource groups, and resource groups contain resources. If you remember one line, remember: management groups → subscriptions → resource groups → resources.

Common misunderstanding: “Resource groups can contain subscriptions.” It’s the opposite: resource groups live inside a subscription.

Practical Situation 2: “Which level is governance vs billing/limits vs organization?”

A team wants to know where to put rules that must apply broadly, where spending is typically tracked, and where “these resources belong together” is modeled.

How to think about it: Use management groups for governance across multiple subscriptions, subscriptions as a common boundary for cost tracking and limits, and resource groups to organize resources by lifecycle inside a subscription.

Common misunderstanding: “Subscriptions and resource groups are basically the same container.” They’re different scopes with different responsibilities.

Practical Situation 3: “Give access across many subscriptions”

An organization has several subscriptions and wants one person (or team) to have the same access across all of them.

How to think about it: If access must span many subscriptions, use a management group to group those subscriptions and assign Azure RBAC at the management group scope so it can inherit down. If access should be limited, choose a narrower scope (subscription or resource group).

Common misunderstanding: “I should always assign access at the resource group level.” That can create repeated work and increases the chance you miss something when new subscriptions or resource groups appear.

Practical Situation 4: “Do we even need management groups yet?”

A small team has one subscription and a few resource groups. Someone proposes building a multi-level management group hierarchy immediately.

How to think about it: Management groups become most valuable when you have multiple subscriptions and need consistent governance across them. With one subscription, you can often stay simpler by focusing on clear resource group structure and using subscription-level governance as needed.

Common misunderstanding: “Management groups are required for every Azure setup.” They’re optional, and they pay off when they solve a real governance-at-scale problem.

Common Pitfalls

  • Mistake: Treating the hierarchy as “folders” that all do the same job. Correction: Each scope has a distinct purpose: management groups (govern subscriptions), subscriptions (boundary for management/cost/limits), resource groups (lifecycle organization), resources (deployed services).

  • Mistake: Thinking resources are deployed “into” a management group. Correction: Management groups organize subscriptions; resources are deployed at lower scopes (typically into a resource group within a subscription).

  • Mistake: Assigning broad Azure RBAC permissions too high “just to make it work.” Correction: Start with least privilege at the narrowest scope that meets the need, then widen the scope intentionally.

  • Mistake: Expecting a setting assigned at one scope to apply everywhere the same way. Correction: Inheritance is real, but it’s still scope-based—verify the exact scope of the assignment and where it should apply.

  • Mistake: Putting resources with different lifecycles into the same resource group. Correction: Group resources that should be deployed/updated/deleted together; separate the ones that need independent change cycles.

Check Your Understanding

  • Write the Azure scope hierarchy from highest to lowest and explain what each level is mainly used for.
  • Describe a real example of resources that should share a lifecycle and belong in one resource group.
  • Explain why you might separate production and development workloads into different subscriptions.
  • Describe when you would choose management group scope for a governance rule instead of subscription scope.
  • In your own words, explain what “inheritance” means for Azure RBAC assignments across scopes.

Further Reading