Episode 9 — Organizing the Estate — Management Groups, Subscriptions, Resource Groups, and Tags

In Episode 8 you assigned Azure roles in the portal, interpreted inherited assignments with Check access, and separated Azure roles from Microsoft Entra roles. Every one of those assignments landed on a scope — now we zoom out and organize the scopes themselves: the containers your whole Azure estate lives in.

Learning objectives

Structure a management-group hierarchy and state its hard limits (depth, count, single parent, single hierarchy).
Explain the special status of the root management group and how a Global Administrator gains control of it.
Create an additional Azure subscription (Microsoft Customer Agreement flow) and identify the roles that permit it.
Manage resource groups by the same-lifecycle rule, including the consequences of deletion and the metadata-location concept.
Design a tagging taxonomy that respects tag limits, casing rules, and the no-inheritance behavior.

Why it matters

Governance tools — role assignments, policies, locks, budgets — are only as good as the scopes you attach them to. A well-shaped hierarchy lets you assign once at a management group and let inheritance do the rest; a flat, improvised estate forces you to repeat every control per subscription and guarantees drift. The AZ-104 exam tests the numbers (levels of depth, tag limits, the 800-instances rule) and the traps (root management group access, tag inheritance, moving subscriptions). As an administrator, this is the chapter that decides whether your future policies cascade cleanly or fight the org chart.

Management groups — governance above subscriptions

A management group is a scope above subscriptions. Governance conditions applied to a management group — Azure Policy assignments, Azure role assignments — cascade by inheritance to every nested management group, subscription, resource group, and resource beneath it, and a subscription or resource owner cannot alter an inherited policy. One role assignment at a management group grants access to all subscriptions below it. All subscriptions inside a single management group must trust the same Microsoft Entra tenant.

The hard facts to memorize:

Fact	Value
Management groups per directory	10,000
Tree depth	6 levels (root level and subscription level excluded)
Parents per management group or subscription	exactly one
Children per management group	many
Hierarchies per directory	one single hierarchy

The root management group

Each directory has a single top-level root management group, displayed as Tenant root group, whose ID equals the Microsoft Entra tenant ID. It can't be moved or deleted, and new subscriptions land there by default. When anyone in the directory first uses management groups, the root is created and all existing subscriptions become its children — guaranteeing one hierarchy that global controls can't be bypassed from.

Every Azure customer can see the root group, but no one has default access to manage it. The only default path in: a Microsoft Entra Global Administrator uses Elevate access ("Access management for Azure resources"), gaining User Access Administrator at root scope — after which they can assign any Azure role there. Because a root-scope assignment applies to every resource in the directory, keep root assignments to "must have" only.

Azure RBAC on management groups

Management groups support Azure RBAC, and permissions inherit downward (VM Contributor on a management group applies to all VMs beneath). Key roles at management-group scope:

Azure role	Create/Rename/Delete MG	Move	Assign access	Assign policy	Read
Owner	✅	✅	✅	✅	✅
Contributor	✅	✅	❌	❌	✅
Management Group Contributor*	✅	(limited)	❌	❌	✅
Reader / Management Group Reader*	❌	❌	❌	❌	✅
Resource Policy Contributor	❌	❌	❌	✅	❌
User Access Administrator	❌	❌	✅	✅	❌

* The Management Group roles act only on the management-group scope itself.

Moving subscriptions and management groups

To move a subscription (or management group) under another parent you need all three: management-group write + role-assignment write on the child (e.g. Owner on the subscription), management-group write on the target parent (Owner, Contributor, or Management Group Contributor), and management-group write on the existing parent. Exception: if the target or the existing parent is the root management group, its permission requirement doesn't apply — root is the default landing spot.

A subtle trap: if your Owner role on the subscription is inherited from its current management group, you can only move it to another management group where you are also Owner. If you are directly assigned Owner on the subscription, you can move it to any management group where you have Contributor.

Two more caveats: Azure Resource Manager caches the hierarchy for up to 30 minutes, so the portal may not reflect a move immediately. And custom roles: a role definition may list only one management group in its assignable scopes (by ID path, unvalidated), and custom roles containing DataActions can't be assigned at management-group scope.

Subscriptions — creating more of them

Why run several subscriptions? Three classic reasons: avoid subscription quota limits, create separate environments for security (prod vs dev), and isolate data for compliance. Note that you can't provision Azure resources in a Microsoft Entra B2B or Azure AD B2C tenant — subscriptions, VMs, and apps live in your workforce Microsoft Entra tenant.

Under a Microsoft Customer Agreement (MCA), creating a subscription requires Owner or Contributor on the invoice section, billing profile, or billing account — or the dedicated Azure subscription creator role on the invoice section. The portal flow (Subscriptions > Add):

