Academmia

Azure Management Groups

az-900•mixed•

Azure architecture and services

Azure Management Groups

Short Summary

Azure management groups help me apply the same governance rules across multiple Azure subscriptions. They sit above subscriptions in the scope hierarchy, so policies and access assignments can inherit down the tree. In this lesson, I’ll focus on what management groups are, how inheritance works, and the common “oops” moments that happen when you assign things too high.

Learning Objectives

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

  • Define what an Azure management group is and what it contains.
  • Place management groups correctly in the Azure scope hierarchy.
  • Explain how Azure Policy and Azure role-based access control (Azure RBAC) assignments inherit from a management group.
  • Differentiate management groups from subscriptions and resource groups.
  • Identify what management groups do not control (for example, billing boundaries).

Core Concepts

What a management group is

An Azure management group is a container used to organize subscriptions and apply governance consistently at scale. It exists within a Microsoft Entra ID (Entra ID) tenant (your organization’s identity directory).

Where it sits in the hierarchy

Management groups are part of the Azure “scope” hierarchy (the layers where you can apply governance and access):

Management groups → Subscriptions → Resource groups → Resources

Scope matters because Azure Policy assignments and Azure RBAC role assignments are applied at a scope and can affect everything beneath it.

The key benefit: inheritance

The main value of management groups is inheritance:

  • If I assign an Azure Policy at a management group, that policy can apply to all descendant scopes (child management groups, subscriptions, resource groups, and resources).
  • If I assign an Azure RBAC role at a management group, that access can also inherit down the hierarchy.

This lets organizations avoid re-applying the same rule set separately in every subscription.

What management groups are not

It’s easy to confuse “management group” with “resource group”, but they solve different problems:

  • A management group groups subscriptions for governance and access.
  • A resource group groups resources inside a subscription for lifecycle management (deploy/update/delete together).

Also, management groups are not a billing boundary. Subscriptions (and billing scopes in Azure Cost Management & Billing) are commonly used for cost separation and chargeback; management groups are primarily about governance and consistent control.

Practical Understanding

Practical Situation 1: One set of rules across many subscriptions

An organization has multiple subscriptions (production, development, testing) and wants the same governance requirement everywhere, such as requiring certain tags or restricting allowed regions.

How to think about it: If the requirement should be consistent across several subscriptions, a management group is usually the cleanest place to set the baseline. Assign the Azure Policy (and any broad Azure RBAC roles) at the management group so they inherit to all subscriptions under it.

Common misunderstanding: “I must configure the rule separately in every subscription.” That works, but it’s easy to miss one and hard to keep consistent over time.

Practical Situation 2: People use “group” words interchangeably

Someone says “resource group,” “management group,” and “subscription” as if they are the same kind of container.

How to think about it:

  • Management group: groups subscriptions for governance.
  • Subscription: a boundary where resources live and many management actions are scoped.
  • Resource group: groups resources inside a subscription for lifecycle management.

Common misunderstanding: “Management groups are just bigger resource groups.” They’re different layers with different jobs.

Practical Situation 3: You assign something at the top and it changes more than expected

A team assigns a restrictive policy or a powerful Azure RBAC role at a high scope and later notices it affects more subscriptions than intended.

How to think about it: High-scope assignments are intentionally broad. Use management group scope for rules that truly should apply widely. Use narrower scopes (subscription or resource group) when you need differences between teams or environments.

Common misunderstanding: “High-level assignments only affect the management group object itself.” In reality, the point is the inheritance to everything underneath.

Practical Situation 4: Inheritance “should work,” but enforcement looks inconsistent

A policy is assigned at a root or parent management group, but some resources under a child subscription don’t appear to follow it.

How to think about it: Before assuming something is broken, check whether the policy assignment has:

  • excluded scopes (often configured via notScopes), or
  • policy exemptions (intentional waivers/mitigations for a scope or resource)

These are normal tools used to create deliberate exceptions without redesigning the hierarchy.

Common misunderstanding: “If it’s assigned at the top, it must apply everywhere with no exceptions.”

Common Pitfalls

  • Mistake: Treating management groups like a place where resources are created and “live”. Correction: Management groups organize subscriptions; resources are created inside subscriptions (typically inside resource groups).

  • Mistake: Thinking management groups and resource groups are the same concept at different sizes. Correction: Management groups are for governance across subscriptions; resource groups are for resource lifecycle inside a subscription.

  • Mistake: Assigning broad Azure RBAC permissions at a management group “just to make it work”. Correction: Start with least privilege at the narrowest scope that meets the requirement, then widen only when necessary.

  • Mistake: Assuming a management group is a billing boundary. Correction: Use subscriptions and billing scopes for cost separation; use management groups for governance structure and inheritance.

  • Mistake: Forgetting that top-level assignments can affect downstream teams you didn’t intend to impact. Correction: Use high scopes only for “baseline” rules, and design the management group hierarchy around real organizational needs.

  • Mistake: Treating missing enforcement as a mystery. Correction: Check excluded scopes (notScopes) and policy exemptions before changing your hierarchy or reassigning policies.

Check Your Understanding

  • Contrast a management group and a resource group using one sentence each.
  • List the scope hierarchy from highest to lowest and explain what “scope” means in this context.
  • Describe a situation where you would assign an Azure Policy at a management group instead of at a subscription.
  • Describe one risk of assigning an Azure RBAC role at a management group and one way to reduce that risk.
  • If a policy is assigned at a parent management group but some resources don’t follow it, name two things you would check first.

Further Reading