Azure Management Groups
Slide deck explaining Azure Management Groups, their purpose in organizing subscriptions, scope hierarchy, inheritance of policies and RBAC, when to use them, and common pitfalls.
Azure Management Groups
Introduction to Azure Management Groups, covering their role in organizing subscriptions and applying governance at scale.
Azure Management Groups
Introduction to Azure Management Groups, covering their role in organizing subscriptions and applying governance at scale.
Why Azure Management Groups exist
They apply consistent governance across multiple subscriptions. Use when you manage many subscriptions. Apply shared rules once, inherit everywhere below. Reduce drift between environments (prod/dev/test). Best for 'baseline' governance.
What is an Azure Management Group?
A management group organizes subscriptions and sets governance scope. Container for organizing Azure subscriptions. Used for governance and access at scale. Exists within a Microsoft Entra ID (Entra ID) tenant. Resources are not created in management groups.
Azure scope hierarchy
Scope is where rules and access are applied—and it cascades down. Management groups → Subscriptions → Resource groups → Resources. Scope equals where a rule or access applies. Higher scope can affect many teams and environments. Use high scopes intentionally.
Inheritance: the superpower
Assignments at a management group can inherit down the entire tree. Assign once at management group scope. Inherits to subscriptions, resource groups, resources. Great for baseline rules and shared controls. Broad impact means higher risk if misused.
Azure Policy inheritance
Policies assigned at a management group can apply to everything below. Azure Policy equals governance rules (standards/requirements). Assign at management group for broad coverage. Inherits to child scopes automatically. Helps prevent 'one subscription missing the rule'.
Azure role-based access control (Azure RBAC) inheritance
RBAC roles assigned high can grant access broadly through inheritance. Azure role-based access control (Azure RBAC) equals permissions by scope. Assigning at management group can grant access across subscriptions. Use least privilege and narrow scopes first. Widen scope only when it's truly needed.
Three containers, three jobs
Each layer groups something different, for a different purpose. Management group: groups subscriptions (governance/access). Subscription: boundary where resources live. Resource group: groups resources (lifecycle management). Different layers, different responsibilities.
What management groups don't control
They're about governance—not billing boundaries. Not a billing boundary. Use subscriptions / billing scopes for cost separation. Use management groups for governance plus inheritance. Design hierarchy around real org needs.
When to use management group scope
Use it for baselines that should apply across many subscriptions. Best for shared rules across multiple subscriptions. Avoid repeating policy in every subscription. Use narrower scopes for environment/team differences. Remember: high scope equals broad impact.
High-scope assignments: the risk
Inheritance can expand impact far beyond what you intended. Policies and roles can affect all descendants. Mistakes spread fast at top scopes. Prefer least privilege for Azure RBAC assignments. Widen scope only when necessary.
When a policy doesn't apply everywhere
Often it's an intentional exception—not a failure of inheritance. Check excluded scopes (notScopes). Check policy exemptions (intentional waivers). Exceptions help avoid redesigning the hierarchy. Validate before changing scope structure.
Common pitfalls (and quick corrections)
Most problems come from confusing layers and overusing high scope. Resources don't live in management groups. Management groups do not equal resource groups (different purposes). Avoid 'too broad' Azure RBAC at the top. Check notScopes and exemptions for exceptions.