Azure Management Hierarchy
Slide deck explaining the Azure management hierarchy, scope hierarchy from management groups to resources, inheritance of Azure RBAC and Azure Policy, and guidance on choosing the right scope level.
Azure Management Hierarchy
Introduction to Azure Management Hierarchy, covering the scope hierarchy and how settings apply across different levels.
Azure Management Hierarchy
Introduction to Azure Management Hierarchy, covering the scope hierarchy and how settings apply across different levels.
Why the hierarchy exists
Azure uses scopes to apply access and governance consistently. Scope equals boundary for management settings. Broad scope equals consistent rules. Narrow scope equals targeted control. Inheritance can flow downward.
Scope = where settings apply
Scope decides how widely a rule or access assignment applies. Apply settings at a chosen boundary. Parent → child inheritance is possible. Higher scope equals wider impact. Choose scope based on intent.
Azure scope hierarchy (top → bottom)
Four scopes organize everything from governance to the individual service. Management groups. Subscriptions. Resource groups. Resources.
Management groups
Use management groups to manage governance across multiple subscriptions. Container above subscriptions. Designed for governance and consistency. Works best when you have many subscriptions. Can be nested into a hierarchy.
Subscriptions
Subscriptions are a major boundary for cost tracking and limits. Common boundary for cost tracking. Common boundary for quotas (service limits). Organize by environment or ownership. Sits below management groups.
Resource groups
Resource groups group resources that share a lifecycle. Logical container inside a subscription. Organize by solution and lifecycle. Deploy/update/delete together. Separate resources with different lifecycles.
Resources
A resource is a deployed Azure service (like a Virtual Machine (VM)). The deployable 'thing' in Azure. Examples: Virtual Machine (VM), storage account, database. Usually placed inside a resource group. Inherits context from higher scopes.
Inheritance (Azure RBAC + Azure Policy)
Assign at a scope; lower scopes can inherit from higher scopes. Azure role-based access control (Azure RBAC) supports multiple scopes. Azure Policy can be assigned by scope. Higher scope can affect everything below. Choose the highest scope that fits your intent.
Fast mental model
One sentence fixes the order and the 'contains what' question. Management groups group subscriptions. Subscriptions contain resource groups. Resource groups contain resources. Broad → specific is the direction.
Which level do I use?
Each scope has a different 'main job.' Management groups: governance across subscriptions. Subscriptions: cost tracking, limits, separation boundaries. Resource groups: lifecycle organization for a solution. Azure RBAC: assign at the scope that matches access needs.
Common pitfalls
Most problems come from using the wrong scope for the job. Don't treat scopes as identical folders. Avoid overly broad permissions (least privilege). Verify the scope of every assignment. Group resources by lifecycle, not convenience.
Recap
Know the order, the purpose of each scope, and how inheritance works. Order: Management groups → Subscriptions → Resource groups → Resources. Scope decides how widely settings apply. Inheritance can flow downward.