# Management group

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/management-group

## Quick definition

A Management group is a way to group together several Azure subscriptions so you can apply rules and permissions to all of them at once. Think of it as a folder that holds subscriptions. If you have many subscriptions, Management groups make it easier to control costs, assign roles, and enforce company policies from a single place. They are part of Azure’s governance and identity structure.

## Simple meaning

Imagine you run a large company with several departments, each with its own budget and rules. Instead of managing each department separately, you create a folder for each department and put all their documents inside. If you want to change a rule for the entire department, you only need to update the folder once, and the change applies to everything inside. That is what a Management group does in Azure, but for subscriptions. A subscription is like a separate account where you run your cloud resources, such as virtual machines or databases. If you have many subscriptions, managing them one by one becomes a nightmare. Management groups let you stack subscriptions into a hierarchy, like folders inside folders. At the top, you have the root Management group for your entire organization. Under that, you might create groups for different business units, like Sales, Engineering, or Finance. Then inside each group, you put the subscriptions that belong to that unit. When you assign a permission or a policy to a Management group, all subscriptions inside it inherit that setting automatically. This saves time and reduces mistakes. It also helps with compliance because you can enforce rules like “no one can create a virtual machine in a specific region” across your entire company with just one policy applied at a Management group level. This structure keeps cloud environments organized, secure, and easier to audit.

## Technical definition

A Management group in Microsoft Azure is a hierarchical container within the Azure governance model that enables centralized management of access, policies, and compliance across multiple subscriptions. Management groups form a key component of Azure’s identity and governance architecture, sitting above subscriptions in the resource hierarchy. The hierarchy works as follows: each Azure tenant has a single root Management group, which can contain one or more child Management groups, each of which can contain subscriptions or further child Management groups. The maximum depth of this hierarchy is six levels, excluding the root level. This structure allows organizations to align Azure resources with their business structure, such as departments, regions, or projects. Management groups rely on Azure Role-Based Access Control (RBAC) and Azure Policy to enforce governance. When you assign a role (like Contributor or Reader) to a user at a Management group scope, that user automatically gets the same permissions on all subscriptions within that group, unless overridden by a more specific role assignment at a lower level. Similarly, Azure Policy assignments at the Management group level are inherited by all child subscriptions and resource groups. This inheritance is crucial for applying compliance standards, such as GDPR or ISO 27001, across the entire organization. Management groups also interact with Azure Blueprints (now deprecated but still referenced) and Azure resource locks. They are managed through the Azure portal, Azure PowerShell, Azure CLI, or REST API. The root Management group is automatically created when you first access the Management groups blade in the portal. Deleting or moving Management groups requires careful planning because it affects all subscriptions within. For exam purposes, you must understand that Management groups are free to use, do not incur extra cost, and are a core part of the Microsoft Azure Well-Architected Framework’s operational excellence pillar. They are also essential for enterprise-scale landing zones and are tested in certifications like Azure Administrator (AZ-104) and Azure Solutions Architect (AZ-305).

## Real-life example

Think of a large international hotel chain. The chain has a corporate headquarters that sets rules for all hotels, such as security standards, check-in procedures, and pricing policies. Each hotel is like a separate Azure subscription, it operates independently but must follow the corporate rules. Now imagine the chain has several regional divisions: North America, Europe, and Asia. Each region manages its own hotels but also needs extra regional policies, like local tax compliance. This is exactly how Management groups work. The root Management group is the corporate headquarters. Under it, you create child Management groups for each region. Under the North America group, you put all the hotels (subscriptions) in that region. If the corporate headquarters decides that all hotels must use a specific security camera system, they apply that policy to the root group, and every hotel automatically follows it. If the European region needs an additional policy about GDPR, they apply it only to the Europe Management group, and only hotels in Europe are affected. This hierarchy avoids manually configuring each hotel separately. It also allows delegation: a regional manager can be given Contributor access to their region’s Management group, giving them full control over all hotels in that region without needing access to other regions. This analogy shows how Management groups bring order, reduce administrative work, and enforce consistency across a large, distributed cloud environment.

## Why it matters

Management groups matter because they solve the problem of scale and governance in cloud environments. In real-world IT, organizations often have dozens or hundreds of Azure subscriptions. Managing each subscription individually leads to inconsistent permissions, security gaps, and wasted time. Management groups centralize control, allowing IT administrators to apply policies, assign roles, and enforce compliance in one place. This reduces human error and ensures that all resources follow the same standards. For example, if a company needs to ensure that no virtual machine is deployed in an unsupported region, a single Azure Policy assignment at the Management group level can block that across thousands of subscriptions. Without Management groups, you would need to apply that policy to each subscription manually, which is error-prone and time-consuming. Management groups support organizational structures. You can mirror your company’s hierarchy, divisions, departments, projects, directly in Azure, making it easier to delegate management and control costs. For instance, you can give a department head the Owner role on their department’s Management group, allowing them to manage their resources without interfering with others. Management groups also play a critical role in Azure landing zones, which are the foundation for enterprise cloud adoption. They help with billing aggregation, because you can see costs per Management group. They also simplify auditing, because compliance reports can be generated at the Management group level. For IT professionals, mastering Management groups is essential for passing Azure governance exams and for building efficient, secure, and scalable cloud environments in practice.

