The Cloud Adoption Framework and Landing Zones

Why this matters

You can now build a management-group hierarchy (module 01) — but which one? Rather than invent a tree from scratch, Microsoft publishes an opinionated, battle-tested answer: the Cloud Adoption Framework (CAF) and its landing zone architecture. A landing zone is the single most over-used and under-defined term in Azure governance, so this module's job is to make it concrete: what a landing zone actually is, the reference hierarchy CAF recommends, and the crucial split between platform and application landing zones. This is survey-level on purpose — you won't deploy the full enterprise accelerator in a lab — but the vocabulary and shape here is what every later module (and real platform team) assumes.

Concepts

The Cloud Adoption Framework in one paragraph

The Cloud Adoption Framework is Microsoft's prescriptive guidance for adopting Azure at organizational scale — a set of methodologies (Strategy, Plan, Ready, Adopt, Govern, Manage, Secure) plus reference architectures and tooling. For this track, the part that matters is Ready / Govern: how to lay out the environment so teams can build safely. You do not need to memorize CAF's phases. You need its central deliverable: a governed landing-zone architecture built on exactly the management groups, policy, and RBAC primitives you already know. CAF is not a product you install; it's a blueprint (small-b) for arranging the primitives from modules 00-01.

What a "landing zone" actually is

A landing zone is a pre-provisioned, pre-governed environment that a workload "lands" in — a subscription (or set of subscriptions) that already has the networking, identity, policy, RBAC, and monitoring wired up before any app team touches it. Contrast with what you've done all curriculum: an empty subscription you configured by hand, per resource. A landing zone flips that — the environment arrives governed, so a team requesting one gets guardrails, a network, and a tagging/policy baseline by default. Concretely, a landing zone is usually one subscription placed under the right management group, with a baseline of policy assignments (inherited from that MG) and a standard network/identity footprint. "Landing zone" ≈ "a governed subscription handed to a team, ready to build in." It's the physical realization of module 00's "governance is a platform-team product."

Platform landing zones vs. application landing zones

The most important distinction in the whole CAF model:

• Platform landing zones host the shared services the whole organization depends on — connectivity (the hub VNet, VPN/ExpressRoute, Azure Firewall from track 5), identity (domain controllers, Entra Connect), and management (Log Analytics, backup, central monitoring from track 6/12). These are run by the platform team, typically in a small number of dedicated subscriptions, and everything else depends on them.
• Application landing zones are the subscriptions handed to application teams to deploy their workloads into. They consume the platform (peer to the hub network, send logs to the central workspace, inherit the baseline policy) but the app team owns what runs inside. Each app or team typically gets its own application landing zone (subscription), which is exactly the "subscription per team × environment" instinct from module 00.

The split is a separation of concerns: platform teams own the shared foundation; app teams own their workloads on top of it. Getting this boundary clean is what lets a platform team scale to hundreds of app teams.

The CAF reference management-group hierarchy

CAF recommends a specific management-group shape under the tenant root — this is the concrete tree module 01 was building toward:

