Prerequisites

Line up the following before you create a single management group.

Access and tooling

You need a Microsoft Entra tenant with Global Administrator rights so you can grant yourself access to the root management group [1]. You also need either the Hierarchy Settings Administrator built-in role or equivalent write access on the root to change defaults and authorization rules [7]. An active subscription with Owner or User Access Administrator is required for role-assignment tests. The Azure portal, Azure CLI, Azure PowerShell, and the ARM REST API all expose the same operations - new portal features appear within 180 days of API release [2].

Conceptual baseline

Know the four scopes: management group, subscription, resource group, and resource [2]. Know that the AZ-104 governance domain accounts for 20-25 percent of the exam [6]. Have a naming convention and tagging strategy committed to paper before clicking anything. Know the headline limits: 10,000 management groups per directory, six depth levels below root, and 980 resource groups per subscription [1][3]. These numbers will shape every design decision that follows.

1. Grant Root Access and Prepare the Root Management Group

Every Entra directory has exactly one root management group at the top of the tree, and every subscription and management group eventually folds up into it [1]. Its default display name is "Tenant root group" and its ID is identical to the Entra tenant ID [1].

Three constraints about the root matter.

First, the root cannot be moved or deleted [1] - it is the anchor of the hierarchy. Second, no one, not even the Global Administrator who created the tenant, has default access to it. Global Administrators must grant themselves root access from the Entra admin center [1]. Third, every new subscription created in the tenant lands directly under the root by default unless a different default is configured [1].

Two structural rules apply at every level below the root. Every management group and every subscription has exactly one parent, although a management group can have many children [1]. And every subscription within a single management group must trust the same Entra tenant - which prevents cross-tenant hierarchies from forming by accident [1].

Grant root access first. Confirm the root display name and ID match the tenant. Then move to design, not configuration.

2. Design the Management Group Hierarchy Using the CAF Landing Zone Pattern

Draw the shape on paper before creating a single node. The Cloud Adoption Framework Azure landing zone reference architecture is the defensible default - it maps cleanly to AZ-104 questions and to real audit conversations [4].

The reference shape places an Intermediate root management group under the tenant root [4]. Underneath the intermediate root sit four siblings.

A Platform branch holds shared services and is usually subdivided into Management, Connectivity, and Identity child groups [4]. A Landing zones branch holds application workloads and splits into Corp (internal, network-connected) and Online (internet-facing), with Local as an optional regional variant [4]. A Sandboxes management group isolates experimentation from policy-bound production zones [4]. A Decommissioned management group catches subscriptions on their way out of the estate [4].

A note on what not to do. Do not create separate management groups for dev, test, and prod - Microsoft's guidance is to separate environments through subscriptions inside the same management group, not through new MGs [4]. Do not model Azure regions as management groups unless data residency regulations force it [4].

Keep the tree shallow. Microsoft recommends three to four levels in practice, and the hard ceiling is six below the root [4][1]. Management groups exist for policy assignment - not for billing aggregation and not for RBAC mirroring [4]. Design accordingly.

3. Create Management Groups in the Azure Portal

In the portal, open All services, search for Management groups, then select Add management group. Give the management group an ID and a display name. The ID is immutable after creation, so encode any naming convention into it first. Select the parent management group from the dropdown. Save.

Two ceilings matter while building the tree. A single Entra directory supports up to 10,000 management groups [1]. The tree can be up to six levels deep below the root, not counting the root or the subscription scope itself [1].

Plan for a delay after each change. Azure Resource Manager caches management group hierarchy details for up to 30 minutes [1].

4. Configure the Default Management Group and Require Authorization

Two hierarchy settings decide whether the design survives contact with users.

Step 1: Set a default management group for new subscriptions. Open Management groups, select the root, open Settings, then choose Change default management group [7]. Point it at Sandboxes or at a designated landing-zone group. Any new subscription created in the tenant now lands there instead of directly under the root [4]. Subscriptions under the root have no policy or RBAC scope above them — they slip past most governance.

Step 2: Require authorization for new management group creation. By default, any user in the tenant can create new management groups [7]. In the same Settings blade, switch on Permissions for creating new management groups, which enforces the Require authorization rule. Once enabled, a user must hold the Microsoft.Management/managementGroups/write operation on the root to create a child management group [7].

Changing either setting requires the Microsoft.Management/managementgroups/settings/write and /read operations on the root, which are granted by the built-in Hierarchy Settings Administrator role [7]. Assign that role to the cloud platform team and to no one else.

These two toggles eliminate most accidental hierarchy sprawl. Configure them on day one.

5. Create and Place Subscriptions Under Management Groups

Open Subscriptions, select Add, and fill in the name, billing account, billing profile, invoice section, and plan [8]. On the Advanced tab, select the target directory, the management group destination, and the subscription owners before you create [8]. Setting the management group at creation skips a manual move and the 30-minute cache delay that follows it.

