🛸 Hitchhiker's Guide — Phase 05: Landing Zones & Management-Group Scale

Read this if: you can assign one policy to one subscription, but "govern 300 subscriptions for a regulated bank" sounds like a different job. It is. This is the compressed tour the WARMUP derives slowly. Skim it, then read the WARMUP.


0. The 30-second mental model

A management group is a container above subscriptions; MGs form a tree with one Tenant Root Group on top, and policy + RBAC assigned at any node inherit downward to every subscription and resource beneath it. So "what governs this resource?" is never answerable from the resource — you walk up the tree and union everything you find. A landing zone is the right tree (CAF's reference: Platform / Landing Zones / Sandbox / Decommissioned) plus the automation (subscription vending) that drops a new subscription under the right node so it inherits the baseline by construction. One sentence to tattoo: governance is a property of where you are in the tree, not a checklist you run — assign once high up, inherit everywhere below.

1. The MG hierarchy to memorize (draw it cold in the interview)

Tenant Root Group
├── Platform              (shared services; locked down; central team)
│   ├── Identity          (domain controllers, Entra Connect)
│   ├── Management        (Log Analytics, Automation, backup)
│   └── Connectivity      (hub VNet, Azure Firewall, ExpressRoute/VPN, DNS)
├── Landing Zones         (the actual workloads)
│   ├── Corp              (private; DENY public IP; reach via hub)
│   └── Online            (internet-facing; WAF required)
├── Sandbox               (experimentation; loose guardrails; isolated)
└── Decommissioned        (deny-most; for subscriptions being retired)

Platform vs Landing Zones = different audience + change rate. Corp vs Online = opposite networking policy, one assignment each. Decommissioned = a safety airlock for retirement.

2. The one formula (the whole phase)

effective(scope) = (assignments at this scope)
                 ∪ (everything inherited from ancestors)
                 − notScopes        (scope carved out of one assignment)
                 − exemptions       (an assignment suppressed at a scope, usually time-boxed)

It's a union (additive) — a child can add governance, never silently delete an inherited one. The only removals are explicit + auditable: notScopes and exemptions. Inheritance is down, never sideways (a sibling MG is not an ancestor).

3. The numbers to tattoo on your arm

ThingNumber
Max MG depth under root6 levels (depth 7 is rejected)
Total scope levels (root + MGs + sub)up to 8
MGs a subscription belongs toexactly 1
MGs per tenant10,000 (you'll never hit it)
Compliance score100 × compliant / total (empty estate = 100%)
Non-compliant ifany policy returns deny or audit failure
Rollout orderaudit first, then deny

4. The az account management-group one-liners

# Build the tree
az account management-group create --name platform --display-name "Platform" --parent root
az account management-group create --name connectivity --parent platform

# Subscription vending = placement under the right MG
az account management-group subscription add --name corp --subscription <sub-id>

# Walk / inspect
az account management-group show --name corp --expand --recurse   # children + subs
az account management-group subscription show-sub-under-mg --name corp

# Move a subscription (e.g. into Decommissioned to retire it safely)
az account management-group subscription add --name decommissioned --subscription <sub-id>

# Policy at an MG, with a carve-out
az policy assignment create --name require-tags --scope <root-mg-id> \
    --policy-set-definition <initiative-id> --not-scopes <sandbox-mg-id>

# Exemption (time-boxed)
az policy exemption create --name migrating-waiver --policy-assignment <assignment-id> \
    --exemption-category Waiver --expires-on 2025-09-01 --scope <sub-scope>

# The compliance score
az policy state summarize --management-group <mg-id>

Terraform / Bicep equivalent: the Azure/caf-enterprise-scale (Terraform) or Azure/ALZ-Bicep modules deploy this whole tree + baseline; lz-vending / bicep-lz-vending do the vending.

5. War story shapes you'll relive

  • "My deployment is denied and there's no deny on my subscription!" → it's inherited from an ancestor MG, two hops up. Walk the chain; the resource never tells you. Fix is a notScopes carve-out or a time-boxed exemption — never delete the policy (that breaks everyone).
  • "Compliance dropped to 60% overnight." → someone flipped an audit initiative to deny or added a policy; the estate was always non-compliant, the score just started counting. Read by_policy → find the policy → find the scope.
  • "We moved a subscription and nothing changed for 10 minutes." → MG moves are eventually consistent (cache up to a few minutes). Not a bug. Wait / check Activity Log.
  • "New team can't create anything." → vended under the wrong MG (Decommissioned, or an over-locked Platform child). Placement is the bug surface of vending.
  • "I assigned a policy to the sub but the RG ignores it." → it doesn't; RGs inherit. Check for a notScopes or exemption suppressing it at the RG.

6. Vocabulary that signals you've run an estate

  • Tenant Root Group — the one node with no parent; its id is the tenant id.
  • Landing zone — a governed environment a workload drops into and inherits everything.
  • Subscription vending — automated placement + baseline for a new subscription.
  • Initiative / policy set — a bundle of policies assigned as one unit.
  • notScopes vs exemption — scope-out-of-an-assignment vs assignment-suppressed-at-a-scope.
  • Audit-first-then-deny — the safe rollout for a new mandatory control.
  • Self-service with guardrails — the only governance model that scales to thousands of engineers; the whole thesis of ALZ.
  • Effective assignments — local ∪ inherited − exclusions; what actually applies here.

7. Beginner mistakes that mark you in interviews

  1. Trying to answer "what governs this resource?" from the resource — instead of walking up.
  2. Thinking a child can override/delete an inherited policy. It can't; only notScopes / exemptions remove, and they're explicit.
  3. Confusing a sibling MG with an ancestor — inheritance is down, never sideways.
  4. Conflating notScopes and exemptions (scope-vs-assignment, structural-vs-time-boxed).
  5. Shipping a deny straight to prod instead of audit-first.
  6. Treating vending as a ticket-and-checklist instead of automated placement → the snowflake subscription problem the whole phase prevents.
  7. Quoting the depth limit wrong (it's 6 under root, and 7 is rejected).

8. How this phase pays off later

  • P06 (Networking) — Connectivity MG is the hub; Corp/Online inherit hub routing + DNS.
  • P04 (RBAC/Policy) — this phase composes P04's single-assignment evaluator across the tree; they're a pair.
  • P08 (CI/CD) — subscription vending and policy-as-code are pipelines; this is where they run.
  • P13 (Observability) — the Management MG's central Log Analytics is what compliance and audit read from.
  • P15 (Capstone) — the landing zone is the substrate the whole secure platform sits in.

Now read the WARMUP slowly, then build the resolver. You'll use its tree-walk + one-formula mental model every time someone asks "wait, why is this allowed/denied here?"