Hands-On with Azure Management Groups: Hierarchy, Inheritance, and Policy Enforcement

Introduction

Inheritance describes the entire reason an Azure management group exists: every role assignment, Policy binding, and hierarchy setting attached to a parent group propagates downward to every child container, subscription, and resource within scope [1]. New subscriptions arrive at the Tenant root by default [1] and that default is usually the first thing worth changing.

Prerequisites

A handful of roles and tenant conditions need to be in place before any of this is worth attempting.

Microsoft Entra Global Administrator on the tenant. Only Global Administrators can grant themselves access to the root scope, because no identity holds default access there [1].
Owner - or the role that grants access management - on any subscription that needs to move.
Resource Policy Contributor for authoring Policy definitions and assignments [5].
Hierarchy Settings Administrator on the root, which carries the managementgroups/settings/read and managementgroups/settings/write operations [7].
Portal access through All services > Management + governance > Management Groups [3].
Every child subscription has to trust the same Entra tenant [1].
The first group created in a tenant can take as long as 15 minutes because of one-time service provisioning [3].

1. Prepare the Tenant Root and Gain Root Access

The Tenant root group is created automatically and shares its ID with the Microsoft Entra tenant; the display name defaults to "Tenant root group" [1]. It cannot be moved or deleted [1]. New subscriptions land directly at root by default [1], which is exactly the behavior most organizations need to override.

Since no identity holds default access at root, the Global Administrator has to grant themselves root access before creating groups, assigning roles, or binding Policy at that scope [1]. The elevation is deliberate, and it should be reversed once setup is finished.

Anything bound at root applies across the entire tenant - every nested group, every subscription, every container, every resource [1]. Treat root assignments as tenant-wide regulation, not convenience. A single deny Policy mistakenly bound at root can block deployments in unrelated business units within minutes. Audit-first effects belong at root; enforcement effects rarely do.

Keep root spare: one or two cross-tenant audits, the elevation itself, and the hierarchy settings that route new subscriptions elsewhere. Everything else moves down.

2. Design the Hierarchy Before Touching the Portal

Microsoft's Cloud Adoption Framework landing zone reference is the standard model and the safest starting point [6]. It places an Intermediate root beneath the Tenant root, then splits into two sibling branches: Platform (holding Management, Connectivity, Identity, and Security) and Landing zones (holding Corp, Online, and Local), with Sandboxes and Decommissioned alongside [6]. Canceled landing zones move into Decommissioned and are deleted after 30 to 60 days [6].

Depth matters. The tree allows six levels of nesting beneath root and above subscription [1], but the Cloud Adoption Framework recommends keeping it flat at three to four levels [6]. Deeper trees produce more inheritance debugging, not better governance.

Each group and each subscription has exactly one parent; a single group can have many children [1]. A tenant accommodates 10,000 groups [1]

Map the design on paper before anything else. Decide which branch owns shared platform services, which owns workload landing zones, and where sandboxes will sit. The names chosen at this stage become the immutable IDs in the next section.

3. Create the Groups in the Portal

Open All services > Management + governance > Management Groups, choose + Add management group, and supply the Management Group ID along with an optional display name [3]. The ID is immutable after creation [3]. The display name can change later; the ID cannot.

A note on permissions. When hierarchy protection has not been enabled, any Entra user in the tenant can create a new group without holding the management group write operation, and the creator picks up an Owner role assignment on it [3]. That default is convenient for proof-of-concept work and dangerous for production. Section 5 closes that door.

Build the Intermediate root first. Add Platform, Landing zones, Sandboxes, and Decommissioned beneath it. Nest Management, Connectivity, Identity, and Security under Platform; then Corp, Online, and Local under Landing zones. Each child inherits from its parent the moment it is created, so any Policy authored at Intermediate root applies to every leaf immediately.

Decommissioned starts empty by design. It exists to receive retired workloads on the 30 to 60 day timer [6].

4. Move Subscriptions Under the Hierarchy

Existing subscriptions sit at the Tenant root by default and need to be relocated. From each subscription's overview blade, choose Move to point at the correct destination within the hierarchy. Each subscription has exactly one parent [1], and all subscriptions sharing one group must trust the same Entra tenant [1].

The 30-minute hierarchy cache is the operational surprise to plan around. Resource Manager caches the shape of the tree for as long as 30 minutes [1], so portal views can lag behind reality right after a move. Verify placement by reading the subscription's properties from a fresh session rather than refreshing the same blade.

Three things are worth checking per subscription: parent placement, tenant alignment, and effective Policy compliance once the cache clears. If a workload spans multiple subscriptions, move them together so they inherit the same Policy baseline at the same moment.

5. Configure Hierarchy Settings to Harden the Root

Hierarchy Settings decide who can create new groups and where new subscriptions land. Both operations require the Hierarchy Settings Administrator role on the root [7].

From Management groups, select the root, open Settings, and turn on Permissions for creating new management groups [7]. With the toggle on, creating a child group now requires the Microsoft.Management/managementGroups/write operation on the parent [7]. The casual any-user creation behavior is gone.

