Management Groups

How to design a hierarchical governance structure for Azure at scale.

What Are Management Groups?

Management Groups are containers above subscriptions that enable:

• Hierarchical policy and RBAC assignment
• Governance at scale across thousands of subscriptions
• Logical organization of Azure resources

Why Management Groups Matter

Without Management Groups

With Management Groups

Enterprise-Scale Management Group Hierarchy

The recommended hierarchy from Microsoft CAF:

Tenant Root Group
│
└── Contoso (Intermediate Root)
    │
    ├── Platform ─────────────────── Shared platform services
    │   ├── Identity                 Azure AD, Domain Controllers
    │   ├── Management               Logging, Automation
    │   └── Connectivity             Hub network, ExpressRoute
    │
    ├── Landing Zones ───────────── Application workloads
    │   ├── Corp                     Internal applications
    │   │   ├── Corp-Prod
    │   │   └── Corp-NonProd
    │   └── Online                   Public-facing applications
    │       ├── Online-Prod
    │       └── Online-NonProd
    │
    ├── Sandboxes ───────────────── Development/experimentation
    │
    └── Decommissioned ──────────── Resources pending deletion

Why This Structure?

Management Group	Purpose	Policies Applied
Intermediate Root	Avoid modifying Tenant Root	Security baseline
Platform	Shared services isolation	Restricted network changes
Identity	Identity infrastructure	Most restrictive
Management	Monitoring infrastructure	Diagnostic requirements
Connectivity	Network infrastructure	Network-specific rules
Landing Zones	Application workloads	Workload policies
Corp	Internal apps	Require private endpoints
Online	Public apps	Allow public endpoints, require WAF
Sandboxes	Dev/Test	Audit-only, budget limits
Decommissioned	Cleanup holding	Deny all deployments

Design Decisions

Decision 1: Hierarchy Depth

Recommendation: Maximum 6 levels (including Tenant Root)

Why?

• Policy evaluation complexity increases with depth
• Troubleshooting becomes harder
• Diminishing returns after 4-5 levels

Decision 2: Intermediate Root Group

Always create an intermediate root below Tenant Root Group:

Why?

• Tenant Root policies affect ALL subscriptions (including new ones)
• Intermediate root provides flexibility
• Enables exclusions for special cases

Decision 3: Separating Prod and Non-Prod

Option A: Separate at Landing Zone level

Landing Zones
├── Corp
│   ├── Corp-Prod      ← Strict policies
│   └── Corp-NonProd   ← Relaxed policies
└── Online
    ├── Online-Prod    ← Strict policies
    └── Online-NonProd ← Relaxed policies

Option B: Separate subscriptions within same MG

Landing Zones
├── Corp
│   ├── App1-Prod-Sub
│   ├── App1-Dev-Sub
│   └── App1-Test-Sub
└── Online
    ├── Web1-Prod-Sub
    └── Web1-Dev-Sub

Recommendation: Option A for enterprises with different compliance requirements per environment.

Decision 4: Sandbox Strategy

Three common patterns:

Pattern	Structure	Use Case
Single Sandbox MG	One MG, budget-controlled subs	Small orgs
Team-based Sandboxes	MG per team	Large orgs
Time-limited	Auto-delete after 30 days	Innovation labs

Policy Assignment Strategy

Inheritance Model

Policy Assignment Matrix

Policy	Root	Platform	LZ	Corp	Online	Sandbox
Require encryption	✅	-	-	-	-	-
Require diagnostics	✅	-	-	-	-	-
Deny public IPs	❌	✅	❌	✅	❌	❌
Require WAF	❌	❌	❌	❌	✅	❌
Budget alerts	❌	❌	❌	❌	❌	✅

Sample: Policy at Management Group Scope

targetScope = 'managementGroup'

@description('The management group to assign the policy to')
param managementGroupId string = 'alz-landingzones-corp'

resource policyAssignment 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'require-private-endpoints'
  properties: {
    policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/xxx'
    displayName: 'Require Private Endpoints for PaaS'
    enforcementMode: 'Default'
    scope: '/providers/Microsoft.Management/managementGroups/${managementGroupId}'
    parameters: {}
  }
}

RBAC Assignment Strategy

Inheritance Model

Role Assignment Matrix

