In the context of the Azure Administrator Associate certification, configuring management groups is essential for managing governance at scale. Management groups provide a scope level above subscriptions. While subscriptions organize resources and billing, organizations with multiple subscriptions …In the context of the Azure Administrator Associate certification, configuring management groups is essential for managing governance at scale. Management groups provide a scope level above subscriptions. While subscriptions organize resources and billing, organizations with multiple subscriptions require a mechanism to efficiently manage access, policies, and compliance across them collectively.
When configuring management groups, you establish a hierarchical structure. Every Azure Active Directory tenant possesses a single 'Tenant Root Group.' Administrators can build a tree structure up to six levels deep under this root to mirror organizational hierarchies, such as geographies, business units, or environment types (e.g., Production vs. Development).
The core power of management groups lies in inheritance. When Azure Policy or Role-Based Access Control (RBAC) definitions are applied to a management group, all nested subscriptions, resource groups, and resources inherit these settings. For instance, applying a policy that restricts virtual machine sizes to a specific management group ensures that every subscription within that group enforces the rule automatically, removing the need for repetitive manual configuration.
To configure this, an Azure Administrator must create the groups, define the hierarchy, and move specific subscriptions into these groups. It is important to note limits, such as a maximum depth of six levels and support for up to 10,000 groups. Proper configuration ensures a consistent security posture and operational efficiency across the entire Azure estate.
Configure Management Groups
What are Azure Management Groups? Azure Management Groups provide a level of scope above subscriptions. They are containers that allow you to organize your subscriptions into a hierarchy and apply governance controls, such as access control (RBAC) and policies, to all subscriptions within that group effectively using inheritance.
Why is it Important? As an organization grows, the number of Azure subscriptions can increase significantly. Managing access and policies for each subscription individually becomes administratively difficult and prone to error. Management Groups solve this by allowing you to group subscriptions together (e.g., by department, environment, or geography) and apply settings once at the group level, which then cascade down.
How it Works Management groups are organized into a tree structure: 1. Tenant Root Group: Every Azure AD tenant has a single top-level management group called the 'Root' management group. All new management groups and subscriptions are children of this root by default. 2. Hierarchy: You can create a flexible hierarchy of management groups and subscriptions up to 6 levels deep (excluding the Root and the subscription level). 3. Inheritance: This is the core mechanic. Resources inherit configurations from their parents. For example, if you apply an Azure Policy to a Management Group, that policy applies to all Subscriptions, Resource Groups, and Resources underneath it. 4. Members: A management group can contain subscriptions or other management groups, but a single subscription can only belong to one management group at a time.
Key Constraints to Remember: Limit: You can have up to 10,000 management groups in a single directory. Depth: The hierarchy tree can support up to six levels of depth.
Exam Tips: Answering Questions on Configure management groups When you encounter questions about Management Groups in the AZ-104 exam, focus on the following logic:
1. Focus on Inheritance Most questions test your understanding of the flow of permissions and policies. Remember that permissions (RBAC) and Policies flow downwards. If a user has 'Contributor' access at a Management Group, they automatically have 'Contributor' access on all Subscriptions inside it. You cannot block this inheritance easily; you can only add to it (Assignment Deny permissions are rare and specific).
2. Moving Subscriptions You may be asked what is required to move a subscription from one specific Management Group to another. To do this, the user needs RBAC write permissions on the source management group, the destination management group, and the subscription itself.
3. The Root Management Group Be careful with questions regarding the 'Tenant Root Group'. Global Administrators do not have access to all subscriptions by default, but they can elevate their access to manage the Root Management Group (via the 'Access management for Azure resources' toggle in Entra ID). Once they have User Access Administrator at the Root level, they can grant themselves access to every subscription in the hierarchy.
4. Custom Roles If a question asks where to store a Custom RBAC definition so it is available to multiple subscriptions, the answer is usually a Management Group. If you define the Custom Role at the Subscription level, it cannot be used by other subscriptions.
5. Policy vs. RBAC Ensure you distinguish between governance (Policy) and access (RBAC). If the requirement is to 'prevent creation of VM types,' use Policy at the Management Group level. If the requirement is to 'allow users to manage resources,' use RBAC at the Management Group level.