In the same Settings blade, choose Change default management group and pick a destination beneath the Intermediate root [7]. New subscriptions stop landing at root and arrive at a pre-governed location instead [7]. Corp under Landing zones is a common choice; an explicit Onboarding group is another.

Confirm the change by creating a test subscription and reading its parent after the cache clears. Once both toggles are in place, the root is locked.

6. Apply RBAC Inheritance at Group Scope

Built-in roles assigned at group scope flow down to child groups, child subscriptions, containers, and resources [1]. Bind Owner, Contributor, and Reader at the branch that matches the business boundary, not the leaf. A Reader assignment at Landing zones gives auditors visibility across Corp, Online, and Local without eighteen separate bindings.

Two constraints shape custom roles here. A new custom role can list only one group in its assignableScopes [1]. And DataActions are not permitted at this scope [1]. Data-plane authorization has to drop down to subscription scope.

Separate duties between RBAC and Policy. RBAC governs who can act; Policy governs what those actions are allowed to produce. A Contributor without Policy guardrails can still create non-compliant resources; a deny Policy stops the deployment regardless of role. Both layers are required for defense-in-depth.

7. Author and Assign Azure Policy at Group Scope

A Policy definition stored at a parent group is assignable to every child below it [2]. Group related definitions into an initiative (policySet) so a single assignment applies a coherent baseline rather than dozens of one-offs [5].

Eleven effects are available: addToNetworkGroup, append, audit, auditIfNotExists, deny, denyAction, deployIfNotExists, disabled, manual, modify, and mutate [4]. Microsoft recommends starting with audit or auditIfNotExists before moving to deny, modify, or deployIfNotExists [5]. Audit-first rollouts surface compliance gaps without breaking deployments.

Evaluation order is fixed: disabled, then append and modify, then deny, then audit, then manual, then auditIfNotExists, with denyAction last [4]. Behavior across overlapping assignments is cumulative most-restrictive — any matching deny blocks the resource [4].

Although Policy assigns at group scope, only subscription-level and container-level resources are evaluated [5]. Exclude specific scopes with the assignment's notScopes array; excluded resources are neither evaluated nor counted [2]. Use exemptions with an expiresOn value for time-bound deviations; creating one needs the exempt/Action verb on the target assignment in addition to Microsoft.Authorization/policyExemptions/write [2].

deployIfNotExists and modify need a managed identity, and that identity's target permissions have to be granted through the access-management role [5]. Keep root assignments minimal so debugging inherited Policy in lower branches stays tractable [6].

8. Verify Inheritance and Enforcement

Compliance evaluation runs on a 24-hour cycle alongside change-triggered evaluations [5]. There is no reason to wait the full cycle to validate: deploy a test resource that should violate a deny assignment and confirm the rejection in real time.

Read the compliance state per assignment to confirm coverage. RBAC inheritance is verified by listing role assignments on a child subscription and a child container; the inherited bindings should appear with the parent scope as their source. Resources listed in notScopes should not appear in compliance counts at all [2].

Finally, create a new subscription and confirm it lands at the default group set in Section 5 rather than at root [7]. If it does, the hierarchy is doing the work it was designed to do.

9. Troubleshooting and Common Issues

Portal hierarchy lag. The 30-minute cache makes recent moves look unapplied [1]. Open a fresh session or wait the cycle out.
First-group provisioning. The first group in a tenant can take as long as 15 minutes [3]. This is one-time and expected.
New subscriptions at root. Hierarchy Settings have not been configured, or the default group was not changed [7].
Unintended tenant-wide effects. A deny bound at root cascades [1]. Move the assignment down or scope it precisely.
Custom role rejected at group scope. The definition contains DataActions, which are not allowed at this scope [1]. Move it to subscription scope.
Scope limits. Each scope holds 500 Policy definitions, 200 initiative definitions, and 200 assignments [5]. Consolidate into initiatives.
Tenant limit. A tenant holds 2,500 initiative definitions in total [5]. Audit before adding more.
Assignment limits. Each assignment allows 400 notScopes exclusions and 512 nested conditionals [5]. Refactor when the rule sprawls.
Initiative limits. Each initiative allows 1,000 definitions and 400 parameters; each definition allows 20 parameters [5].
Remediation cap. A single remediation task targets at most 50,000 resources [5]. Split larger backlogs.
Identity-driven failures. deployIfNotExists and modify fail silently when the managed identity lacks its target permissions [5]. Re-grant through the appropriate access-management role.
Conflicting denies. Overlapping assignments produce cumulative most-restrictive behavior [4]. Identify the matching assignment in compliance details and revise scope or notScopes.

Summary

The hierarchy follows Microsoft's landing zone reference: Intermediate root beneath Tenant root, with Platform, Landing zones, Sandboxes, and Decommissioned as siblings [6]. Hierarchy Settings and a default group protect the root, so new subscriptions never land there unintentionally [7]. RBAC and Policy inherit cleanly from group scope, evaluated by the platform's fixed effect order [4]. Audit-first effects go in first; deny effects follow once the compliance picture is stable. Caches, provisioning delays, and per-scope limits are accounted for in advance.