Role	Root	Platform	LZ-Corp	Subscription
Security Team	Reader	-	-	-
Platform Team	-	Owner	-	-
Network Team	-	Network Contributor	-	-
App Team Lead	-	-	Reader	Contributor
Developers	-	-	-	Reader (Prod)

Sample: RBAC at Management Group

targetScope = 'managementGroup'

param principalId string
param roleDefinitionId string

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(managementGroup().id, principalId, roleDefinitionId)
  properties: {
    principalId: principalId
    roleDefinitionId: '/providers/Microsoft.Authorization/roleDefinitions/${roleDefinitionId}'
    principalType: 'Group'
  }
}

Implementation with Bicep

Create Management Group Hierarchy

targetScope = 'tenant'

@description('The prefix for all management groups')
param prefix string = 'alz'

// Intermediate root
resource intermediateRoot 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}'
  properties: {
    displayName: 'Contoso'
  }
}

// Platform
resource platform 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}-platform'
  properties: {
    displayName: 'Platform'
    details: {
      parent: {
        id: intermediateRoot.id
      }
    }
  }
}

// Platform children
resource identity 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}-platform-identity'
  properties: {
    displayName: 'Identity'
    details: {
      parent: {
        id: platform.id
      }
    }
  }
}

resource management 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}-platform-management'
  properties: {
    displayName: 'Management'
    details: {
      parent: {
        id: platform.id
      }
    }
  }
}

resource connectivity 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}-platform-connectivity'
  properties: {
    displayName: 'Connectivity'
    details: {
      parent: {
        id: platform.id
      }
    }
  }
}

// Landing Zones
resource landingZones 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}-landingzones'
  properties: {
    displayName: 'Landing Zones'
    details: {
      parent: {
        id: intermediateRoot.id
      }
    }
  }
}

resource corp 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}-landingzones-corp'
  properties: {
    displayName: 'Corp'
    details: {
      parent: {
        id: landingZones.id
      }
    }
  }
}

resource online 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}-landingzones-online'
  properties: {
    displayName: 'Online'
    details: {
      parent: {
        id: landingZones.id
      }
    }
  }
}

// Sandboxes
resource sandboxes 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}-sandboxes'
  properties: {
    displayName: 'Sandboxes'
    details: {
      parent: {
        id: intermediateRoot.id
      }
    }
  }
}

// Decommissioned
resource decommissioned 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: '${prefix}-decommissioned'
  properties: {
    displayName: 'Decommissioned'
    details: {
      parent: {
        id: intermediateRoot.id
      }
    }
  }
}

Common Pitfalls

❌ Pitfall 1: Too Many Levels

Root → Region → BU → Team → Project → Environment → App → Sub
      Level 2   3     4      5         6           7      8

Too deep! Policy conflicts, troubleshooting nightmare

❌ Pitfall 2: Policy Conflicts

Resolution: Use enforcementMode: 'DoNotEnforce' for exceptions.

❌ Pitfall 3: Orphaned Subscriptions

Prevention: Policy to deny creation outside designated MGs.

❌ Pitfall 4: Over-Privileged Roles at Root

Fix: Apply least-privilege; Owner only at subscription level.

Management Group Limits

Limit	Value
MG hierarchy depth	6 levels
MGs per directory	10,000
Subscriptions per MG	Unlimited
MGs per subscription	1 (can only have one parent)
Role assignments per MG	500 (Azure RBAC)
Policy assignments per MG	500

Quick Reference Card

Concept	Description
Tenant Root	Top of hierarchy; don't modify directly
Intermediate Root	Your organization's root; apply baseline
Platform MGs	Identity, Management, Connectivity
Landing Zone MGs	Corp (internal), Online (public)
Sandbox MG	Dev/Test with budget limits
Decommissioned MG	Holding area before deletion
Policy Inheritance	Child MGs inherit parent policies
RBAC Inheritance	Roles flow down to subscriptions

What Interviewers Look For

✅ Good answers:

• Explain inheritance model
• Describe why intermediate root is important
• Discuss policy vs RBAC differences
• Mention the 6-level depth limit

❌ Red flags:

• Flat structure without MGs
• Assigning Owner at root level
• No intermediate root group
• Creating too many hierarchy levels

Next Steps

Continue to Subscription Strategy to learn how to organize workloads into subscriptions.