Tenant Root Group
└─ Contoso (org root MG; broad "everyone" guardrails live here)
   ├─ Platform            (shared-services subscriptions)
   │  ├─ Connectivity     (hub network, firewall, DNS)
   │  ├─ Identity         (domain services, identity infra)
   │  └─ Management       (Log Analytics, automation, backup)
   ├─ Landing Zones       (application landing zones — the app teams' subs)
   │  ├─ Corp             (internal apps, no public inbound)
   │  └─ Online           (internet-facing apps)
   ├─ Sandbox             (loose, experiment-only subs; cheap guardrails)
   └─ Decommissioned      (subs being retired; deny-most policy)

Notice how the axes from module 01 combine: the top split is by function (platform vs. workloads vs. sandbox vs. decommissioned), and Landing Zones sub-splits Corp/Online by network exposure. Broad guardrails (allowed regions, no public storage) attach at Contoso so everything inherits them; Online gets stricter public-exposure policy than Corp; Sandbox gets a deliberately loose set so experimentation isn't strangled; Decommissioned gets a near-total Deny so retiring subs can't grow new resources. This is "broad high, specific low" (module 01) made into a template.

Landing zone "accelerators" and how much to adopt

Microsoft ships landing zone accelerators — ready-made Terraform/Bicep deployments (the "Azure Landing Zones" or ALZ modules) that stand up the entire hierarchy, baseline policies, and platform networking in one go. They're powerful and heavy: designed for enterprises with connectivity, identity, and management teams already in place. For a small org — or your lab — adopting the full accelerator is overkill. The pragmatic path most teams take is "start with the concepts, adopt incrementally": build the management-group skeleton (module 01), attach a handful of baseline policies (module 03), and add platform subscriptions only when you actually have shared services to run. This module is the conceptual foundation; you deliberately won't run the full accelerator here. Knowing it exists — and that it's built from exactly the MG + policy + Terraform primitives you're learning — is the goal.

Command reference

CAF is architecture, not a CLI surface, so most "commands" here are the module-01 primitives arranged into the reference shape, plus ways to inspect it. There's no az caf command.

Flag breakdown — az account management-group hierarchy-settings create --name <tenant-root-id> --default-management-group /providers/Microsoft.Management/managementGroups/mg-sandbox --require-authorization-for-group-creation true:

• --name <tenant-root-id> — the tenant root group these settings apply to (hierarchy settings live on the root).
• --default-management-group .../mg-sandbox — where brand-new subscriptions automatically land instead of directly under the root. Setting this to a governed (or sandbox) MG means a newly created subscription is already under guardrails rather than ungoverned at the root — a key CAF safety default.
• --require-authorization-for-group-creation true — locks down who can create management groups (requires explicit Microsoft.Management/.../write), preventing sprawl of ad-hoc MGs. The governance-of-the-governance setting.

Hands-on exercises

Everything here is free (MGs, policy assignments, inspection). You'll shape the hierarchy you started in module 01 into the CAF reference form. You have one subscription, so most landing zones are modelled, not populated — noted where it matters.

1. (Azure) Reshape your module-01 tree toward the CAF reference. Building on mg-org/mg-prod/mg-nonprod from module 01 (rename in your head to mg-contoso), add the CAF top-level nodes:

   az account management-group create --name mg-platform --display-name "Platform" --parent mg-org
   az account management-group create --name mg-landingzones --display-name "Landing Zones" --parent mg-org
   az account management-group create --name mg-sandbox --display-name "Sandbox" --parent mg-org
   az account management-group create --name mg-decommissioned --display-name "Decommissioned" --parent mg-org
   

   Expect a tree matching the CAF reference top level. You now have the standard skeleton — empty, but correctly shaped.

2. (Azure) Add the platform and landing-zone sub-tiers. Fill in the second level:

   az account management-group create --name mg-connectivity --display-name "Connectivity" --parent mg-platform
   az account management-group create --name mg-identity --display-name "Identity" --parent mg-platform
   az account management-group create --name mg-management --display-name "Management" --parent mg-platform
   az account management-group create --name mg-corp --display-name "Corp" --parent mg-landingzones
   az account management-group create --name mg-online --display-name "Online" --parent mg-landingzones
   

   Expect the full reference hierarchy. Render it:

   az account management-group show -n mg-org --expand --recurse \
     --query "{name:displayName, children:children[].{name:displayName, children:children[].displayName}}" -o json
   

3. (Azure) Place your one subscription as an application landing zone. Your dev subscription is best modelled as a Corp application landing zone (or move it to mg-sandbox if you prefer). Move it:

   SUB=$(az account show --query id -o tsv)
   az account management-group subscription add --name mg-corp --subscription "$SUB"
   

   Expect your subscription under mg-corp. Write down what a real org would have that you don't: separate subscriptions under mg-connectivity (the hub network), mg-management (Log Analytics), and one per app team under mg-corp/mg-online. You're modelling the shape with one real leaf.

4. (Azure) Attach a broad baseline at the org root, a stricter one at Online. Demonstrate "broad high, specific low." Assign allowed-locations at mg-org (broad) and a public-network-restriction flavour at mg-online (specific) — both in Audit:

   LOC=$(az policy definition list --query "[?displayName=='Allowed locations'].name" -o tsv)
   az policy assignment create --name baseline-locations --policy "$LOC" \
     --scope /providers/Microsoft.Management/managementGroups/mg-org \
     --params '{"listOfAllowedLocations":{"value":["eastus","westus"]}}'
   # A public-exposure-related built-in for the internet-facing tier (pick any storage-public built-in):
   PUB=$(az policy definition list --query "[?displayName=='Storage account public access should be disallowed'].name" -o tsv)
   az policy assignment create --name online-no-public-storage --policy "$PUB" \
     --scope /providers/Microsoft.Management/managementGroups/mg-online \
     --params '{"effect":{"value":"Audit"}}' 2>/dev/null || echo "adapt display name to an available built-in"
   

   Confirm mg-online sees both (its own + the inherited baseline), while mg-corp sees only the baseline:

   az policy assignment list --scope /providers/Microsoft.Management/managementGroups/mg-online -o table
   az policy assignment list --scope /providers/Microsoft.Management/managementGroups/mg-corp -o table
   

5. (Azure) Distinguish a platform landing zone from an application one — on paper, backed by the tree. In a scratch file, list which of your MGs are platform landing zones (mg-connectivity, mg-identity, mg-management) and which are application landing zones (mg-corp, mg-online), and for each platform one name the shared service from an earlier track it would host (hub VNet/firewall from track 5 → Connectivity; Log Analytics from track 6/12 → Management). This cements the consume-vs-own boundary.

6. (Azure) Inspect the tenant hierarchy setting (read-only). See whether a default landing MG is configured for new subscriptions:

   az account management-group hierarchy-settings list --name $(az account management-group list --query "[?contains(displayName,'Tenant Root')].name | [0]" -o tsv) 2>/dev/null || echo "no custom hierarchy settings (new subs land at root by default)"
   

   Understand the implication: with no default set, a brand-new subscription lands ungoverned at the tenant root. A CAF-aligned org sets the default to a governed MG so nothing is ever born ungoverned. (Don't change the tenant setting in a shared tenant without permission — this is read/awareness only.)

7. Diagnose and fix: "the landing zone isn't inheriting the baseline." A very common CAF mistake — a subscription placed in the wrong MG silently misses the baseline. Simulate it: temporarily move your subscription to mg-sandbox (which has no baseline attached), then observe it loses the Online exposure policy and keeps only whatever mg-org provides:

   az account management-group subscription add --name mg-sandbox --subscription "$SUB"
   az policy assignment list --scope /subscriptions/$SUB --disable-scope-strict-match \
     --query "[].{name:name, scope:scope}" -o table
   

   Diagnose: the subscription now inherits only mg-org → mg-sandbox assignments; anything attached under mg-landingzones/mg-online no longer applies because sandbox is a different branch. Fix: move it back to the intended landing-zone MG:

   az account management-group subscription add --name mg-corp --subscription "$SUB"
   az policy assignment list --scope /subscriptions/$SUB --disable-scope-strict-match \
     --query "[].{name:name, scope:scope}" -o table
   

   Lesson: a landing zone's governance comes entirely from where in the tree its subscription sits. "The baseline isn't applying" is almost always "the subscription is in the wrong MG," not a broken policy.

8. (Azure) Clean up the extra policy assignments; keep the hierarchy. Later modules reuse the MG tree (free), so leave it, but remove the demo assignments if you like:

   az policy assignment delete --name online-no-public-storage --scope /providers/Microsoft.Management/managementGroups/mg-online 2>/dev/null; true
   # Leave baseline-locations on mg-org — module 03 builds on it.
   

Independent challenge

No commands given — a design task drawing on this module, module 01 (hierarchy axes), module 00 (the four forces), and track 5 (hub/spoke networking, firewall) and track 6/12 (central monitoring). For the Payments/Web/Data org you've been carrying since module 00, produce a one-page landing-zone design document: draw the full CAF-aligned management-group hierarchy, then for every subscription (real or imagined) label it as a platform or application landing zone and name what it hosts. For each of the three platform landing zones (Connectivity, Identity, Management), name the specific earlier-track resource it would contain and which application landing zones depend on it and how (e.g. "Web-prod's spoke VNet peers to the Connectivity hub"). Finally, decide where Payments-prod's compliance-strict subscription attaches in this CAF shape and argue whether Corp or Online (or a dedicated child) is correct for it. Do not stand up an accelerator; the deliverable is the reasoned design and, optionally, the top two MG levels built in your tenant.

Common mistakes & troubleshooting

• Thinking a landing zone is a product you deploy. It's a pattern — a governed subscription under the right MG with baseline policy/network/identity — realized from the primitives in modules 00-01. The accelerator automates it; the concept is what matters.
• Blurring platform and application landing zones. Platform LZs host shared services owned by the platform team (network, identity, management); app LZs host workloads owned by app teams. Mixing shared services into app subscriptions destroys the separation of concerns that lets the model scale.
• Adopting the full accelerator into a small org. The enterprise ALZ accelerator assumes connectivity/identity/management teams already exist. For a small org or a lab it's overkill — build the skeleton and add platform subs when you actually have shared services.
• Letting new subscriptions be born at the tenant root. With no default management group set, a fresh subscription is ungoverned. CAF sets a default landing MG so nothing is ever created outside the guardrails.
• Putting a subscription in the wrong branch and blaming policy. A landing zone's entire governance comes from where its subscription sits in the tree (exercise 7). Wrong MG = wrong (or missing) inherited baseline.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

Cumulative review

Closed-book. Don't reopen modules 00-02 or earlier tracks while attempting these — the point is to find out what actually stuck. These mix this track's first three modules with the baselines from tracks 9, 11, and 16.

1. Trace the full scope ladder from an individual storage account up to the tenant root, naming all five levels, and state at which levels you can attach a policy assignment.
2. A company has three teams, each with dev and prod, and one PCI-bound prod workload. Using module 00's four forces, justify a subscription count, then (module 01) sketch a management-group tree for them, then (module 02) label which nodes are platform vs. application landing zones.
3. You assigned an Audit "allowed locations" policy at a management group. Explain, using track 11 module 05's effect model, what would change if you promoted it to Deny, and why the existing non-compliant resources in a child subscription would not be deleted.
4. Explain "inheritance flows down, only down" and give a concrete example of a policy assigned on one subscription that a sibling subscription does not receive, plus the correct fix if both needed it.
5. Distinguish RBAC inheritance (additive) from Deny-policy inheritance (non-overridable) down a management-group hierarchy, referencing how role assignments worked in track 16.
6. What does it mean that "a landing zone's governance comes entirely from where its subscription sits"? Describe the exercise-7 failure and fix from module 02 in your own words.
7. Give the Terraform (track 9) resource types you'd use to declare a two-level management-group hierarchy with one subscription placed under a child MG, and explain why the parent/child wiring should be a reference not a string.
8. Why is a subscription — not a resource group — the right boundary for isolating the PCI workload, in terms of billing, quota, and RBAC/policy?
9. Contrast an "environment-first" and a "business-unit-first" hierarchy for the three-team org, and say which makes "prod is stricter than dev" a clean MG boundary and why.
10. Name two guardrails you'd attach at the org-root MG (so everything inherits) and one you'd attach only at an Online/internet-facing MG, and justify the placement with "broad high, specific low."

Next

Continue to 03-azure-policy-at-scale-initiatives-and-exemptions — you have a governed hierarchy; now bundle the individual policies from track 11 into an initiative, assign it at the management-group level, and learn the one escape hatch (exemptions) for legitimate exceptions.