Separate subscriptions per environment. Microsoft's guidance is distinct subscriptions for development, testing, and production - that gives hard isolation, per-environment cost tracking, and environment-specific policy assignment [5].

For cross-tenant ownership, Azure generates a subscription creation request, and the target tenant owner must accept ownership within seven days or the request expires [8]. Track that window.

The quotas are friendly at this level. The number of subscriptions per Entra tenant is unlimited, and the number of subscriptions per management group is also unlimited [3]. Two limits do bite. A subscription supports up to 4,000 Azure role assignments, and a management group supports up to 500 role assignments [3]. Plan group-based assignments accordingly.

Move existing subscriptions into the designed branch one at a time and verify each placement in the management group view before moving on.

6. Create Resource Groups and Place Resources

A resource group is a container that holds related resources for one Azure solution, and resources inside it should share a lifecycle [2]. Open Resource groups, select Create, choose the subscription, give the resource group a name, and choose a region.

The region is the location where the resource group metadata is stored, which matters for data residency [2]. The resources inside can live in regions different from the resource group itself, although Microsoft recommends keeping them aligned [2].

Three lifecycle rules every administrator must internalize.

Every Azure resource belongs to exactly one resource group [2]. Deleting a resource group deletes every resource inside it, with no per-resource confirmation [2]. Resource names cannot be changed after creation, so naming conventions should encode only attributes that will never change - workload code, environment, and the like [5].

Keep in mind the hard limits to plan against: 980 resource groups per subscription, 800 resources per resource type per resource group (some types are exempt), 50 tags per scope, tag keys up to 512 characters, and tag values up to 256 characters [3]. Sharded subscriptions, not larger resource groups, are the answer to scale.

7. Verify Inheritance, RBAC Scope, and Locks

Validate the design before declaring it done.

Confirm policy inheritance. Assign a benign Azure Policy at a management group scope and check that it surfaces as inherited on a child subscription, on a resource group inside that subscription, and on a resource inside that resource group. Lower scopes inherit settings from higher scopes by design [2].

Validate RBAC at every scope. AZ-104 explicitly requires candidates to assign built-in roles at management group, subscription, resource group, and resource scopes [6]. Use Access control (IAM), then Check access, to confirm effective permissions for a test user.

Apply resource locks where the blast radius justifies them. CanNotDelete blocks delete operations; ReadOnly blocks delete and modify. The cap is 20 management locks per unique scope, so reserve them for production [3]. Tags appear in downstream inventory views, but the 50-tag-per-scope ceiling applies independently at each level [3].

Stress-test concurrency. Azure Resource Manager detects concurrent updates to the same resource and returns HTTP 409 to blocked operations, allowing only one to complete [2]. Deployment ceilings are 800 per location at both subscription and management group scope [3]. Pipelines that ignore the 409 will silently drop work.

Run the verification once using the portal and once using either Azure CLI or PowerShell. Portal and API parity is the standard [2].

Troubleshooting and Common Issues

Ten failures cover most production and exam scenarios.

  1. New subscription appears under the root. The default management group was never set. Configure it through root Settings, Change default management group [7].
  2. Non-privileged user cannot create a management group. Require authorization is on. Grant Microsoft.Management/managementGroups/write on the root or refuse the request [7].
  3. Hierarchy change does not appear in the portal. Wait up to 30 minutes for the ARM cache to refresh, then reload the tree [1].
  4. Policy does not apply to a subscription. The subscription was moved out of the scoped management group. Move it back or extend the policy scope [1].
  5. Resource group deletion removed production data. Cascading deletion is the documented behavior [2]. Apply a CanNotDelete lock to every production resource group as standard practice.
  6. Role assignment limit hit. Subscriptions cap at 4,000 assignments and management groups cap at 500 [3]. Replace user assignments with group-based assignments.
  7. HTTP 409 on concurrent deployments. Serialize pipelines or accept that ARM allows only one writer per resource at a time [2].
  8. Cross-tenant subscription request expired. The seven-day acceptance window passed [8]. Reissue the request.
  9. Resource group hits 800 resources per type. Split the workload across resource groups [3].
  10. No access to the root management group. Grant yourself root access as Global Administrator from the Entra admin center [1].

Conclusion: Building a Defensible Azure Hierarchy

The Azure scope hierarchy has four levels - management group, subscription, resource group, and resource - and settings cascade top-down by inheritance [2]. The CAF landing zone shape, with Intermediate root, Platform, Landing zones, Sandboxes, and Decommissioned, is the defensible default [4]. Protect the root with a default management group assignment and the Require authorization toggle on day one [7]. Design against the hard limits - 10,000 management groups per directory, six depth levels, 4,000 role assignments per subscription, 980 resource groups per subscription - before, not after, the build [3]. The material maps directly to the 20-25 percent AZ-104 governance domain, where the passing score is 700 [6]. The one thing left to do: codify the design in ARM or Bicep templates so the next tenant rebuild is a deployment, not a rediscovery.

Sources