## Why it matters in exams

Management groups are a core topic in several Microsoft Azure exams, especially the Azure Administrator (AZ-104) and Azure Solutions Architect (AZ-305) certifications. In AZ-104, the explicit exam objective is to “manage Azure identities and governance,” which includes creating and managing Management groups, assigning RBAC roles at the Management group scope, and applying Azure Policies at that level. You may see scenario-based questions where you need to recommend the best way to enforce a company-wide policy across multiple subscriptions. The correct answer often involves using a Management group rather than configuring each subscription individually. In AZ-305, Management groups are part of designing governance and management solutions. Questions may ask you to design a hierarchy that aligns with business units or departments, ensuring proper delegation and policy inheritance. You need to understand the limits: maximum depth of 6 levels (excluding root), and that the root Management group cannot be deleted or moved. In the Microsoft Security, Compliance, and Identity fundamentals (SC-900) exam, Management groups appear in the context of governance and compliance, but at a lighter level. Exam traps often focus on inheritance: learners might think a role assigned at the Management group scope applies only to that group and not to child subscriptions, but the truth is it does apply recursively. Another trap is confusing Management groups with resource groups. Management groups contain subscriptions, not resources directly. Also, remember that Management groups can be nested up to six levels deep. Questions might also test your knowledge of when to use Management groups versus Azure Policy versus RBAC. Always look for keywords like “company-wide,” “all subscriptions,” or “centralized governance.” The right answer often points to Management groups. Finally, some questions present a scenario where you need to move a subscription between Management groups, you should know that moving a subscription changes its inherited policies and roles, which could break existing functionality if not carefully planned.

## How it appears in exam questions

Exam questions about Management groups typically fall into several patterns. The first is scenario-based design. For example: “A company has 50 subscriptions for different departments. The IT team wants to enforce a policy that all subscriptions must use Azure Security Center. What is the most efficient way?” The correct answer is to create a Management group, assign the policy at that group, and place all subscriptions under it. A distractor might be to apply the policy to each subscription individually, that is possible but not efficient. The second pattern is inheritance and scope. You might be asked: “A user is assigned the Reader role at the root Management group. Can this user read resources in a child subscription?” The answer is yes, because RBAC assignments at the Management group level are inherited by all child subscriptions unless there is a deny assignment at a lower level. The third pattern is hierarchy and limits. A question may ask: “How many levels deep can Management groups be nested?” The answer is six, excluding the root. Another pattern is moving subscriptions. For instance: “A subscription is moved from Management group A to Management group B. What happens to existing policies and roles?” The answer: the subscription inherits the policies and roles from Management group B, and loses those from Management group A. This can cause unexpected changes in access or compliance. Configuration questions might involve the Azure portal or CLI. For example: “Which Azure CLI command creates a new Management group?” You need to know `az account management-group create` or the PowerShell equivalent. Troubleshooting questions might present a scenario where a policy is not being applied to a subscription; the solution could be that the subscription is not under the correct Management group, or the policy is assigned at a lower scope and overridden. There are questions about the root Management group itself, you may be asked whether it can be deleted or renamed. The answer is no, it cannot be deleted, but it can be renamed. Knowing these patterns helps you quickly identify the correct answer in an exam setting.

## Example scenario

Imagine you work as a cloud administrator for a university with three campuses: North, Central, and South. Each campus has its own IT team and its own Azure subscription to manage resources like virtual labs, student portals, and research databases. The university’s central IT department wants to enforce two rules across all campuses: first, all virtual machines must use a specific antivirus extension; second, no one can create resources outside the United States. Instead of asking each campus IT team to manually apply these rules to their subscription, you decide to use Management groups. You go to the Azure portal and create a root Management group called “University.” Inside it, you create three child Management groups: “North Campus,” “Central Campus,” and “South Campus.” Then you move each campus’s subscription into its respective group. Now, you assign the antivirus policy at the root “University” Management group, so it automatically applies to all three campuses. You also assign the region-restriction policy at the same level. A few weeks later, one campus hires a new intern who needs read-only access to all resources in their campus. Instead of granting access to the subscription directly, you assign the Reader role to the intern at the “North Campus” Management group. The intern can now view all resources within that campus’s subscription. This scenario shows how Management groups centralize management, reduce manual work, and maintain consistency. It also demonstrates delegation: each campus IT team still has full control within their own Management group, but the university’s central policies are enforced organization-wide.

