Phase 05 — Azure Landing Zones & Management-Group Scale

Difficulty: ⭐⭐⭐☆☆ (the mechanism) → ⭐⭐⭐⭐⭐ (the org-scale judgment) Estimated Time: 1 week (12–18 hours) Prerequisites: Phase 03 (Entra ID — the identity the tree authorizes) and Phase 04 (RBAC + Azure Policy — the single-assignment evaluator this phase composes across a tree). Read those first; this phase assumes them.

Why This Phase Exists

Phase 04 taught you to evaluate one assignment: given a role assignment or a policy at a scope, does this request pass? That is the senior skill. The principal skill is the layer above it: when you have hundreds of subscriptions and thousands of engineers, where do assignments live, how do they reach a given resource, and how do you stamp a new subscription with the right governance the moment it is born? That is what a landing zone is, and it is the difference between an Azure estate that scales and one that becomes an ungoverned sprawl of snowflake subscriptions nobody can audit.

The mechanism is deceptively simple and the consequences are enormous: a management group is a container above subscriptions, management groups form a tree with one Tenant Root Group at the top, and policy and RBAC assigned at any node inherit downward to every subscription and resource beneath it. So the question "who can touch this resource / which policies apply to it?" is never answerable from the resource alone — you walk up the tree. Get the tree right and governance is automatic; get it wrong and you are hand-assigning policy to 300 subscriptions and missing 40 of them.

Microsoft codified the right tree as the Cloud Adoption Framework (CAF) and its reference architecture, the Azure Landing Zone (ALZ). This phase makes you build the resolver that walks that tree: effective-assignment inheritance, subscription vending (placing a new subscription under the correct node so it inherits the baseline), and an estate-wide compliance score. The JD calls it out directly: "Configure and manage Azure Landing Zones … Azure Policies, RBAC … at scale."

Concepts

• Cloud Adoption Framework (CAF) — Microsoft's end-to-end guidance for governed cloud adoption (strategy → plan → ready → adopt → govern → manage). The "Ready" methodology is where landing zones live; the "Govern" methodology is where policy-as-code and compliance scoring live.

• Azure Landing Zone (ALZ) — CAF's reference architecture: a management-group hierarchy, a policy-as-code baseline, RBAC, hub-and-spoke networking, centralized logging, and a subscription-vending process. The canonical hierarchy:

  Tenant Root Group
  ├── Platform
  │   ├── Identity        (domain controllers, Entra Connect)
  │   ├── Management      (Log Analytics, automation, backup)
  │   └── Connectivity    (hub VNet, firewall, ExpressRoute/VPN, DNS)
  ├── Landing Zones
  │   ├── Corp            (private workloads, no direct internet)
  │   └── Online          (internet-facing workloads)
  ├── Sandbox             (loose guardrails for experimentation)
  └── Decommissioned      (deny-most, for subscriptions being retired)
  

• Management groups — a tree above subscriptions, max depth 6 levels of MGs under the Tenant Root Group. A subscription belongs to exactly one management group. Policy and RBAC assigned at an MG inherit to every descendant MG, subscription, and resource.

• Effective governance at a scope = (local assignments) ∪ (everything inherited from ancestors) − notScopes − exemptions. This is the single formula this phase exists to make muscle memory; it composes Phase 04's evaluator across the tree.

• Subscription vending — the automated, policy-compliant allocation of a new subscription into the right MG with budgets, RBAC, and networking pre-wired, so a new team gets a governed subscription in minutes, not a ticket queue in weeks.

• Policy-as-code — policy/initiative definitions and assignments live in Git, are reviewed in PRs, versioned, and deployed via pipelines — so governance is auditable and a rollback is a git revert, not an archaeology project. Initiatives (policy sets) bundle related policies; guardrails are expressed as deny (block) vs audit (flag, do not block).

• Compliance scoring — the estate-wide percentage of resources that pass the assigned initiatives, with a per-policy breakdown so you know which guardrail is failing where.

Labs

Lab 01 — Landing-Zone Resolver (flagship, implemented)

→ Lab folder: lab-01-landing-zone-resolver/

Integrated-Scenario Suggestions

These carry the phase into the rest of the track — each is a real platform-team problem the landing-zone layer underpins:

1. Greenfield estate bring-up — design the MG hierarchy for a regulated org (PCI/HIPAA tiers as MGs vs initiatives?), assign the baseline at the right scopes, and prove a new subscription lands compliant without manual steps. (Uses every function in the lab.)
2. Subscription vending at scale — a self-service "request a subscription" flow: a team files a request, a pipeline picks the MG (Corp vs Online vs Sandbox), creates the subscription, places it, applies the budget + RBAC + networking, and reports back — in minutes. (Builds on P01 ARM/Bicep, P02 Terraform, P08 CI/CD.)
3. Policy-as-code migration — take a portal-clicked pile of ad-hoc assignments, export them, refactor into versioned initiatives in Git, gate changes with PR review and a what-if-style compliance diff, and roll out via pipeline. (Builds on P04 Policy, P08.)
4. The "we're failing audit" fire drill — given a compliance score of 71%, find the policy and the scope dragging it down, decide deny vs audit vs exemption for each gap, and write the remediation plan (DINE policies, time-boxed exemptions). (Builds on P04 effects, P13 monitoring.)
5. Decommissioning safely — move a retiring subscription to the Decommissioned MG so it inherits a deny-most baseline, verify nothing critical still depends on it, and prove the blast radius is contained. (Builds on P14 reliability/operations.)

Guides in This Phase

• HITCHHIKERS-GUIDE.md — the 30-minute orientation; read first
• WARMUP.md — the full primer; read slowly
• BROTHER-TALK.md — the candid version

Where This Phase Sits in the Track

This phase is the scale layer that turns Phase 04's single-assignment evaluator into estate-wide governance, and it is the substrate every later phase deploys into:

The mental model to carry forward: assign once, high up; inherit everywhere below; carve out explicitly and auditably. Every later phase that creates a resource is creating it somewhere in this tree, and therefore inheriting something — and a principal always knows what.

Key Takeaways

• A management group is a container above subscriptions; MGs form a tree (one Tenant Root Group, depth ≤ 6) and a subscription lives in exactly one MG.
• Governance inherits downward: a policy/RBAC assignment at an MG applies to every descendant. You can never answer "what applies here?" from a resource alone — walk up.
• The one formula: effective(scope) = local ∪ inherited − notScopes − exemptions, and the result is deterministic (most-local first).
• Subscription vending is placement: hang a new subscription under the right MG and the baseline (policy, RBAC, budget, networking) is inherited automatically. That is the whole promise of a landing zone — governance by construction, not by ticket.
• Policy-as-code + compliance scoring make governance reviewable and measurable: an initiative in Git, a PR review, a pipeline deploy, and a number you can put on a slide.

Deliverables Checklist

• Lab 01 implemented; all tests pass against solution.py and your lab.py
• You can draw the canonical ALZ management-group hierarchy from memory and say what each node is for
• You can compute the effective assignments for a Corp subscription by hand (walk the chain, union, subtract notScopes/exemptions)
• You can explain why depth is capped at 6 and what breaks at depth 7
• You can describe subscription vending end-to-end and why it beats a ticket queue
• You can read a compliance score and name the policy + scope to fix first