What Does Management Group Design Mean?
Also known as: management group design, azure management group, az-305 governance, management group hierarchy, azure policy inheritance
On This Page
Quick Definition
Management Group Design is about organizing your Azure subscriptions into a tree-like structure. This structure helps you apply rules, policies, and access controls to groups of subscriptions at once. Instead of managing each subscription separately, you can manage them as a single unit. This makes governance and compliance much easier as your cloud environment grows.
Must Know for Exams
Management Group Design is a core topic in the Microsoft Azure certification exams, especially the AZ-305 Designing Microsoft Azure Infrastructure Solutions exam. This exam tests your ability to design identity, governance, and monitoring solutions. The exam objectives explicitly include designing a governance model, selecting an appropriate management group hierarchy, and applying Azure Policy and RBAC at the management group level.
You will encounter scenario-based questions that require you to understand the order of inheritance. For example, if a policy assigned at the root management group conflicts with a policy assigned at a child management group, you need to know which one takes effect. Azure Policy uses a deny-first logic, but inheritances are additive unless there is a policy that explicitly denies or overrides.
Another common exam question involves designing a management group structure for a multinational company with different regulatory requirements. You might need to create separate management groups for regions that have specific compliance needs, like Europe or Asia. Then, you would assign policies at those management groups that enforce local regulations.
The exam also tests whether you know the limitations of management groups. For example, the maximum depth of the hierarchy is six levels. You cannot move or delete the root management group.
Each subscription can belong to only one management group. These constraints are important for your design. You should also understand that management groups work with Azure Policy, RBAC, and cost management, but not with every Azure service directly.
The AZ-305 exam is not the only one that covers this topic. The AZ-104 exam may also touch on management groups, though at a more basic level. The AZ-500 exam on security may require you to design a management group structure as part of a security governance solution.
In the exam, you may be asked to recommend a management group design based on a company scenario. You need to justify your choices with reasons related to policy enforcement, access control, and administrative efficiency. You should also be familiar with the default root management group and when to use custom management groups.
Knowing the difference between assigning a role at the management group level versus the subscription level is also important because role inheritance affects who can manage what.
Simple Meaning
Imagine you are the head of a large company with many different departments. Each department has its own budget, its own projects, and its own way of doing things. Without some kind of organization, it would be chaos.
You would have no idea if the marketing department is spending too much or if the engineering team is following security rules. Management Group Design is like creating a filing cabinet for all these departments. You put related departments into the same drawer.
You put the whole company into the cabinet. Then, you can lock the entire cabinet with one key or put a sign on the drawer that says these departments must follow certain rules. In Azure, your subscriptions are like the individual departments.
A management group is like a drawer that holds several related subscriptions. You can create a hierarchy of drawers inside drawers. For example, you might have a drawer called All Subscriptions that holds everything.
Inside that, you have drawers like Production and Non-Production. Inside Non-Production, you might have drawers for Development and Test. The top of the entire hierarchy is called the root management group.
Every Azure subscription in your organization belongs to exactly one management group. When you apply a policy or an access control to a management group, it automatically applies to every subscription inside it and every resource in those subscriptions. This is incredibly powerful.
You can set a rule that says no one can create virtual machines in a certain region, and that rule will apply to thousands of subscriptions at once. You can also assign a team to manage an entire department by giving them access at the management group level. This design is not random.
You have to plan it carefully based on your company structure, your security requirements, and your compliance needs. A good design saves time, reduces errors, and keeps your cloud environment secure. A bad design can lead to confusion, security gaps, and extra work for administrators.
Management Group Design is the blueprint for how you organize and govern your entire Azure estate.
Full Technical Definition
Management Group Design in Microsoft Azure refers to the deliberate structuring of management groups into a hierarchical tree to facilitate policy-based governance and role-based access control (RBAC) across multiple Azure subscriptions. Management groups are containers that help you manage access, policies, and compliance on a large scale. The hierarchy can be up to six levels deep, not including the root management group or the subscription level.
The root management group is automatically created when you first start using management groups in a tenant. Every subscription and management group in the tenant is a descendant of this root. The root management group cannot be moved or deleted.
You can assign Azure Policy definitions and role assignments at any level in the hierarchy. These assignments are inherited by all child management groups and subscriptions. This inheritance is the core mechanism that makes management groups so effective for governance.
For example, if you assign a policy that requires encryption on all storage accounts at the root management group, every subscription and every storage account in every subscription must comply. If you assign a custom role to a user at a production management group, that user has those permissions only in the subscriptions under that production group. Management groups support Azure Policy, Azure RBAC, and cost management.
You can also use Azure Blueprints to deploy consistent environments that include resource groups, policies, and role assignments. However, Blueprints are being replaced by deployment stacks. When designing a management group hierarchy, you must consider organizational alignment, environmental separation, and regulatory boundaries.
Common patterns include aligning by department, by geography, by environment type like production versus development, or by a combination of these factors. Azure allows up to 10,000 management groups in a single directory. A management group can have multiple child subscriptions or child management groups.
The structure is flexible but must be planned carefully. Changes to the hierarchy can affect inheritance of policies and roles. Moving a subscription from one management group to another can change its governance posture.
You should avoid creating a flat structure with too many subscriptions in one management group because it reduces the benefit of hierarchical management. Tools like Azure Policy, Azure Blueprints, and Azure Resource Manager templates work with management groups. The Azure portal, Azure CLI, Azure PowerShell, and REST API all support management group operations.
Management Group Design is a key element of the Cloud Adoption Framework for Azure, which provides best practices for organizing cloud resources. It is also a fundamental concept for the Azure Architecture Center's governance and compliance guidance.
Real-Life Example
Think about a large office building that houses many different companies. Each company rents a floor or a suite. The building has a main entrance with a security desk. The security guard checks everyone who comes in.
Now imagine that the building management wants to enforce certain rules for all tenants. For example, no smoking in the hallways, fire doors must remain closed, and all deliveries must go through the loading dock. The building management can put up signs at the main entrance that apply to everyone.
This is like applying a policy at the root management group. Now suppose the building is divided into wings: the East Wing and the West Wing. Each wing has its own security guard who can also set additional rules.
For example, the East Wing might require all visitors to sign in, while the West Wing allows badge access only. These wing-level rules apply to everyone in that wing, on top of the building-wide rules. This is like creating management groups for different departments in your organization.
Each management group can have its own policies and access rights. Now take it one step further. Inside the East Wing, there are two floors: Floor 1 and Floor 2. Floor 1 is for technology companies, and Floor 2 is for finance companies.
Each floor might have its own additional rules, like requiring two-factor authentication for finance floors. This is like creating child management groups under a parent management group. Each level adds more specific rules, but everyone still follows the building-wide rules.
If a company moves from Floor 1 to Floor 2, they immediately start following the finance floor rules. This is exactly what happens when you move a subscription from one management group to another in Azure. The policies and roles that apply to the destination management group automatically apply to the subscription.
This analogy shows how a well-designed hierarchy makes it easy to manage large numbers of subscriptions. You set broad rules at the top, and you add more specific rules as you go deeper. You can also grant access to whole wings or floors at once, rather than managing each office door individually.
Why This Term Matters
Management Group Design matters because it directly affects how effectively you can govern and secure your Azure environment. Without a well-planned hierarchy, you end up managing each subscription individually. This is not sustainable when you have hundreds or thousands of subscriptions.
Each subscription would need separate policy assignments, separate role assignments, and separate compliance monitoring. This creates a huge administrative burden and increases the risk of human error. A single misconfigured subscription could expose sensitive data or violate compliance requirements.
By using management groups, you can apply policies and access controls once and have them inherited everywhere they are needed. This consistency is critical for meeting regulatory standards like GDPR, HIPAA, or SOC 2. Auditors want to see that your security and compliance controls are applied uniformly.
Management groups help you demonstrate that. They also enable delegated administration. You can give a team lead access to manage all subscriptions in their department without giving them access to other departments.
This follows the principle of least privilege. Cost management is another reason. You can view aggregate costs at the management group level, which helps with chargeback and showback to business units.
You can also apply budgets and cost alerts to management groups. When designing a solution for the real world, you need to think about how your organization is structured. Are you organized by business unit, by geography, or by project lifecycle?
Your management group design should mirror that structure. The Cloud Adoption Framework recommends starting with a simple hierarchy and adding complexity as needed. Many organizations create management groups for Sandbox, Development, Test, and Production environments.
Then, under each environment, they might have management groups for different business units. This design allows fine-grained control. For example, you can block production subscriptions from being in the wrong region while allowing development subscriptions to be more flexible.
Without management groups, you would have to configure these restrictions for every single subscription. That is error-prone and time-consuming. Management Group Design is a foundational skill for Azure administrators, architects, and security professionals.
It is one of the first things you should plan when setting up a new Azure tenant.
How It Appears in Exam Questions
In certification exams, Management Group Design appears primarily in scenario-based questions. These questions describe a company with multiple departments, multiple subscriptions, and specific governance requirements. You are asked to design the management group hierarchy or to evaluate an existing design.
For example, a question might say: Contoso has three business units: Sales, Engineering, and HR. Each business unit has two subscriptions, one for development and one for production. They need to apply a policy that blocks the creation of resources in a specific region for all production subscriptions.
What is the most efficient way to do this? The correct answer involves creating a management group for production subscriptions and assigning the policy at that management group. Another type of question asks about Azure Policy inheritance.
For instance: You assign a policy at the root management group that requires all storage accounts to be encrypted. You then assign a policy at a child management group that denies the creation of any storage account in a specific region. A user tries to create an encrypted storage account in that region.
What happens? You need to know that the deny policy at the child level takes precedence for that region. There are also questions about role-based access control. For example: You need to give a user read-only access to all subscriptions in the Engineering department.
You have a management group for Engineering that contains all Engineering subscriptions. You assign the Reader role to the user at the Engineering management group. Does this work?
Yes, the role is inherited by all subscriptions under that management group. Some questions test the limitations. For example: Your company has 15,000 subscriptions. Can you place them all under a single management group?
The answer is no, because management groups support up to 10,000 subscriptions per group, but the real constraint is that you should not do this for manageability reasons. You need to design a hierarchy that groups subscriptions logically. Another common scenario: A company wants to use Azure Policy to enforce tagging on all resources.
They have a flat management group structure. An administrator suggests moving all subscriptions under a root management group and assigning the policy there. Is this a good design?
You need to evaluate the trade-offs. A flat structure may simplify policy assignment but limits granularity. You might recommend a hierarchy that separates environments. Exam questions often include a mix of policy, RBAC, and cost management scenarios.
You need to know that management groups can be used for all three. You may also be asked about moving subscriptions between management groups and what effect that has on policies and roles. The key is to understand the inheritance model and the hierarchy depth limit.
Practise Management Group Design Questions
Test your understanding with exam-style practice questions.
Example Scenario
Scenario: A mid-sized company named Fabrikam is moving all its IT operations to Azure. They have five departments: Marketing, Sales, Engineering, HR, and Finance. Each department will have its own set of subscriptions.
The company wants to enforce a security policy that requires all virtual machines to use managed disks and be encrypted at rest. Additionally, the company has a compliance requirement that no resources can be deployed in the US Gov Virginia region for any department. The company also wants to allow the IT team to manage all subscriptions centrally without giving them access to the billing data of each department.
Solution: First, the company creates a root management group for the entire tenant. Under the root, they create a management group for each environment type: Production and Non-Production. Under the Production management group, they create a management group for each department: Marketing-Prod, Sales-Prod, Engineering-Prod, HR-Prod, and Finance-Prod.
Under the Non-Production management group, they create similar groups for Dev and Test environments. They assign the policy requiring managed disks and encryption at the root management group. This policy automatically applies to every subscription in every department.
They assign the policy blocking the US Gov Virginia region at the Production management group. This policy applies only to production subscriptions. The Non-Production subscriptions are not restricted by this policy, so developers can still use that region for testing if needed.
They assign the Contributor role to the IT team at the root management group. This gives the IT team contributor access to all subscriptions under the root. However, because the company wants to restrict billing access, they do not assign the Billing Reader role at the root.
Instead, they assign financial staff the Billing Reader role at the department management groups. This design efficiently meets all the company's requirements. It centralizes common governance, allows flexibility for different environments, and maintains departmental cost isolation.
Common Mistakes
Creating too many management groups without a clear plan.
Each management group adds complexity. Managing a deep or wide hierarchy can become confusing. It can also slow down policy evaluation. Without a plan, you may create duplicate or overlapping rules.
Start with a simple hierarchy based on environment types or departments. Use the Cloud Adoption Framework's recommended structure. Only add more levels when you have a clear need for additional separation.
Assigning policies only at the subscription level and ignoring management groups.
This defeats the purpose of management groups. You lose the ability to apply a single policy to many subscriptions at once. It creates administrative overhead and increases the risk of missing a subscription.
Identify policies that apply to all subscriptions and assign them at the root or a high-level management group. Use subscription-level assignments only for exceptions.
Placing all subscriptions under a single management group without any hierarchy.
A flat structure makes it hard to apply different policies to different groups. You cannot give different access rights to different departments. All subscriptions are treated the same, which is rarely correct.
Create at least two management groups: one for production and one for non-production. Then, if needed, create child groups for departments or projects.
Assigning a role at the root management group that gives too many permissions to too many users.
The root management group covers every subscription in the tenant. Assigning a high-privilege role like Owner at the root gives that user full control over everything. This is a security risk.
Use the principle of least privilege. Assign roles at the lowest possible management group that still meets the need. If a team only needs to manage development subscriptions, assign the role at the development management group, not the root.
Not considering the six-level depth limit when designing the hierarchy.
Azure allows only six levels of management groups below the root. If you exceed this limit, you cannot create the hierarchy you want. This can force a redesign.
Plan your hierarchy counting from the root as level 0. Keep the depth within six levels. If you need more granularity, consider using tags or resource groups instead.
Exam Trap — Don't Get Fooled
A question asks whether you can assign an Azure Policy at the management group level that denies the creation of all resources in a specific region, and then a user tries to create a resource in that region. The trap is that the candidate thinks the policy at the management group level can be overridden by a policy at the subscription level. Remember that Azure Policy uses an effective deny or allow based on the most restrictive policy in the hierarchy.
If any policy in the inheritance chain denies an action, it is denied. This is different from RBAC, where an explicit deny at a lower level takes precedence over an allow at a higher level. For Azure Policy, the deny is absolute.
Commonly Confused With
A management group is a container for subscriptions, not a subscription itself. A subscription holds resources and has its own billing and access control. A management group organizes multiple subscriptions and applies policies and roles to them. You cannot put resources directly in a management group; they must be in a subscription.
Think of a subscription as an individual house, and a management group as a neighborhood. The neighborhood has rules, but each house has its own address and owner.
A resource group is a container within a subscription that holds related resources like virtual machines and databases. A management group sits above subscriptions and cannot contain resource groups directly. Resource groups are logical groupings for deployment and management within a subscription, while management groups are for governance across subscriptions.
A resource group is like a room in a house. All the furniture in that room belongs together. A management group is like the city planning office that sets rules for entire neighborhoods, not individual rooms.
Azure Policy is a service that creates rules for resource compliance. Management groups are the structure where you can assign those policies. You can also assign policies at the subscription or resource group level. Management groups are the container, and Azure Policy is one of the things you put inside that container.
A management group is a filing cabinet drawer. Azure Policy is a rule written on a sticky note placed on the drawer. The sticky note affects everything inside the drawer.
The root management group is the top-level container in the management group hierarchy. It is automatically created and cannot be deleted or moved. Every other management group and subscription is a child of this root. Management Group Design refers to the entire hierarchy you build, including the root.
The root management group is like the main building entrance. Every office and floor is inside that building. The rest of your management group design is like the floor plan inside.
Step-by-Step Breakdown
Identify Organizational Structure
Map out your company's departments, business units, or geographic regions. This will serve as the basis for your management group hierarchy. Consider how your organization is managed and who needs access to what.
Choose a Hierarchy Pattern
Decide whether to organize by environment type such as production, development, and test, by business unit, by geography, or a combination. The Cloud Adoption Framework recommends starting with an environment-based pattern for most organizations.
Create the Root Management Group
The root management group is created automatically when you start using management groups. Ensure that you assign the necessary global policies and roles here. This sets the baseline for all subscriptions.
Create Child Management Groups
Add management groups under the root for each top-level category you identified, such as Production and Non-Production. Then, add more child groups for departments or projects as needed, keeping the depth within six levels.
Move Subscriptions into the Appropriate Groups
Assign each Azure subscription to the management group that aligns with its purpose. A subscription can belong to only one management group. Moving a subscription applies the policies and roles of the new parent group.
Apply Policies and Role Assignments
Assign Azure Policy definitions and RBAC roles at the appropriate management group level. Policies and roles are inherited by all child groups and subscriptions. Test the assignments to ensure they work as intended.
Review and Refine
Regularly review your management group hierarchy as your organization grows. Adjust the structure if new departments or compliance requirements emerge. Use Azure Policy insights to monitor compliance.
Practical Mini-Lesson
Management Group Design is a foundational skill for any Azure professional. In practice, you will use management groups to implement governance at scale. The first step is to understand your organization's structure.
Do you have separate teams for development and operations? Are there regulatory requirements that differ by region? Your design should reflect these realities. A common approach is to create a management group for each major environment type.
For example, you might have a management group called Production, another called Non-Production, and another called Sandbox. Under Production, you could have child groups for each business unit like Sales-Prod and Engineering-Prod. Under Non-Production, you have groups for Development and Test.
This pattern allows you to assign strict policies to Production, such as requiring encryption and blocking certain regions, while allowing more flexibility in Non-Production. You can also give development teams contributor access to their own subscriptions without giving them access to production. When you assign a policy or role at a management group, it flows down to all child groups and subscriptions.
This inheritance is the key feature. However, you must be careful. If you assign a policy that denies the creation of a resource type at the root level, it will affect every subscription.
Only do this if it is truly a global requirement. For example, you might want to block the use of a legacy virtual machine size across the entire company. Otherwise, assign policies at the lowest effective level.
In real-world scenarios, you will also need to manage the migration of subscriptions. When a subscription moves from one management group to another, it inherits the policies of the new parent. This can cause compliance violations if the subscription contains resources that do not meet the new policies.
Plan for this by evaluating the impact before moving. Azure Policy has a concept of remediation, which can automatically fix non-compliant resources, but it requires a managed identity and appropriate permissions. Another practical consideration is naming conventions.
Use clear and consistent names for your management groups. For example, Prod-Marketing, Dev-Sales, or Geo-EU-Prod. Avoid vague names like Group1 or Test. Good naming helps everyone understand the purpose of each group.
You should also document your hierarchy and the policies assigned at each level. This documentation is useful for audits and for onboarding new team members. Tools like Azure Policy Insights and Azure Resource Graph can help you visualize your hierarchy and check compliance.
Finally, remember that management groups are not a replacement for resource groups. You still need to organize resources within subscriptions using resource groups. Management groups are the top-level organizational tool for governance, not for resource management.
Memory Tip
Remember the six-level limit: from root to subscription, you can only have six management groups in the chain. Write Root as 0, then count up to 5 for the deepest group.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
AZ-305AZ-305 →Related Glossary Terms
Frequently Asked Questions
Can I move a subscription between management groups?
Yes, you can move a subscription to a different management group. The subscription will then inherit the policies and roles from the new parent group. Make sure the subscription is compliant with the new policies before moving.
How many management groups can I have in one directory?
You can have up to 10,000 management groups in a single Azure Active Directory tenant. This is a soft limit that can be increased by request.
What is the maximum depth of the management group hierarchy?
The hierarchy can be up to six levels deep, including the root management group. The root management group is level 0, and you can child groups down to level 5.
Can I assign Azure Policy at the management group level?
Yes, you can assign Azure Policy definitions at the management group level. The policy will be inherited by all subscriptions and resource groups under that management group.
Do management groups affect billing?
Management groups themselves do not generate costs. However, they can be used to view aggregated costs for all subscriptions under them, which helps with cost management and chargeback.
Can I delete the root management group?
No, the root management group cannot be deleted or moved. It is automatically created when you first use management groups. You can rename it, but you cannot remove it.
Summary
Management Group Design is about creating a logical hierarchy of containers in Azure to organize your subscriptions and apply governance at scale. The design directly affects how policies, access controls, and cost management are applied across your entire cloud environment. A well-designed hierarchy uses a maximum of six levels, mirrors your organizational structure, and applies the most restrictive policies at the highest level needed.
Common patterns include grouping by environment like production and development, by business unit, or by geography. For certification exams like the AZ-305, you need to understand inheritance, the six-level depth limit, and how to combine management groups with Azure Policy and RBAC. Avoid common mistakes like creating a flat structure, assigning too broad of roles at the root, or ignoring the depth limit.
Remember that management groups are a container for subscriptions, not for resources. They are a governance tool, not a deployment tool. With careful planning, management group design makes your Azure environment easier to manage, more secure, and compliant with regulations.