Management Group Hierarchy

Management groups are the top-level governance and access structure above subscriptions. They exist for one reason: to let Azure Policy and Azure RBAC be assigned once and inherited by every subscription beneath them. Everything in this series — policy, identity, connectivity — anchors to this hierarchy.

Purpose

This page defines the management group hierarchy that the rest of the platform hangs from. New subscriptions are placed under the tenant root management group by default, so a landing zone design must decide, deliberately, where subscriptions belong instead.

Design Reasoning

The hierarchy should be simple and purpose-driven. Microsoft recommends designing management groups around governance, policy, compliance, connectivity, and feature needs — not around the company org chart, and not around Azure regions.

Two practical rules follow directly from Microsoft’s guidance:

• Keep it shallow. Aim for three to four levels. A management group tree supports up to six levels of depth (excluding the tenant root and the subscription level), but depth is complexity, and complexity is debugging inherited policy.
• Limit root-level assignments. Everything below the tenant root inherits root assignments, so reserve them for genuinely tenant-wide requirements. Most guardrails belong lower in the tree.

Microsoft’s reference architecture places an intermediate root management group (given an organization prefix, for example contoso) directly under the tenant root. This keeps your hierarchy out of the tenant root group, lets you move existing subscriptions in cleanly, and gives you a single parent to assign baseline policy to.

Architecture Decision Record

Tradeoff: A capability-based hierarchy means the tree does not mirror how the business is organized, which can feel unintuitive at first. In exchange, policy and access scopes map directly to security and compliance needs, which is what management groups are actually for.

Recommended Configuration

A practical starting structure for a small-to-medium organization:

• platform — shared platform subscriptions, with optional child groups for identity, management, connectivity, and security
• landing-zones — workload subscriptions, with archetype child groups such as corp and online
• sandbox — isolated experimentation, with deliberately lighter guardrails
• decommissioned — a holding area for subscriptions on their way to deletion

flowchart TD
A[Tenant root group] --> B[contoso - intermediate root]
B --> C[platform]
B --> D[landing-zones]
B --> E[sandbox]
B --> F[decommissioned]
C --> C1[identity]
C --> C2[management]
C --> C3[connectivity]
C --> C4[security]
D --> D1[corp]
D --> D2[online]

This structure supports shared services in platform subscriptions, workloads grouped by archetype, sandboxes with separate guardrails, isolation of decommissioned subscriptions, and policy/RBAC inheritance at meaningful scopes.

The corp and online archetypes match how Microsoft separates workloads: corp for workloads that need corporate (often hybrid) connectivity through the hub, and online for internet-facing workloads that may not need a virtual network at all. A local archetype exists in the reference architecture for Azure Local / hybrid workloads; add it only when you have those workloads.

Example Implementation

Bicep deploys policy, RBAC, and child management groups at management group scope; the Azure CLI deploys those templates with az deployment mg create.

1
targetScope = 'managementGroup'
2

3
@description('Name of the policy assignment.')
4
param policyAssignmentName string
5

6
@description('Resource ID of the policy or initiative definition to assign.')
7
param policyDefinitionId string
8

9
resource assignment 'Microsoft.Authorization/policyAssignments@2025-03-01' = {
10
  name: policyAssignmentName
11
  properties: {
12
    displayName: 'Allowed locations baseline'
13
    policyDefinitionId: policyDefinitionId
14
    enforcementMode: 'Default'
15
  }
16
}

1
# Create the intermediate root and a child management group
2
az account management-group create --name contoso --display-name "Contoso"
3
az account management-group create --name platform --display-name "Platform" --parent contoso
4

5
# Deploy management-group-scoped Bicep (policies, RBAC, child groups)
6
az deployment mg create \
7
  --management-group-id contoso \
8
  --name platform-baseline \
9
  --location switzerlandnorth \
10
  --template-file ./infra/management-groups/main.bicep

Validation Steps

1
# Inspect the full hierarchy
2
az account management-group entities list --output table
3

4
# Confirm policy assignments at the intermediate root scope
5
az policy assignment list \
6
  --scope /providers/Microsoft.Management/managementGroups/contoso \
7
  --output table

Also confirm that workload teams do not require management-group-scoped RBAC. Broad management group permissions should be reserved for platform teams, and even then granted just-in-time through Privileged Identity Management rather than as standing access.

Common Mistakes

• Creating dev, test, and prod management groups instead of using workload archetypes and subscription boundaries.
• Copying the company org chart into the management group hierarchy.
• Assigning too many policies at the tenant root, which makes inherited policy hard to debug.
• Modeling Azure regions as management groups instead of using policy, tags, or deployment configuration.
• Granting workload teams RBAC at management group scope, which over-permissions them through inheritance.

References

• Management groups design area — Cloud Adoption Framework
• Azure management groups overview
• Protect your resource hierarchy
• Deploy Bicep files to management group scope
• Tailor the Azure landing zone architecture