Skip to main content

Challenge 17: Management Groups & subscriptions

Estimated Time and Cost

60-75 minutes | Estimated cost: Free (management plane operations) | Exam Weight: 20-25%

Scenario

Contoso Ltd. is growing fast. What started as a single Azure subscription has ballooned into six subscriptions across three departments (IT, Finance, and Engineering). The CTO wants a governance hierarchy that enforces policies consistently across all subscriptions without duplicating effort. Your job is to design and implement a management group structure that mirrors the company's organizational chart and apply governance at the right levels.

Exam skills covered

SkillWeight
Configure management groupsHigh
Manage subscriptions and governanceHigh
Move subscriptions between management groupsMedium
Implement resource locks across subscriptionsMedium
Apply RBAC at management group scopeHigh

Sysadmin ↔ Azure reference

On-Prem / SysadminAzure EquivalentNotes
Active Directory OUsManagement groupsHierarchical governance containers
Group Policy linked to OUAzure Policy at MG scopeInherited by all child subscriptions
Domain admin over OU treeRBAC at MG scopeCascades to subscriptions and resources
Moving computers between OUsMoving subscriptions between MGsGovernance policies change immediately
Delegated OU administrationSubscription-level RBACScoped admin access
Forest root domainTenant Root GroupTop of the hierarchy, cannot be moved

Tasks

Task 1: create a Management Group hierarchy

Design and create the following management group structure:

Tenant Root Group
└── mg-contoso (Contoso Ltd.)
├── mg-production (Production)
│ ├── mg-prod-it (IT Production)
│ └── mg-prod-finance (Finance Production)
└── mg-nonproduction (Non-Production)
├── mg-dev (Development)
└── mg-sandbox (Sandbox)
# Create the top-level management group
az account management-group create \
--name "mg-contoso" \
--display-name "Contoso Ltd."

# Create production hierarchy
az account management-group create \
--name "mg-production" \
--display-name "Production" \
--parent "mg-contoso"

az account management-group create \
--name "mg-prod-it" \
--display-name "IT Production" \
--parent "mg-production"

az account management-group create \
--name "mg-prod-finance" \
--display-name "Finance Production" \
--parent "mg-production"

# Create non-production hierarchy
az account management-group create \
--name "mg-nonproduction" \
--display-name "Non-Production" \
--parent "mg-contoso"

az account management-group create \
--name "mg-dev" \
--display-name "Development" \
--parent "mg-nonproduction"

az account management-group create \
--name "mg-sandbox" \
--display-name "Sandbox" \
--parent "mg-nonproduction"
Portal Alternative

Navigate to Azure Portal > Management groups. Click + Create and specify parent group, ID, and display name for each group.

Task 2: move a Subscription into a Management Group

Move your current subscription into the mg-dev management group:

# Get your subscription ID
SUB_ID=$(az account show --query id -o tsv)

# Move subscription to mg-dev
az account management-group subscription add \
--name "mg-dev" \
--subscription $SUB_ID

# Verify the move
az account management-group show \
--name "mg-dev" \
--expand \
--recurse

Task 3: assign Azure Policy at Management Group scope

Apply the built-in policy "Require a tag and its value on resources" at the mg-production scope:

# Get the policy definition ID
POLICY_DEF=$(az policy definition list \
--query "[?displayName=='Require a tag and its value on resources'].id" -o tsv)

# Assign the policy at management group scope
az policy assignment create \
--name "require-env-tag-prod" \
--display-name "Require Environment Tag (Production)" \
--policy "$POLICY_DEF" \
--scope "/providers/Microsoft.Management/managementGroups/mg-production" \
--params '{"tagName": {"value": "Environment"}, "tagValue": {"value": "Production"}}'

Task 4: apply RBAC at Management Group level

Grant a user the "Reader" role at the mg-contoso management group scope (cascading to all subscriptions):

# Get user object ID (replace with your test user)
USER_ID=$(az ad user show --id "alice@yourtenant.onmicrosoft.com" --query id -o tsv)

# Assign reader role at management group scope
az role assignment create \
--assignee "$USER_ID" \
--role "Reader" \
--scope "/providers/Microsoft.Management/managementGroups/mg-contoso"

# Verify the assignment
az role assignment list \
--scope "/providers/Microsoft.Management/managementGroups/mg-contoso" \
--query "[?principalId=='$USER_ID']" -o table

Task 5: move a Subscription between Management Groups

Simulate a department reorganization by moving the subscription from mg-dev to mg-sandbox:

# Remove subscription from current MG
az account management-group subscription remove \
--name "mg-dev" \
--subscription $SUB_ID

# Add subscription to new MG
az account management-group subscription add \
--name "mg-sandbox" \
--subscription $SUB_ID

# Verify new location
az account management-group show \
--name "mg-sandbox" \
--expand \
--recurse

Task 6: query the Management Group hierarchy

# View the full hierarchy
az account management-group list --query "[].{Name:name, DisplayName:displayName}" -o table

# Show hierarchy tree
az account management-group show \
--name "mg-contoso" \
--expand \
--recurse \
--query "{Name:name, Children:children[].{Name:name, Children:children[].name}}"

Success criteria

  • Management group hierarchy matches the specified structure (5 groups under mg-contoso)
  • At least one subscription is placed under a management group
  • Azure Policy is assigned at the mg-production scope
  • RBAC role assignment exists at the mg-contoso scope
  • Subscription was successfully moved between management groups
  • You can query and display the full hierarchy

Hints

Hint 1: Management group permissions

You need specific permissions to create management groups. By default, any user in the tenant can create management groups. This can be restricted via the tenant-level setting "Require permissions to create new management groups" in the Azure portal under Management Groups > Settings.

Hint 2: Policy inheritance

Policies assigned at a management group scope are inherited by all child management groups and subscriptions. You cannot override or exclude a child from an inherited policy | you can only add exemptions for specific resources.

Hint 3: Maximum hierarchy depth

Management groups support up to 6 levels of depth (not counting the Tenant Root Group). Plan your hierarchy to stay within this limit.

Hint 4: Moving subscriptions

Moving a subscription between management groups changes which policies and RBAC assignments apply. The change takes effect immediately but may take up to 30 minutes to be fully reflected in policy compliance evaluations.

Break and fix

Scenario a: Policy conflict

Assign two conflicting policies at different levels: one requiring tag "Environment=Production" at mg-production and another requiring "Environment=Development" at mg-dev. Try to deploy a resource in a subscription under mg-dev. What happens when contradictory policies exist at different levels?

Scenario b: orphaned Subscription

Remove your subscription from all custom management groups. Where does it appear? (Answer: It returns to the Tenant Root Group.) How do you find subscriptions that are not in any custom management group?

Scenario c: locked out

Assign a Deny RBAC assignment at a management group scope. What happens to users who previously had access through subscription-level assignments? How do deny assignments interact with allow assignments?

Knowledge check

1. How many levels deep can management groups be nested?

Management groups support 6 levels of depth below the Tenant Root Group. The Tenant Root Group itself is level 0, so the total hierarchy can be 7 levels (root + 6).

2. What happens to policies when you move a subscription between management groups?

When a subscription is moved, it immediately loses policies from the old management group and inherits policies from the new management group hierarchy. Existing non-compliant resources are not automatically remediated but will be flagged in the next compliance evaluation.

3. Can you move the Tenant Root Group or rename it?

The Tenant Root Group cannot be moved or deleted. It can be renamed (display name only) by a user with Owner or User Access Administrator role at that scope. Its ID is always the tenant ID.

4. Who can create management groups by default?

By default, any user in the Entra ID tenant can create management groups. This can be restricted so that only users with Owner, Contributor, or Management Group Contributor role at the parent scope can create them. This setting is configured at the Tenant Root Group level.

Cleanup

# Remove subscription from custom MG (returns to tenant root group)
SUB_ID=$(az account show --query id -o tsv)
az account management-group subscription remove \
--name "mg-sandbox" \
--subscription $SUB_ID 2>/dev/null

# Remove policy assignment
az policy assignment delete \
--name "require-env-tag-prod" \
--scope "/providers/Microsoft.Management/managementGroups/mg-production" 2>/dev/null

# Remove RBAC assignment (replace user_id)
# az role assignment delete --assignee "$user_id" --scope "/providers/Microsoft.Management/managementGroups/mg-contoso"

# Delete management groups (bottom-up order required)
az account management-group delete --name "mg-sandbox" 2>/dev/null
az account management-group delete --name "mg-dev" 2>/dev/null
az account management-group delete --name "mg-nonproduction" 2>/dev/null
az account management-group delete --name "mg-prod-it" 2>/dev/null
az account management-group delete --name "mg-prod-finance" 2>/dev/null
az account management-group delete --name "mg-production" 2>/dev/null
az account management-group delete --name "mg-contoso" 2>/dev/null

echo "Cleanup complete."

Learning resources