Basics — subscription name; pick the billing account, billing profile, and invoice section; choose the Plan (Microsoft Azure Plan or Microsoft Azure Plan for DevTest).
Advanced — pick the Subscription directory (the Entra tenant it will trust), a Management group (current directory only), and one or more Subscription owners (users or service principals of that directory — not guest users).
Tags — name/value pairs, then Review + create.

If you create a subscription in another tenant, it generates a subscription creation request: the target owner gets an email and must accept ownership within seven days or the request expires (visible under Subscriptions > View Requests). After any creation, enable Azure Service Health alerting — it's free and recommended for all production subscriptions. If a subscription seems missing in the portal, check the Subscriptions filter (select All, clear the portal-filter checkbox).

Resource groups — the same-lifecycle containers

A resource group is a container for related resources. The guiding rule: put resources that share the same lifecycle together, so you deploy, update, and delete them as a group. The rules that matter:

Each resource lives in exactly one resource group, but can be added, removed, or moved between resource groups and subscriptions at any time — and can connect to resources in other resource groups.
The resource group's location stores only metadata about its resources (relevant for compliance); resources can be in different regions than their group. Pick a location close to where your control operations originate — if that region is temporarily unavailable, control-plane requests fail over to a secondary region.
Deleting a resource group deletes every resource in it. One portal click (Delete resource group) can erase an entire solution — this is precisely what locks (Episode 10) protect against.
Limit: up to 800 instances of a resource type per resource group (some types are exempt). Some resources exist outside any resource group (deployed at subscription, management-group, or tenant scope).
A resource group is a scope: you attach Azure RBAC assignments, Azure Policy, locks, and tags to it, and the portal builds group-wide views (Metrics, Deployments, Policy, Diagnostics blades).

Remember from Episode 1 that everything here flows through Azure Resource Manager: resource groups, subscriptions, management groups, and tags are all themselves resources, and concurrent updates to the same resource end in a 409 conflict for all but one writer.

Tags — metadata that doesn't travel

Tags are key-value pairs of metadata (e.g. Environment = Production) that you apply to resources, resource groups, and subscriptions — but NOT to management groups.

The single most-tested behavior: resources do NOT inherit tags from their resource group or subscription. If you want real inherited tags, enforce them with Azure Policy (tag policies with the Modify effect). Separately, Cost Management offers a tag inheritance feature that copies subscription/resource-group tags down in cost data only — nothing is written on the resources (details in Episode 11).

