Management Groups and Subscription Governance

Management groups are containers that help you manage access, policy, and compliance for multiple subscriptions. They form a hierarchy that allows you to apply governance at scale. Without management groups, you would have to assign policies and RBAC roles to each subscription individually, which becomes unmanageable in large enterprises with hundreds of subscriptions. Management groups enable you to define a structure that mirrors your organization's operational or business needs, such as by department, geography, or environment (dev/test/prod).

Azure has a single top-level management group called the Tenant Root Group. This group is automatically created when you start using Azure and is the root of the hierarchy. All management groups and subscriptions are children of this root group. You can create up to 10,000 management groups in a single directory. Each management group can have up to 3,000 child management groups (a flat limit, not depth). The maximum depth of the hierarchy is 6 levels (not including the root level). This means you can have up to 6 nested management groups below the root.

When you assign an Azure Policy or RBAC role to a management group, all child management groups, subscriptions, and resources under that group inherit that assignment. Inheritance is blocked if a more specific assignment (e.g., at the subscription or resource group level) denies the policy, but in general, policies and RBAC flow downward. This is similar to Group Policy in Active Directory.

Management groups are managed via the Azure portal, Azure CLI, PowerShell, or REST API. To create a management group using Azure CLI:

az account management-group create \
  --name "MyManagementGroup" \
  --display-name "My Management Group" \
  --parent-id "/"

To move a subscription to a management group:

az account management-group subscription add \
  --name "MyManagementGroup" \
  --subscription "MySubscription"

To view the hierarchy:

az account management-group list --expand

In PowerShell:

New-AzManagementGroup -GroupId "MyGroup" -DisplayName "My Group" -ParentId "/"

Management groups are tightly integrated with Azure Policy and RBAC. When you assign a policy at the management group level, it applies to all subscriptions and resources within that group. For example, if you assign a policy that enforces a specific SKU for virtual machines at the "Production" management group, all VMs in subscriptions under "Production" must comply. This is a powerful way to enforce compliance across an entire department or geography.

RBAC assignments at the management group level grant permissions to manage resources in all child subscriptions. For instance, assigning the "Contributor" role to a security team at the "Corporate IT" management group gives them contributor access to all subscriptions under that group. This eliminates the need to assign roles per subscription.

A subscription is a logical container for Azure resources that is associated with an Azure AD tenant. Each subscription has its own limits and quotas, such as 980 resource groups per subscription (default). Subscriptions are billed separately and have their own set of administrators. Governance at the subscription level involves applying policies, RBAC, and resource locks to ensure compliance and security.

Resource Locks prevent accidental deletion or modification of resources. There are two types: CanNotDelete (users can read and modify but not delete) and ReadOnly (users can only read). Locks are inherited from the subscription to all resource groups and resources within. However, locks do not prevent changes made by Azure services or by users with Owner permissions (though Owner is still bound by locks).

Azure Policy can be assigned at the subscription level to enforce rules like allowed locations or required tags. Policies are evaluated during resource creation and update, and can also be audited on existing resources.

Azure Blueprints (now deprecated in favor of deployment stacks) allowed you to define a repeatable set of Azure resources and policies. Blueprints could be assigned to management groups or subscriptions. While Blueprints are being phased out, understanding the concept helps: management groups provide the structure, and policies enforce the rules. For the SC-900 exam, focus on management groups and Azure Policy as the primary governance tools.

A global company with operations in North America, Europe, and Asia needs to enforce region-specific data residency laws (e.g., GDPR in Europe). They create a management group hierarchy: Root -> Geography (NA, EU, Asia) -> Department (Sales, R&D, HR). Under each geography, they assign Azure Policies that restrict allowed regions for resource creation. For example, the EU management group has a policy that only allows resources in West Europe and North Europe. Additionally, they assign RBAC roles at the geography level for regional IT teams. This ensures that a developer in Europe cannot accidentally deploy resources in the US. The hierarchy also allows cost aggregation per geography. A common misconfiguration is assigning policies at the root group that conflict with regional policies. The solution is to use policy exemptions at child scopes if needed.

A SaaS provider uses separate subscriptions for development, testing, and production. They create management groups: Root -> Environment (Dev, Test, Prod). The Production management group has strict policies: no public IP addresses, mandatory encryption, and specific VM SKUs. The Dev group has more relaxed policies. The security team is assigned the 'Security Reader' role at the root group to audit all environments. The DevOps team is assigned 'Contributor' at the Dev and Test groups but only 'Reader' at Prod. This setup prevents accidental changes to production. Performance is not an issue because management groups are logical containers with no resource overhead. However, moving a subscription from Dev to Prod requires careful planning because policies change. A common mistake is moving a subscription without updating policies, leading to non-compliant resources.

After acquiring another company, an organization needs to integrate the new company's subscriptions into their existing management group hierarchy. They create a new management group called 'Acquired' under the root and move the acquired subscriptions into it. They then apply their standard policies (e.g., require MFA, enable Defender for Cloud) at the 'Acquired' group. Over time, they restructure the hierarchy to align with their department structure. This approach minimizes disruption during integration. A pitfall is that the acquired subscriptions may have existing policies that conflict with the parent policies. The solution is to audit and remediate before moving. Also, RBAC assignments need to be cleaned up to avoid excessive permissions.