## Common mistakes

- **Mistake:** Thinking Management groups contain resources directly like virtual machines or storage accounts.
  - Why it is wrong: Management groups only contain subscriptions, not individual resources. Resources live inside resource groups, which are inside subscriptions.
  - Fix: Remember the hierarchy: Management group contains subscriptions, subscriptions contain resource groups, and resource groups contain resources.
- **Mistake:** Believing that a role assigned at a Management group scope does not apply to child subscriptions.
  - Why it is wrong: RBAC and policy assignments at the Management group level are inherited by all child subscriptions and resource groups unless overridden by a deny assignment.
  - Fix: Always assume inheritance flows downward. If you assign Contributor at a Management group, it applies to all subscriptions underneath.
- **Mistake:** Creating Management groups haphazardly without planning the hierarchy, leading to more than six levels of nesting.
  - Why it is wrong: Azure supports a maximum of six levels of Management groups (excluding root). Exceeding this limit requires restructuring, which is disruptive.
  - Fix: Plan your hierarchy beforehand. Keep it flat enough to avoid hitting the depth limit, ideally no more than 3-4 levels.
- **Mistake:** Confusing Management groups with resource groups or Azure Policy assignments.
  - Why it is wrong: Resource groups are logical containers for resources, while Management groups are containers for subscriptions. Policy assignments can be applied at both levels, but the scope differs.
  - Fix: Resource group = folder for resources. Management group = folder for subscriptions. Use Management groups for organizational-wide governance, resource groups for resource organization.
- **Mistake:** Attempting to delete the root Management group.
  - Why it is wrong: The root Management group is automatically created and cannot be deleted. It can only be renamed.
  - Fix: Never try to delete the root Management group. If you need to reorganize, move child groups and subscriptions, but leave the root in place.

## Exam trap

{"trap":"A question states: “A policy is applied to the root Management group. Will it affect a subscription that is not under any custom Management group?” Learners often answer “No” because the subscription is not in a custom group.","why_learners_choose_it":"They think inheritance only flows through custom Management groups they created, forgetting that every subscription is always under the root Management group by default.","how_to_avoid_it":"Remember that every Azure subscription is automatically a child of the root Management group. Any policy or role assigned at the root Management group applies to all subscriptions in the tenant, even if they are not placed into a custom group."}

## Commonly confused with

- **Management group vs Resource group:** A resource group is a logical container for Azure resources like virtual machines and databases. A Management group is a container for subscriptions, not resources. Resource groups are inside subscriptions, which are inside Management groups. (Example: If you have 10 virtual machines, you put them in a resource group. If you have 5 subscriptions, you put them in a Management group.)
- **Management group vs Azure Policy:** Azure Policy is a service used to create, assign, and manage policies. Management groups are the containers where policies can be assigned at a broad scope. Policy assignments are often placed on Management groups, but they are not the same thing. (Example: A Management group is like a filing cabinet drawer; Azure Policy is the rule you tape to the drawer that says “No toys allowed.” The rule is applied to the drawer, but the drawer itself is just the container.)
- **Management group vs Subscription:** A subscription is a billing and management boundary that contains resource groups and resources. A Management group is a higher-level container that groups multiple subscriptions together. Subscriptions are the items inside Management groups. (Example: A subscription is like an individual bank account. A Management group is like a family of bank accounts managed under one umbrella for easier oversight.)
- **Management group vs Azure AD tenant:** An Azure AD tenant is a dedicated instance of Azure Active Directory that holds identities and permissions. The root Management group lives inside the tenant, but the tenant itself is not a Management group. The tenant is the overall directory, while Management groups are a governance feature within it. (Example: The tenant is the whole company building. The Management group is a folder inside the building that holds subscriptions (departments).)

## Step-by-step breakdown

1. **Create the root Management group** — When you first access the Management groups blade in the Azure portal, a root Management group is automatically created for your Azure AD tenant. This root group is the top-level container and cannot be deleted. It serves as the starting point for your hierarchy.
2. **Define your hierarchy** — Plan how you want to organize your subscriptions. Common patterns include by department (Sales, Engineering), by environment (Production, Development), or by region (US, Europe). Create child Management groups under the root to reflect this structure.
3. **Create child Management groups** — In the Azure portal, go to Management groups, click “Create,” and give the group a name and a display name. You can also use Azure PowerShell with the `New-AzManagementGroup` command or Azure CLI with `az account management-group create`. Each child group can have its own child groups, up to six levels deep.
4. **Move subscriptions into Management groups** — Select a subscription and choose “Move” to place it under the correct Management group. The subscription will immediately inherit any policies and RBAC roles assigned at the parent Management group. Be careful because moving a subscription can change access and compliance rules.
5. **Apply RBAC roles at the Management group scope** — Assign roles like Owner, Contributor, or Reader at the Management group level. For example, grant the “Reader” role to a user at the “Finance” Management group. That user can now view all resources in all subscriptions under that group, without needing individual assignment to each subscription.
6. **Apply Azure Policies at the Management group scope** — Create or assign built-in Azure Policies (e.g., “Allowed locations”) at the Management group level. All child subscriptions will inherit these policies. This ensures consistent compliance across the organization without manual configuration.
7. **Monitor and audit** — Use Azure Policy compliance reports and Azure Monitor to check that all subscriptions under each Management group follow the assigned policies. You can also export cost data per Management group for billing analysis. Regularly review the hierarchy to ensure it still meets organizational needs.