Limit / rule	Value
Tags per resource, resource group, or subscription	50 name-value pairs (workaround: JSON string in one value)
Tag name length	512 characters (128 for storage accounts)
Tag value length	256 characters
Forbidden characters in names	`<` `>` `%` `&` `\` `?` `/`
15-tags-only resource types	Azure Automation, Azure CDN, Azure Public/Private DNS (zone and A records), Log Analytics saved search
Name casing	case-insensitive for operations
Value casing	case-sensitive

More gotchas: tags are stored as plain text — never put secrets in them (they leak via cost reports, tag listings, deployment histories, exported templates, logs). Not all resource types support tags; classic resources don't; VM extension tags update only while the VM is running. To tag, you need either write access to the resource itself (Contributor or a resource-specific role) or write access to Microsoft.Resources/tags via the Tag Contributor role — which can tag anything without access to the resource itself, though in the portal it only works on subscriptions (use PowerShell/REST for the rest). For cost analysis, the special cm-resource-parent tag (value = a resource ID) groups related resources' costs in Cost Management without filters, and billing-supported tags appear in the Tags column of the usage file.

🧠 Mnemonic: picture a filing cabinet: management groups are the drawers, subscriptions the folders, resource groups the envelopes, and tags the sticky labels. Sticky labels don't stick through the envelope — tags don't inherit downward.

Exercises

Exercise 9.1 — Design the hierarchy

Contoso has two divisions, Corp and Online, each with production and dev subscriptions. Compliance requires all Corp resources to be deployed only in West Europe. Sketch the management-group hierarchy and state exactly where you assign the location policy — and why not lower.

Solution

Under the Tenant Root Group, create two management groups: Corp and Online (well within the 6-level depth limit). Place Corp-Prod and Corp-Dev subscriptions under Corp; Online-Prod and Online-Dev under Online.

Assign the allowed-locations policy on the Corp management group. By inheritance it cascades to both Corp subscriptions and everything inside them, and subscription/resource owners can't alter the inherited policy — assigning per subscription instead would mean two assignments to maintain and the risk of forgetting future Corp subscriptions (new ones moved under Corp inherit automatically). Don't assign it at the root: root-scope assignments hit every resource in the directory, including Online, and should be "must have" only.

Exercise 9.2 — The subscription-move puzzle

Amara has the Owner role on subscription Sub-A, inherited from its current management group MG-Legacy. She has Contributor on the target management group MG-Modern but no role on it beyond that, and no other assignments. Can she move Sub-A under MG-Modern? What would change if her Owner role were assigned directly on Sub-A?

Solution

No. When Owner on the subscription is inherited from the current management group, you can only move the subscription to a management group where you also have Owner — Amara only has Contributor on MG-Modern.

If Owner were directly assigned on Sub-A, the move would succeed: a direct subscription Owner can move it to any management group where they have Contributor (which she has on the target), and she satisfies write access on the existing parent unless that's also missing — note the exception: if the existing or target parent is the root management group, its permission requirement is waived. Finally, don't panic if the portal still shows the old parent right after the move: ARM caches the hierarchy for up to 30 minutes.

Exercise 9.3 — A tag taxonomy under the limits

You propose this five-tag taxonomy for all resources: Environment, CostCenter, Owner, Project, DataClass?. (a) Check each against the tag rules and fix any violation. (b) One team writes Environment=production, another writes environment=Production. Which difference matters, and why? (c) Where will these tags NOT be applicable at all?

Solution

(a) Four names are fine; DataClass? is invalid — tag names can't contain ? (nor < > % & \ /). Rename it DataClass. Five tags is far below the 50-pair limit (watch resource types capped at 15, like Azure DNS or CDN). Also verify no one plans to store secrets in values — tags are plain text.

(b) Environment vs environment: tag names are case-insensitive, so these are treated as the same tag for operations (the provider may preserve the casing you typed, which shows in cost reports). But production vs Production: tag values are case-sensitive, so cost reports and filters treat them as two different values — your environment breakdown splits in two. Standardize the value casing in your convention.

(c) On management groups — tags simply don't apply there. And remember resources won't inherit these tags from their resource group or subscription: enforce them with Azure Policy tag policies (Episode 10) if you need them present everywhere.

Key takeaways

Management groups sit above subscriptions; conditions cascade by inheritance and can't be altered below. Limits: 10,000 per directory, 6 levels deep (root and subscription levels excluded), one parent each, one hierarchy per directory.
The Tenant Root Group (ID = tenant ID) can't be moved or deleted; new subscriptions land there by default; no one manages it by default — a Global Administrator must elevate access to gain User Access Administrator at root.
Moving a subscription needs write + role-assignment write on the child, write on target and existing parents (root parent exempt); inherited-vs-direct Owner changes what moves are allowed; the hierarchy is cached up to 30 minutes.
Extra subscriptions isolate quotas, environments, and compliance; MCA creation needs Owner/Contributor on invoice section, billing profile, or billing account (or Azure subscription creator); cross-tenant creation requires acceptance within 7 days.
Resource groups hold same-lifecycle resources; the group's location is metadata only; resources may live in other regions; deleting the group deletes everything in it; max 800 instances per resource type per group.
Tags (max 50 per entity, name 512/value 256 chars) go on resources, resource groups, and subscriptions — never on management groups — and do not inherit downward; names are case-insensitive, values case-sensitive, storage is plain text.
Tag Contributor can tag without resource access; Contributor tags via resource access; cm-resource-parent groups costs in Cost Management.

Quick recall

Q: How deep can a management-group tree go, and what's excluded from the count? A: Six levels, excluding the root level and the subscription level.

Q: A new subscription is created and nobody picks a management group. Where does it appear? A: Under the root management group (Tenant root group) — the default landing spot.

Q: Scenario — a Global Administrator needs to assign a policy at the Tenant Root Group but sees "no access." What's the path? A: Use Elevate access ("Access management for Azure resources"): they become User Access Administrator at root scope and can then assign any Azure role, including to themselves, at the root.

Q: You tag a resource group CostCenter=CC-42. What do the resources inside carry? A: Nothing — resources don't inherit resource-group or subscription tags. Use Azure Policy to enforce tags; Cost Management's tag inheritance affects cost data only.

Q: What happens to the resources when you delete their resource group? A: All of them are deleted with the group.

Q: Which casing difference breaks your cost reports: Env vs env, or Prod vs prod as the value? A: The value: tag values are case-sensitive (Prod ≠ prod), whereas tag names are case-insensitive for operations.

Coming up

Your estate now has shape — next we bolt on the guardrails. Episode 10 covers Azure Policy (definitions, initiatives, effects, remediation, and compliance reporting) and resource locks — including the classic gotchas where a ReadOnly lock breaks things you didn't expect.