## Practical mini-lesson

Management groups are a fundamental tool for Azure governance, and every IT professional working with Azure should understand how to use them effectively. In practice, when you first start using Azure for an organization, you likely have only one subscription. As the company grows, you add more subscriptions for different departments, environments, or projects. Without Management groups, each subscription is managed in isolation. This means that if you want everyone to use a specific tagging policy, you must apply it to each subscription individually. That is inefficient and prone to errors. Management groups solve this by allowing you to apply governance at a central point. The key to using Management groups well is planning your hierarchy. A common approach is to create a hierarchy based on your organization’s structure: one group for each major business unit. However, you might also consider using a hierarchy based on environments, such as Production, Test, and Development. Some organizations use a combination: first by environment, then by department. Whatever you choose, keep it simple. Too many levels make management complex and can hit the six-level limit. Another practical consideration is delegation. You can give a department manager the Contributor role on their department’s Management group. That manager can then create subscriptions, assign resources, and manage policies within that group, without having access to other parts of the organization. This is a powerful way to scale administration. However, be careful with inheritance. When you move a subscription from one Management group to another, its inherited policies and roles change. This can break existing applications if, for example, a resource deployment is blocked by a new policy. Always test moves in a non-production environment first. Also, remember that the root Management group should be tightly controlled. Only a few global administrators should have Owner access to it, because a mistake at the root level affects all subscriptions. In terms of cost, Management groups themselves are free, but the policies you assign may incur costs if they trigger compliance evaluations. Finally, for exam preparation, you should practice creating Management groups using the Azure portal, CLI, and PowerShell. Understand how to view inheritance, check effective policies, and troubleshoot issues. The more hands-on experience you have, the easier it will be to answer complex scenario questions.

## Memory tip

Think of Management groups as “umbrellas” that cover all subscriptions underneath, whatever you put under the umbrella applies to everything below.

## FAQ

**Can I create a Management group without having the root group?**

No, the root Management group is automatically created for your Azure AD tenant. You cannot create custom Management groups without it. The root group is the top-level container for your entire hierarchy.

**How many subscriptions can be in one Management group?**

There is no hard limit on the number of subscriptions in a Management group. However, Azure has overall subscription limits per tenant (default 50, but can be increased). Practically, you can group as many subscriptions as you need.

**Does moving a subscription between Management groups affect existing resources?**

It does not directly affect existing resources, but it does change which policies and RBAC roles apply to the subscription. Resources may become non-compliant with new policies, and user permissions may change. Always review the target Management group’s settings before moving.

**Can I apply different policies to different subscriptions within the same Management group?**

Yes, you can apply additional policies directly at the subscription or resource group level. These more specific assignments can either complement or override (if using Deny effect) the policies inherited from the Management group.

**Is there a cost for using Management groups?**

No, Management groups are free to use. The only costs come from the Azure resources within the subscriptions and from Azure Policy compliance evaluations if you have a large number of policies and resources.

**Can I rename or delete a Management group?**

You can rename any Management group, including the root. You can delete custom Management groups, but only if they are empty (no child groups or subscriptions). The root Management group cannot be deleted.

## Summary

Management groups are a powerful Azure feature that enables centralized governance, policy enforcement, and role-based access control across multiple subscriptions. They form a hierarchical structure starting with a root Management group, under which you can create child groups to reflect your organization’s structure, such as departments or environments. By applying policies and roles at the Management group level, you ensure consistency, reduce administrative overhead, and improve compliance. For IT professionals aiming for Azure certifications like AZ-104 or AZ-305, understanding Management groups is crucial because they appear in numerous scenario-based questions about governance, inheritance, and delegation. Common mistakes include confusing Management groups with resource groups, forgetting that roles and policies are inherited by all child subscriptions, and trying to delete the root Management group. In exams, focus on the hierarchy limits (six levels), the default inheritance behavior, and the practical implications of moving subscriptions between groups. Mastering Management groups will help you design scalable and secure Azure environments and pass your certification exams with confidence.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/management-group