Cloud Adoption Framework & Azure Landing Zones, In Depth

In a nutshell

Imagine an airport that is fully built and staffed before a single plane arrives: the runways are poured, the control tower is manned, customs, fuel, and baggage handling are all ready. Airlines don’t each pour their own tarmac — they taxi in and start flying on day one. That pre-built, pre-governed environment is exactly what a landing zone is for cloud workloads. Before any team deploys an app, the network, identity, security rules, and monitoring are already there and already enforced. The name is literal: when a workload “lands”, the runway is waiting.

The Cloud Adoption Framework (CAF) is Microsoft’s playbook for the whole journey of moving an organisation to Azure — why you’re doing it, what to move and in what order, what foundation to build, and how to govern, secure, and operate it forever. The Azure Landing Zone (ALZ) is the foundation that playbook tells you to build: the airport, not the planes. CAF is the guidance; the landing zone is the thing you end up with.

Why a beginner should care: almost every “real” Azure job — architect, platform engineer, administrator — happens inside a landing zone that someone designed. Understanding it is the difference between clicking resources into a random subscription and reasoning about an estate the way an architecture review board does. It is also the single most exam-heavy topic on AZ-305.

Level: Advanced lesson with a beginner on-ramp · Time: ~43 min read

Before you start, it helps to know what a subscription, resource group, and virtual network are, and that Azure Policy exists — the Prerequisites & where this fits section just below has the full list and links. By the end you’ll be able to explain CAF versus the Well-Architected Framework, name the seven methodologies, tell a platform landing zone from an application one, and reason through the eight design areas — the precise outcomes are spelled out in Learning objectives immediately after this.

Most engineers meet Azure one resource at a time. You create a virtual network, attach a subnet, drop a VM in it, wire up a public IP, and it works. Do that two hundred times across forty teams and you do not have a cloud estate — you have a landfill. No two subscriptions are named the same way, identity is a patchwork of half-configured RBAC, half your storage accounts are reachable from the public internet, and nobody can answer the simplest governance question: which workloads are non-compliant, and who owns them?

The Cloud Adoption Framework (CAF) exists to stop that outcome before it starts. It is Microsoft’s end-to-end guidance for the organisational journey to cloud — the strategy, the planning, the operating model, and the governed environment that workloads land in. Its physical centrepiece is the Azure Landing Zone (ALZ): a pre-built, opinionated, policy-governed foundation so that application teams move fast without re-litigating identity, networking, and security on every project.

This lesson is the design-judgement layer the tutorials skip. We will draw the bright line between CAF and the Well-Architected Framework, walk all seven CAF methodologies (and explain why older courses say six), then go deep on the landing-zone architecture itself: platform vs application landing zones, the eight design areas that every enterprise-scale foundation is built from, and the ALZ accelerator — including the modern Azure Verified Modules (AVM) path in Bicep and Terraform versus the portal accelerator. By the end you should be able to reason about a landing-zone design the way an architecture review board does: not “what button do I click”, but “what decision am I making, and what does it cost me later”.

Learning objectives

By the end of this lesson you will be able to:

1. Distinguish CAF from WAF by scope and audience — the organisational adoption journey versus the per-workload quality bar — and explain why a mature estate needs both.
2. Name and sequence the seven CAF methodologies, separating the four foundational sequential phases (Strategy → Plan → Ready → Adopt) from the three operational, continuous ones (Govern, Secure, Manage), and explain the historical shift from six to seven.
3. Differentiate a platform landing zone from an application landing zone, and articulate the separation-of-duties model that makes the distinction load-bearing.
4. Enumerate and reason about the eight ALZ design areas, including the key decision in each (e.g. hub-spoke vs Virtual WAN, management-group hierarchy depth, policy-driven vs detective governance).
5. Choose an ALZ deployment path — the Azure Verified Modules accelerator (Bicep or Terraform) versus the portal accelerator — based on the customer’s IaC maturity and operating model.
6. Apply CAF/ALZ reasoning to AZ-305-style scenario questions, which are dominated by management-group design, subscription strategy, Azure Policy placement, and connectivity topology.

Prerequisites & where this fits

This is an Architecture & Design Mastery lesson. You should already be comfortable with the building blocks it composes:

• Azure resource hierarchy — management groups, subscriptions, resource groups, resources — and Microsoft Entra ID (formerly Azure AD) for identity and RBAC.
• Core networking — virtual networks, subnets, NSGs, peering, and the idea of a hub-and-spoke topology. (See Azure virtual network basics and cloud network segmentation if those are fuzzy.)
• Azure Policy at a conceptual level — definitions, initiatives, assignments, effects.
• Infrastructure as Code — that Bicep and Terraform exist and produce idempotent deployments.

Where it sits in the course: the previous lesson, The Azure Well-Architected Framework, In Depth, taught the workload quality bar as a tradeoff system. This lesson zooms out to the organisational frame — CAF — and the foundation it produces. The companion implementation series (azure-landing-zone-billing-tenant, azure-landing-zone-identity, azure-landing-zone-network, and the rest of the eight) drills each design area to the Bicep/Terraform level; this lesson is the map that ties them together. The next lesson, Choosing an Architecture: Styles & the Ten Design Principles, moves from the foundation to what you build on it.

CAF vs WAF: organisation versus workload

The single most common conceptual error in Azure architecture is treating CAF and WAF as interchangeable, or as competing checklists. They are neither. They operate at different altitudes and answer different questions, and a mature estate runs both at once.

The Well-Architected Framework (WAF) is a workload lens. It asks: is this particular system well-built? It judges a single workload against five pillars — Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency — and forces you to reason about the tensions between them. WAF is what an architecture review applies to one application. Its time horizon is the lifetime of that workload, and its primary tool is judgement about tradeoffs.

The Cloud Adoption Framework (CAF) is an organisational lens. It asks: is the enterprise adopting and operating cloud well, at scale? Its scope is the whole estate and the whole journey — motivations and business case, a migration and innovation plan, the governed foundation, the operating model, and the continuous disciplines of governance, security, and management that run forever. CAF is what a cloud centre of excellence (CCoE) and a platform team apply across all workloads. Its time horizon is the life of the organisation in the cloud.

A clean mental model: CAF builds and runs the neighbourhood; WAF inspects each house. CAF gives you zoning, roads, water, and power — the landing zone. WAF makes sure the house you build on a given plot is sound. You can build a beautifully Well-Architected workload and still have a chaotic estate (no governance, no consistent identity, no cost accountability). You can have a pristine CAF-aligned foundation and still deploy a fragile, over-provisioned workload onto it. You need both, and they reference each other deliberately — CAF’s Ready and Govern methodologies bake WAF principles into the platform so that every workload starts from a better baseline.

A note on the broader family. CAF and WAF are two of the pillars of Microsoft’s architecture guidance, alongside the Azure Architecture Center (reference architectures, design patterns, architecture styles) and the Mission-Critical guidance (the apex reliability bar). They are designed to be used together: CAF tells you how to adopt; the Architecture Center tells you what to build; WAF tells you whether it is good; Mission-Critical tells you how to push reliability to its limit. This lesson lives squarely in CAF.

The seven CAF methodologies

CAF is organised into methodologies — coherent bodies of guidance for a phase or discipline of adoption. There are seven in the current model. This is the first place to be precise, because the canon changed and many courses, exam dumps, and blog posts are stale.

The seven split into two groups by their cadence:

• Four foundational, sequential methodologies — you move through them roughly in order, once, to establish your cloud presence: Strategy → Plan → Ready → Adopt.
• Three operational, continuous methodologies — they run in parallel, forever, across everything you have adopted: Govern · Secure · Manage.

Why seven, not six (or eight). Older CAF material described six methodologies, with security folded into Govern and Manage rather than standing alone. Microsoft elevated Secure to its own first-class methodology to reflect how central security and Zero Trust have become — so the current, canon-accurate count is seven. (You may also see Adopt drawn as containing two sub-tracks, Migrate and Innovate; those are sub-methodologies of Adopt, not separate top-level methodologies. If a question lists “Migrate” and “Innovate” as peers of Strategy and Plan, treat them as the two paths inside Adopt.) On the exam: if the choices include a standalone Secure, the modern seven-methodology model is what’s being tested.

The four foundational (sequential) methodologies

1. Strategy — establish the why. Before any technology decision, define the motivations (cost savings, datacentre exit, agility, new capabilities, risk reduction), the business outcomes (measurable: “reduce time-to-market for a new market from 9 months to 6 weeks”), and the business case that justifies investment. The signature artefact is a clear, leadership-endorsed statement of why you are doing this. Without it, every later argument — how much to spend on the foundation, how strict governance should be — has no anchor. Strategy is where you decide migrate vs modernise vs innovate at the portfolio level and secure executive sponsorship.

2. Plan — turn strategy into an actionable plan. Inventory and rationalise the existing estate using the 5 Rs (Rehost, Refactor, Rearchitect, Rebuild, Replace — Microsoft’s rationalisation model; you will also see “Retain” and “Retire” as disposition decisions). Build a skills-readiness plan (your people need to learn), and produce a cloud adoption plan — a backlog of workloads, sequenced and estimated, often tracked in Azure DevOps or GitHub. Plan is where wishful strategy becomes a dated, owned, prioritised list of work.

3. Ready — prepare the environment: this is where landing zones live. Ready is the methodology that produces the Azure Landing Zone — the governed foundation. It prescribes the eight design areas (covered in depth below), the landing zone conceptual architecture, and the deployment options (the ALZ accelerator). Critically, Ready embeds a start-small-and-expand philosophy: you do not need a perfect, fully built-out foundation on day one, but you do need the design decisions made and a path to grow into them. Ready is the bridge between CAF the methodology and ALZ the architecture — and the single most exam-relevant CAF methodology, because management-group and subscription design questions are Ready questions.

4. Adopt — migrate and innovate. With a foundation in place, you actually move and build. Adopt contains the two sub-tracks:

• Migrate — bring existing workloads to Azure, typically with Azure Migrate for discovery/assessment and a structured assess → migrate → optimise → secure & manage loop. The 5 Rs from Plan get executed here.
• Innovate — build new, cloud-native capability: modern apps, data platforms, AI. This is where the cloud earns its keep beyond cost savings — the innovate track is about new business value, not just relocating old value.

The three operational (continuous) methodologies

These do not “finish”. They run as long as you are in the cloud, and they apply to everything Strategy/Plan/Ready/Adopt produced.

5. Govern — keep the estate compliant and controlled over time. Governance is the continuous discipline of staying within policy as the estate grows and changes. CAF frames it as the Govern methodology built on the CAF governance benchmark and the Five Disciplines of Cloud Governance: Cost Management, Security Baseline, Resource Consistency, Identity Baseline, and Deployment Acceleration. The mechanism in Azure is overwhelmingly Azure Policy (and initiatives) assigned at the management-group level, plus Azure landing-zone policy baselines that ship with the accelerator. Govern is an incremental discipline: you establish a minimum viable governance baseline, then tighten it as risk and maturity grow — you do not boil the ocean on day one.

6. Secure — protect the estate (now its own methodology). Secure is CAF’s dedicated security methodology, aligned to Zero Trust (verify explicitly, use least-privilege access, assume breach) and the Microsoft Cloud Security Benchmark (MCSB). It spans security operations, asset protection, identity and access, infrastructure and endpoint security, and the security of DevOps and data. In Azure it shows up as Microsoft Defender for Cloud, Microsoft Sentinel, Entra ID controls (Conditional Access, PIM), and the security baseline policies. Its elevation from “part of Govern/Manage” to a standalone methodology is the precise reason the count moved from six to seven.

7. Manage — operate for reliability and ongoing value. Manage is the operations methodology: a management baseline (monitoring, backup, patching/update management, alerting), operations management for business-critical workloads (higher commitments where the business case justifies it), and the bridge to WAF’s Operational Excellence and Reliability pillars. In Azure: Azure Monitor / Log Analytics, Azure Backup, Azure Site Recovery, Update Manager, and the management-subscription resources the landing zone provisions centrally. Manage is where the foundation’s central management subscription earns its place.

Azure Landing Zones: the architecture

A landing zone is an environment that has been provisioned and governed ahead of the workloads that will use it. The term is deliberately physical: when a workload “lands”, the runway — network, identity, policy, monitoring — is already there. The Azure Landing Zone is CAF’s reference implementation of that idea, and it is opinionated on purpose. The opinion is the value: every team lands in the same shape, so security, cost, and operations are consistent by construction rather than by heroics.

The architecture is split into two clearly separated kinds of landing zone, and getting this distinction right is the foundation of everything else.

Platform landing zone vs application landing zone

The platform landing zone is the set of shared, central subscriptions that provide common services to every workload. In the ALZ conceptual architecture these live under a Platform management group and are conventionally three subscriptions:

• Identity — domain controllers / Entra Domain Services, identity sync, the resources that underpin authentication for the estate.
• Connectivity (Network) — the hub: ExpressRoute/VPN gateways, Azure Firewall, DNS private zones, the central network everything routes through.
• Management — Log Analytics workspace, Automation account, backup vaults, the central monitoring and operations plane.

The platform landing zone is owned and operated by the platform team (the CCoE). It is built once, carefully, and changed deliberately. Application teams consume it; they do not modify it.

An application landing zone is a subscription (or set of subscriptions) where a workload actually runs. It is provisioned from the platform — pre-wired with a spoke network peered to the hub, the right RBAC, the policy assignments inherited from above, and a budget — and then handed to an application team to deploy into. Application landing zones live under the Landing Zones management group, typically split into Corp (workloads needing on-prem connectivity / no public exposure) and Online (internet-facing workloads). They come in flavours — for example a subscription per workload, or per-environment subscriptions (prod / non-prod) — chosen by your isolation and blast-radius requirements.

The reason this distinction is load-bearing is separation of duties and blast-radius isolation. The platform team owns shared, high-blast-radius concerns (connectivity, identity, policy) in subscriptions application teams cannot touch. Application teams get autonomy inside their own subscription — they can deploy freely — but the guardrails (policy, networking, RBAC) are inherited and non-negotiable. This is the model that lets a large enterprise give hundreds of teams self-service speed without surrendering governance. The automated provisioning of new application landing zones from the platform is called subscription vending (covered in its own lesson, caf-subscription-vending-platform-automation).

The full conceptual hierarchy, top to bottom: the Tenant Root management group → an intermediate root (e.g. “Contoso”) → then Platform (Identity / Connectivity / Management subscriptions), Landing Zones (Corp / Online application subscriptions), Sandbox (safe experimentation, isolated), and Decommissioned (workloads on the way out). Policy is assigned high in this tree so it inherits down; subscriptions are the unit of scale and the primary management/billing boundary.

The diagram above ties the two concepts together: the management-group hierarchy on the left (with platform and application landing zones), and the eight design areas — the cross-cutting decisions — running across the whole foundation.

The eight design areas

Every enterprise-scale landing zone is the product of decisions across eight design areas. These are not features to switch on; they are decisions to make, each with real tradeoffs. Make them well and the rest is implementation. The eight, in canon order:

1. Azure billing & Microsoft Entra tenant
2. Identity & access management
3. Resource organization
4. Network topology & connectivity
5. Security
6. Management
7. Governance
8. Platform automation & DevOps

The first design area is sometimes framed as the environment design areas (the enrolment and tenant), and the eight are sometimes grouped as foundational (1–4) and “operate” (5–8) — but the canonical AZ-305 list is these eight by name. We will take each in turn, with the central decision and the tradeoff.

1. Azure billing & Microsoft Entra tenant

The decision: what is your billing/enrolment topology, and how many Entra tenants do you have?

This is the bedrock. Your billing comes through an Enterprise Agreement (EA), a Microsoft Customer Agreement (MCA), or a Cloud Solution Provider (CSP) relationship — and the billing hierarchy (billing account → billing profiles → invoice sections, or EA enrollment accounts/departments) determines how cost is segmented and who can create subscriptions. Your Microsoft Entra tenant is the identity and security boundary for the whole estate.

The tradeoff: the strong default is a single Entra tenant. One tenant means one identity boundary, one place to apply Conditional Access and PIM, and the simplest possible governance. Multiple tenants (often inherited from M&A, or demanded by hard sovereignty/regulatory isolation) multiply identity management, complicate cross-tenant access, and break the clean inheritance model — so you adopt multi-tenant only when a real requirement forces it, never for “team separation” (that is what management groups and subscriptions are for). Get this wrong and every later design area inherits the mess.

2. Identity & access management

The decision: how do humans and workloads authenticate and what can they do?

Identity is the new perimeter. This area covers your Entra ID design — hybrid identity (Entra Connect sync vs cloud-only), the RBAC model (custom roles, role assignments at management-group/subscription scope), Privileged Identity Management (PIM) for just-in-time elevation, Conditional Access policies, and managed identities for workloads so secrets stop living in code.

The tradeoff: centralise identity governance (consistency, auditability, least privilege enforced from the top) against the friction it adds to teams. Over-tight RBAC creates ticket queues and shadow workarounds; over-loose RBAC creates standing privilege and breach blast radius. The landing zone’s job is to set a least-privilege baseline with PIM-gated elevation so the common case is frictionless and the dangerous case is gated. (Deep dive: azure-landing-zone-identity.)

3. Resource organization

The decision: how do you structure management groups and subscriptions?

This is the most exam-tested design area. Management groups form a hierarchy above subscriptions and are the inheritance scope for Azure Policy and RBAC — policy assigned at a management group flows to every subscription beneath it. Subscriptions are the primary unit of scale, the management boundary, and a billing/quota boundary. The ALZ reference hierarchy (Platform / Landing Zones / Sandbox / Decommissioned under an intermediate root) is the canonical starting point.

The tradeoff: hierarchy depth vs manageability. A flat structure cannot express differentiated governance (Corp vs Online have genuinely different policy needs); too deep a hierarchy becomes unmanageable and confusing, and Azure limits management-group depth to six levels below root anyway. Subscription granularity is the same tension: more subscriptions give cleaner isolation, independent quotas, and tighter blast radius, but more to govern and vend. The guidance: model management groups on policy/governance needs, not on org chart (org charts change; governance needs are more stable), and use subscriptions for scale and isolation boundaries. Avoid mirroring your HR hierarchy in management groups — a classic anti-pattern. (Deep dive: azure-landing-zone-resource-organization and enterprise-scale-landing-zone-management-group-hierarchy-design.)

4. Network topology & connectivity

The decision: what is your network topology — hub-and-spoke or Virtual WAN — and how do you connect to on-prem and the internet?

The two canonical topologies:

• Traditional hub-and-spoke — you build and manage the hub VNet (with Azure Firewall, gateways, DNS) and peer spoke VNets to it. Maximum control and customisation; you own the routing and the operational burden.
• Virtual WAN (vWAN) — a Microsoft-managed hub that handles transit routing, branch/VPN/ExpressRoute connectivity, and any-to-any spoke connectivity at scale. Less control over the internals, far less operational burden, and the better choice for large, global, many-region estates with lots of branch connectivity.

Plus the connectivity primitives: ExpressRoute (private, dedicated) and/or VPN to on-prem, Azure Firewall for centralised egress inspection, private DNS zones, and Private Link / private endpoints to keep PaaS traffic off the public internet.

The tradeoff: control vs operational burden vs scale. Hub-spoke gives you total control at the cost of running it yourself, and it scales less gracefully across many regions and hundreds of spokes. Virtual WAN trades some control for managed scale and simpler global transit. Choose hub-spoke for smaller/single-region estates that need bespoke routing; choose Virtual WAN when you are global, branch-heavy, or expect the spoke count to explode. (Deep dives: azure-landing-zone-network and azure-virtual-wan-global-network-architecture.)

5. Security

The decision: what is your security baseline across the platform?

This design area operationalises the Secure methodology in the foundation: Microsoft Defender for Cloud (CSPM + workload protection) enabled across subscriptions, Microsoft Sentinel for SIEM/SOAR, encryption (at rest and in transit) standards, Key Vault for secrets/keys/certs, and the security baseline policies that ship with the landing zone. It is Zero Trust made concrete in the platform — assume breach, segment, inspect, and monitor.

The tradeoff: security genuinely adds latency, cost, and failure points (every inspection hop, every private endpoint, every gateway is something that can fail or slow you down) — exactly the WAF Security-vs-Performance/Reliability tension, applied estate-wide. The landing zone’s job is to make the baseline secure-by-default so workloads inherit good posture for free, while leaving room for workload-specific tightening. (Deep dive: azure-landing-zone-security; the workload-level treatment is azure-waf-security.)

6. Management

The decision: how is the platform monitored, backed up, and patched — centrally?

This is the Manage methodology in the foundation: a central Log Analytics workspace (the management subscription’s crown jewel), Azure Monitor for metrics/alerts, Azure Backup and Azure Site Recovery for protection and DR, Update Manager for patching, and the platform-wide alerting and operations baseline. Centralising telemetry means you can answer estate-wide operational questions in one place.

The tradeoff: centralisation vs cost/sovereignty. A single central workspace is operationally ideal but can become a cost and data-residency concern at scale (ingestion is billed, and some data cannot cross regions/borders). The pattern is a central platform workspace for platform/security telemetry, with workload teams able to add their own where isolation or residency demands it. (Deep dive: azure-landing-zone-management.)

7. Governance

The decision: how do you enforce and audit compliance continuously — primarily via Azure Policy?

Governance is the Govern methodology made real: Azure Policy definitions and initiatives assigned at management-group scope to enforce (Deny), audit (Audit), or auto-remediate (DeployIfNotExists / Modify) standards across the estate, plus cost controls (budgets, tags) and the landing-zone policy baseline that the accelerator ships. Policy assigned high inherits down — this is why resource organisation (area 3) and governance (area 7) are joined at the hip.

The tradeoff: preventive (Deny) vs detective (Audit) controls. Deny stops non-compliant resources from ever existing (strong, but it breaks deployments and frustrates teams if mis-scoped). Audit lets you see drift without blocking (low friction, but non-compliance still happens). Mature estates use Deny for the truly non-negotiable (no public IPs on certain resources, allowed regions, required encryption) and Audit + remediate for the rest, tightening over time per the incremental-governance philosophy. (Deep dive: azure-landing-zone-governance.)

8. Platform automation & DevOps

The decision: how is the platform itself defined, deployed, and evolved — as Infrastructure as Code, through pipelines?

The landing zone is itself a software product. This area covers IaC (Bicep or Terraform) for the platform, the CI/CD pipelines (GitHub Actions / Azure DevOps) that deploy and update it, the GitOps/source-of-truth model, and subscription vending automation that mass-produces application landing zones on demand. The principle: no ClickOps on the foundation — every change is code, reviewed, and repeatable.

The tradeoff: up-front automation investment vs long-term velocity and consistency. Building the foundation as IaC with pipelines is slower on day one than clicking it together, but it is the only way to keep hundreds of subscriptions consistent, auditable, and reproducible as the estate grows — and it is what makes self-service subscription vending possible at all. (Deep dive: azure-landing-zone-platform-automation and caf-subscription-vending-platform-automation.)

Deploying the landing zone: the ALZ accelerator

Knowing the eight design areas is the architecture. Actually building the foundation is where the Azure Landing Zone accelerator comes in — Microsoft’s productised, opinionated implementation of the conceptual architecture. There are two principal paths, and choosing between them is itself a design decision tied to the customer’s IaC maturity (design area 8).

The portal accelerator

The portal accelerator is a guided, wizard-style experience in the Azure portal that deploys the full ALZ — management-group hierarchy, platform subscriptions, policy baseline, connectivity — from a set of form choices. It is the fastest path to a working, opinionated foundation, and it is excellent for getting started, demos, and organisations without strong IaC practices. Its limitation is exactly its strength: it is portal-driven, so the foundation itself is born outside source control and pipelines, which sits awkwardly with design area 8’s “no ClickOps on the platform” principle. Many teams use it to bootstrap, then bring the result under IaC.

Azure Verified Modules (Bicep & Terraform)

The modern, recommended path for any organisation with real IaC maturity is the Infrastructure-as-Code accelerator built on Azure Verified Modules (AVM). Azure Verified Modules are Microsoft’s single, official, supported library of reusable IaC modules — one canonical module per resource/pattern, available in both Bicep and Terraform, that bake in WAF and ALZ best practices. AVM replaced the older fragmented module landscape (CARML, the Terraform AzureRM landing-zone modules, sundry community modules) with one consistent, Microsoft-owned standard.

The ALZ accelerator on AVM gives you the whole foundation as code: the management-group hierarchy, policy assignments, platform subscriptions, and connectivity expressed as Bicep or Terraform modules, deployed through CI/CD pipelines (GitHub Actions or Azure DevOps) with the source of truth in Git. This is the path that satisfies design area 8 end-to-end: the platform is versioned, reviewed, reproducible, and continuously deployable — and it is what makes mass subscription vending of application landing zones practical.

Bicep vs Terraform within AVM is a tooling/operating-model choice, not a capability gap — AVM ships both. Choose Bicep if you are an Azure-only shop wanting the tightest Azure integration, native ARM tooling, and no state file to manage. Choose Terraform if you are multi-cloud, already standardised on Terraform/HCL, and want one IaC language across providers (and you accept managing state). The decision follows your existing engineering standards, not Azure capability.

The rule of thumb: AVM-based IaC is the default for any serious enterprise estate; the portal accelerator is for bootstrapping and learning. A common, pragmatic sequence is to deploy with the portal accelerator to see the shape quickly, then re-platform onto AVM Bicep/Terraform so the foundation lives in Git going forward.

Real-world application

How does all this show up in an actual Azure design, the kind you would present to an architecture review board?

A regulated enterprise (say a logistics carrier or a bank) onboarding to Azure does not start by creating VMs. The platform team runs CAF top-down. Strategy produces a board-approved motivation (datacentre exit + faster market entry) and business case. Plan uses Azure Migrate to inventory 800 on-prem servers, rationalises them with the 5 Rs (rehost the legacy SAP, rearchitect the customer portal, retire 120 dead VMs), and produces a sequenced backlog. Ready is where the architecture happens: the team deploys the ALZ via the AVM Terraform accelerator (they are multi-cloud), standing up an intermediate root management group, Platform subscriptions (Identity, Connectivity with a Virtual WAN hub because they are global, Management with a central Log Analytics workspace), and Landing Zones management groups split Corp/Online. The eight design areas are each a documented decision in the design doc — single Entra tenant; PIM-gated RBAC baseline; six-level-max management-group hierarchy modelled on governance not org chart; Virtual WAN with ExpressRoute to on-prem; Defender for Cloud + Sentinel everywhere; central monitoring/backup; an Azure Policy baseline with Deny on disallowed regions and public IPs; and the whole thing in Git with GitHub Actions pipelines.

Then Adopt runs: workloads are migrated and built into application landing zones that are vended automatically from the platform — a team requests an environment, subscription vending provisions a new subscription pre-peered to the vWAN hub, with policy inherited and a budget attached, and hands it over. Meanwhile Govern, Secure, Manage run continuously — policy compliance dashboards, Defender posture, central operations — and every individual workload that lands is separately assessed against WAF (is this workload reliable, secure, cost-efficient?). That is CAF and WAF working together exactly as designed: CAF built and runs the estate; WAF judges each house in it.

You can see this concretely in the course’s enterprise examples — enterprise-arch-azure-landing-zone and the multi-cloud secure-multicloud-landing-zone-global-logistics and zero-downtime-multicloud-landing-zone-universal-bank case studies all instantiate exactly this CAF/ALZ skeleton.

Going deeper

The sections above are the architecture as an AZ-305 candidate needs to reason about it. This section is the operational reality underneath — the internals, identity plumbing, limits, cost, and failure modes that only show up when you actually build and run a landing zone. None of it re-teaches the eight design areas; it is the layer beneath them.

Azure Blueprints is deprecated — what packages a landing zone now

Older ALZ material — and some exam dumps — reference Azure Blueprints as the way to bundle a management-group structure, policy assignments, and RBAC into one repeatable artefact. Do not build anything new on it. Azure Blueprints never left preview and is deprecated, with retirement dated 11 July 2026. Its replacement is a combination of three GA capabilities: Template Specs (versioned ARM/Bicep templates stored as a first-class resource so they can be shared and pinned), Deployment Stacks (a Microsoft.Resources/deploymentStacks resource that manages a whole set of resources as one atomic unit and can apply deny settings — denyDelete or denyWriteAndDelete — so the platform’s own resources can’t be casually changed or deleted), and Azure Policy for the ongoing enforcement Blueprints could never do well. For the landing zone specifically, the “blueprint” is now the ALZ Bicep/Terraform accelerator plus its policy library — code, not a portal artefact. If a scenario still names Blueprints as the recommended path, it is stale.

How a policy actually enforces: DINE, managed identities, remediation

A policy with an Audit or Deny effect needs nothing but the assignment. But the two effects that change the estate — DeployIfNotExists (DINE) and Modify — need an identity, and this is where real deployments break. When you assign such a policy, Azure attaches a managed identity to the assignment, and that identity must hold the exact roles listed in the definition’s roleDefinitionIds (for a diagnostic-settings DINE, e.g. Monitoring Contributor + Log Analytics Contributor). Two failure modes bite everyone:

1. The identity has no role. Assign a DINE policy by IaC and forget the role assignment, and the policy evaluates, reports non-compliant, and silently deploys nothing. In the portal the role is granted for you; in Bicep/Terraform you must create the identity and its role assignment explicitly.
2. Existing resources stay non-compliant. DINE and Modify only act on create/update by default. Resources that already exist are flagged but never fixed until you run a remediation task (az policy remediation create), which walks existing resources and applies the effect through that managed identity.

Two more nuances: compliance is re-evaluated on a cycle (about every 24 hours) or on demand (az policy state trigger-scan), so “it reports non-compliant” and “it is unenforced” are different statements; and every assignment carries an enforcementMode — setting it to DoNotEnforce evaluates and reports without actually applying Deny or deploying anything, which is how you safely trial a policy across a live estate before turning it on. (Deep dive: Landing zone governance.)

Management-group mechanics: limits, consistency, the tenant-root trap

Management groups look trivial and hide sharp edges. The hard limits: up to 10,000 management groups per tenant; a tree that is six levels deep (not counting the root level or the subscription level); and one parent per management group or subscription. The root group (the “Tenant Root Group”) is special — it can’t be moved or deleted, and by default even a Global Administrator has no RBAC there until they elevate access (Microsoft.Authorization/elevateAccess), which grants User Access Administrator at the / scope. That elevation is a break-glass action, not a daily tool: leave it switched on and every Global Admin can silently touch every subscription. Two operational traps follow: management-group operations are eventually consistent (a freshly created group, or a just-moved subscription, may not appear in a query for a short while — automation must retry, not assume), and inheritance flows down but never up, which is precisely why resource organisation and governance are one conversation. Model the tree on governance archetypes (Platform, Corp, Online, Sandbox), because moving a subscription between groups re-evaluates every inherited policy — cheap to plan, expensive to re-org later.

Subscription vending under the hood

Subscription vending is where the platform stops being a diagram and becomes an API. Programmatic subscription creation is the Microsoft.Subscription/aliases resource, and it needs a billing role, not just Azure RBAC: on an Enterprise Agreement you need an enrollment Account Owner; on a Microsoft Customer Agreement you need Owner or Contributor on an invoice section or billing profile. The vending automation — the Azure Verified Modules lz-vending pattern module, shipped in both Bicep and Terraform — does four things as one unit: create the subscription, place it in the correct management group (so policy is inherited the instant the subscription exists), peer its spoke to the hub or Virtual WAN, and stamp RBAC plus a budget. Watch the ceilings: Azure RBAC caps role assignments at roughly 4,000 per subscription, and management-group/subscription moves are throttled — so “a subscription per tiny app” can hit limits and governance overhead. Right-size instead: subscription-per-workload for genuine blast-radius needs, per-team or per-environment otherwise. (Deep dive: Subscription vending.)

The platform tax: what the foundation itself costs

The foundation is not free, and newcomers are surprised by the platform tax — the run-rate of the shared services before a single workload ships. The usual line items: the central Log Analytics workspace bills per GB ingested (with commitment tiers, e.g. 100 GB/day, that discount steady volume, plus retention charges beyond the free window); Microsoft Defender for Cloud plans bill per resource-hour; Azure Firewall carries a fixed hourly deployment cost plus per-GB processed; a Virtual WAN hub bills per hub-hour plus data; and ExpressRoute is a standing circuit charge. None is enormous alone, but together they are why the platform needs its own budget and cost-owner, and why design area 6 warns against a single mega-workspace — ingestion is the sleeper cost at scale. (Figures are directional and region-dependent; model them in the Azure pricing calculator rather than quoting from memory.)

IaC operational reality: state, provider versions, module lineage

Two implementation truths the accelerator glosses over. First, Terraform state: the platform’s state must live in a remote backend — a locked Azure Storage account — and that backend is a chicken-and-egg problem, because you need a subscription and a storage account to hold the state that builds your subscriptions. Teams bootstrap it once (a tiny seed config or a manual step), then migrate state into it. Second, provider versions: azurerm v4 made subscription_id required in the provider block (or via the ARM_SUBSCRIPTION_ID environment variable) and removed long-deprecated fields — so pinning the provider version is not optional for a foundation that must deploy identically for years. And module lineage: the long-standing Terraform path was Azure/caf-enterprise-scale/azurerm (the “ALZ” module), which Microsoft is converging onto Azure Verified Modules pattern modules (e.g. avm-ptn-alz); a mature estate pins module versions and plans that migration deliberately rather than floating on latest. (Deep dive: Platform automation & DevOps.)

Common beginner mistakes

These are the conceptual traps newcomers fall into — a wrong mental model and the right one to replace it. They are distinct from the senior design anti-patterns (org-chart management groups, day-one Deny sprawl, ClickOps foundations) catalogued in Common mistakes & anti-patterns below.

• “A landing zone is just the network.” The network is only one of eight design areas. A landing zone is the entire governed foundation — identity, policy, management, billing, and network. Right model: the hub VNet is a room in the house, not the house.
• “CAF is a checklist you finish, then you’re done.” Four methodologies really do finish (Strategy → Plan → Ready → Adopt run roughly once); three — Govern, Secure, Manage — run forever. CAF is a way of operating an estate, not a box you tick and file away.
• “CAF and the Azure Landing Zone are the same thing.” CAF is the guidance and journey; the ALZ is the artefact the Ready methodology produces. One is the recipe, the other is the meal you cook from it.
• “I’ll set the governance rules on my subscription.” Policy and RBAC are meant to be assigned high — at a management group — and inherited down. Hand-configuring each subscription is exactly the toil a landing zone exists to eliminate; if you’re editing per-subscription policy, your scope is probably wrong.
• “The application landing zone is a resource group for my app.” It is a whole subscription (or a small set of them), vended from the platform with networking, policy, and RBAC already wired. Resource groups live inside it — they are not the same unit.
• “Sandbox is where we can run cheap production.” Sandbox is deliberately isolated — looser policy, no corporate or on-prem connectivity, a capped budget — for throwaway experiments only. Anything real belongs under Corp or Online, where the guardrails actually apply.
• “A deeper management-group tree means stronger governance.” Depth is capped at six levels and every layer is overhead you must reason about. Governance strength comes from the right policies at the right scope, not from more tiers — a shallow, well-placed hierarchy beats a deep, confused one every time.

Common mistakes & anti-patterns

• Mirroring the org chart in management groups. Management groups should model governance and policy needs, which are relatively stable, not the HR/org structure, which reorganises constantly. Org-chart hierarchies churn and force painful subscription moves; governance hierarchies (Platform / Corp / Online / Sandbox) endure.
• Treating CAF and WAF as the same thing — or as a single checklist. They are different altitudes. Applying WAF to “the organisation” or CAF to “a workload” produces confused designs. Know which question you are answering.
• Skipping Strategy and Plan and jumping straight to building a landing zone. A foundation with no business case behind it has no anchor for its governance strictness, its cost ceiling, or its scope — and tends to get over- or under-built.
• Building the platform by ClickOps in the portal and never bringing it into IaC. The foundation is the highest-blast-radius thing you own; it must be code (AVM Bicep/Terraform) so it is reproducible, auditable, and safely changeable. The portal accelerator is a bootstrap, not a destination.
• Letting application teams modify platform (shared) subscriptions. This destroys separation of duties and blast-radius isolation. Application teams own their application landing zones; the platform team owns Identity/Connectivity/Management. Vending, not editing.
• Over-using Deny policies on day one. Aggressive preventive policy across the whole estate breaks deployments and trains teams to route around governance. Start with a minimum viable baseline (Deny only the non-negotiable; Audit the rest) and tighten incrementally.
• Defaulting to multiple Entra tenants for “separation”. Multi-tenant multiplies identity overhead and breaks inheritance. Use management groups and subscriptions for separation; reserve multi-tenant for genuine sovereignty/regulatory or M&A requirements.
• Choosing hub-spoke vs Virtual WAN by habit instead of by scale. Hand-rolling hub-spoke for a global, branch-heavy, hundred-spoke estate is an operational trap; conversely, paying for Virtual WAN’s managed transit on a tiny single-region estate is over-engineering. Match topology to scale and control needs.
• Saying “six methodologies” / forgetting Secure is now standalone. The current model is seven, with Secure as its own methodology. Stale “six” answers are a tell on the exam.
• Confusing platform landing zones with application landing zones (or thinking “landing zone” means only the network). Platform = shared central subscriptions (Identity/Connectivity/Management); application = where workloads run. Both are landing zones.

Interview & exam questions

These concepts dominate AZ-305’s design sections. Practise reasoning to the answer, not just recognising it.

1. A company is reorganising frequently. How should they structure management groups so the hierarchy does not need constant restructuring? — Model management groups on governance/policy needs (e.g. Platform / Corp / Online / Sandbox), not on the org chart. Governance needs are stable; org charts churn. This is the canonical AZ-305 management-group question.

2. What is the difference between a platform landing zone and an application landing zone? — A platform landing zone is the shared central subscriptions (Identity, Connectivity, Management) owned by the platform team. An application landing zone is a subscription where a workload actually runs, vended from the platform with policy/networking/RBAC inherited and owned by an application team.

3. You need to enforce that no storage account in the estate allows public network access. Where and how do you implement this? — An Azure Policy with a Deny effect, assigned at a management-group scope so it inherits to all subscriptions beneath. (Audit if you need visibility without blocking; DeployIfNotExists/Modify to remediate.)

4. When would you choose Virtual WAN over a traditional hub-and-spoke topology? — When the estate is large, global, multi-region, and branch-heavy, and you want Microsoft-managed transit routing with lower operational burden. Choose hub-spoke when you need maximum control/bespoke routing and the scale is modest/single-region.

5. Name the seven CAF methodologies and group them. — Four foundational/sequential: Strategy → Plan → Ready → Adopt. Three operational/continuous: Govern · Secure · Manage. (If the question offers “six”, the model is stale — Secure is now standalone.)

6. Which CAF methodology produces the Azure Landing Zone? — Ready. It defines the eight design areas, the conceptual architecture, and the deployment accelerators.

7. A workload needs on-prem connectivity and must not be internet-facing. Which application landing-zone management group does it belong under? — Corp (Connected) — for workloads requiring private/on-prem connectivity. Internet-facing workloads go under Online.

8. What is the recommended way to deploy and maintain the landing zone as code, in either Bicep or Terraform? — The ALZ accelerator built on Azure Verified Modules (AVM) — Microsoft’s single official module library, available in both Bicep and Terraform, deployed via CI/CD pipelines with Git as the source of truth.

9. How do CAF and WAF relate, and which applies to a single workload? — CAF is the organisational adoption journey (builds/runs the estate and the landing zone); WAF applies to a single workload (judges its quality across five pillars). You use both; WAF is per-workload.

10. How are new subscriptions provisioned at scale for application teams in an ALZ? — Via subscription vending — automated provisioning (IaC/pipelines) of new application-landing-zone subscriptions, pre-wired with networking (spoke peered to hub/vWAN), inherited policy, RBAC, and a budget.

11. What are the Five Disciplines of Cloud Governance in CAF? — Cost Management, Security Baseline, Resource Consistency, Identity Baseline, and Deployment Acceleration — the structure of the Govern methodology.

12. A single Entra tenant or multiple — what is the default and when do you deviate? — Default to a single tenant (one identity/security boundary, simplest governance). Deviate only for genuine sovereignty/regulatory isolation or M&A realities — never for mere team separation.

Quick check

Q1. True or false: the Well-Architected Framework is the right tool to assess whether an entire organisation is adopting cloud well.

Q2. How many CAF methodologies are there in the current model, and which one was elevated to standalone status (causing the count to change)?

Q3. Which three subscriptions conventionally make up the platform landing zone?

Q4. Where should you assign an Azure Policy so it applies to every subscription beneath a given part of the hierarchy?

Q5. What is the Microsoft-recommended IaC foundation for deploying an Azure Landing Zone in both Bicep and Terraform?

Answers

A1. False. WAF assesses a single workload. The organisational adoption journey is the Cloud Adoption Framework (CAF).

A2. Seven. Secure was elevated from being folded into Govern/Manage to its own methodology, moving the count from six to seven.

A3. Identity, Connectivity (Network), and Management — the shared central subscriptions under the Platform management group.

A4. At the management-group scope above those subscriptions — Azure Policy (and RBAC) inherit downward through the management-group hierarchy.

A5. The ALZ accelerator built on Azure Verified Modules (AVM) — one official module library available in both Bicep and Terraform, deployed via pipelines.

Exercise

The scenario (a design thought-experiment). You are the lead architect for Northwind Freight, a global express-and-cold-chain carrier moving to Azure. Constraints:

• ~600 workloads to migrate over 18 months; a further pipeline of new cloud-native apps (tracking, IoT telemetry).
• Operations in 14 countries; two have strict data-residency laws. The company is multi-cloud (some AWS already).
• Three big workload classes: internet-facing customer/partner portals; internal back-office (must reach on-prem ERP, no public exposure); and a sandbox for the data-science team to experiment freely.
• A regulator requires that no production resource is deployable outside approved regions, and all storage must deny public network access.
• The platform team is small but strong on Terraform; they want self-service for the ~40 application teams.

Your task: sketch the CAF/ALZ design. Decide: (a) tenant strategy; (b) management-group hierarchy; © the platform-subscription set and network topology; (d) where the three workload classes land; (e) how you enforce the two regulatory rules; (f) how application teams get environments; (g) which deployment accelerator/IaC path.

---

A model answer.

(a) Tenant strategy. Single Entra tenant. The data-residency requirement is about data location (handled by region policy and resource placement), not identity isolation — it does not justify multi-tenant. One tenant keeps identity governance, Conditional Access, and PIM simple. (Deviate only if a regulator literally mandates a separate identity boundary.)

(b) Management-group hierarchy. Tenant Root → intermediate root “Northwind” → Platform, Landing Zones (with Corp and Online children), Sandbox, Decommissioned. Modelled on governance, not the 14-country org chart. Stays well within the six-level limit.

© Platform subscriptions + network. Three platform subscriptions: Identity, Connectivity, Management (central Log Analytics). Network topology = Virtual WAN — the estate is global and multi-region with on-prem (ERP) connectivity and many spokes, which is exactly vWAN’s sweet spot; hand-rolling hub-spoke across 14 countries would be an operational trap. ExpressRoute/VPN into the vWAN hub for on-prem ERP; Azure Firewall for central egress; Private Link for PaaS.

(d) Where workloads land. Internet-facing portals → Online application landing zones. Back-office reaching on-prem ERP with no public exposure → Corp application landing zones (private connectivity via the vWAN hub). Data-science experimentation → the Sandbox management group (isolated, looser policy, capped budget). Use subscription-per-workload (or prod/non-prod pairs) for blast-radius isolation.

(e) Enforcing the regulatory rules. Two Azure Policy definitions assigned at the management-group level with Deny effect: an allowed-locations policy (production scope) denying resource creation outside approved regions, and a storage public network access policy denying public-enabled storage accounts. Assigned high so they inherit to every subscription — assign the region policy on the production management groups (Corp/Online) and the storage policy estate-wide. Add Audit/remediate policies for the softer standards (tags, diagnostics). This is the preventive-vs-detective tradeoff applied: Deny for the two non-negotiable regulator rules, Audit for the rest.

(f) Self-service for 40 teams. Subscription vending — automated provisioning of application-landing-zone subscriptions from the platform: a team requests an environment, the pipeline creates a subscription pre-peered to the vWAN hub, with inherited policy, RBAC, and a budget, then hands it over. Teams get autonomy inside their subscription; guardrails are inherited and non-negotiable.

(g) Deployment path. The AVM Terraform ALZ accelerator — the team is multi-cloud and Terraform-strong, so one IaC language across Azure and AWS, with the foundation in Git and deployed through pipelines (satisfying design area 8 fully). They might bootstrap once with the portal accelerator to see the shape, then operate on AVM Terraform.

The point of the exercise is the reasoning: every choice traces to a stated requirement and a named tradeoff, which is exactly how an architecture review board evaluates a landing-zone design — and how AZ-305 scenario questions are scored.

Practice challenges

Work these top to bottom; each solution gives the answer and, in one line, why. No Azure subscription is needed — these are design-reasoning drills, which is exactly how AZ-305 is scored. Every az/policy snippet is illustrative; all IDs are placeholders.

1. (Beginner) Sort activities into methodologies. Label each with its CAF methodology and say whether it is sequential (once) or continuous (forever): (a) writing the board-approved business case; (b) tightening an Azure Policy initiative each quarter as risk grows; © running Azure Migrate to inventory 800 on-prem servers; (d) enabling Defender for Cloud across every subscription.

<details><summary>Solution</summary>

(a) Strategy — sequential. (b) Govern — continuous. © Plan — sequential. (d) Secure — continuous. Why: the sequential-vs-continuous split (Strategy/Plan/Ready/Adopt once; Govern/Secure/Manage forever) is the backbone of the seven-methodology model. </details>

2. (Beginner) Place workloads under the right management group. Three workloads: a public marketing site; an internal payroll app that must reach the on-prem HR database and must never be internet-facing; a data scientist’s throwaway experiment. Which management group does each land under?

<details><summary>Solution</summary>

Public site → Online. Payroll (private, on-prem-connected) → Corp. Experiment → Sandbox. Why: Corp = private/on-prem-connected, Online = internet-facing, Sandbox = isolated experimentation — the archetypes that differentiated policy hangs off. </details>

3. (Intermediate) Enforce “no public storage” estate-wide. A regulator says no storage account anywhere may allow public network access. At what scope do you assign the policy, with what effect, and sketch the CLI.

<details><summary>Solution</summary>

Assign at the intermediate-root (or a top) management group with the Deny effect, so it inherits to every subscription beneath:

az policy assignment create \
  --name deny-public-storage \
  --scope /providers/Microsoft.Management/managementGroups/<mg-id> \
  --policy <policy-definition-id> \
  --enforcement-mode Default

Why: assign-high-inherit-down + Deny is the canonical governance mechanic — enforce the non-negotiable rule once, at a scope every subscription sits under. </details>

4. (Intermediate) Hub-spoke or Virtual WAN? Estate A: single region, one hub, ~15 spokes, bespoke routing needs. Estate B: 14 countries, hundreds of branches and spokes, growing fast. Pick a topology for each, and name the platform subscription the hub lives in.

<details><summary>Solution</summary>

A → hub-and-spoke (maximum control, modest scale, you own the routing). B → Virtual WAN (Microsoft-managed global transit, far lower operational burden at scale). Both hubs live in the Connectivity platform subscription. Why: topology is chosen by scale and operational-burden appetite, not by habit — and the hub is always a platform-owned concern. See Virtual WAN global network architecture. </details>

5. (Advanced) A DINE policy that deploys nothing. You assign a DeployIfNotExists policy (deploy diagnostic settings to Log Analytics) via Terraform. New resources still show non-compliant, existing ones too, and nothing deploys. Give the two most likely causes and the fix.

<details><summary>Solution</summary>

Cause 1: the assignment’s managed identity was never created, or lacks the roles in the definition’s roleDefinitionIds (e.g. Monitoring Contributor + Log Analytics Contributor) — in IaC you must create the identity and its role assignment yourself; the portal does it silently. Cause 2: DINE only acts on create/update, so existing resources need a remediation task: az policy remediation create --name fix-diag --policy-assignment <assignment-id> --management-group <mg-id>. Also confirm enforcementMode is not DoNotEnforce. Why: managed-identity roles + remediation tasks are the number-one reason a “correct” policy quietly does nothing. </details>

6. (Advanced) Design subscription vending for 40 teams. Outline the vending design: the billing role required, the four things the automation must do as one unit, and the module and API involved.

<details><summary>Solution</summary>

Billing role: an EA Account Owner (or, on an MCA, Owner/Contributor on an invoice section). Atomic steps: (1) create the subscription (Microsoft.Subscription/aliases); (2) place it in the correct management group (instant policy inheritance); (3) peer its spoke to the hub/Virtual WAN; (4) apply RBAC + a budget. Module: the AVM lz-vending pattern module (Bicep or Terraform). Why: vending is the API that turns “give me an environment” into a governed, guard-railed subscription in minutes — self-service without surrendering control. </details>

Certification mapping

AZ-305 — Designing Microsoft Azure Infrastructure Solutions (primary). CAF and Azure Landing Zones are core to multiple objective domains:

• Design identity, governance, and monitoring solutions — management-group hierarchy and subscription design (resource organization), Azure Policy governance (placement, Deny vs Audit, initiatives), RBAC/PIM, central monitoring/Log Analytics. This domain is saturated with Ready/Govern/Manage design-area questions.
• Design data storage / business continuity — touches the Management design area (backup, Site Recovery) and region/residency decisions enforced by policy.
• Design infrastructure solutions — connectivity topology (hub-spoke vs Virtual WAN), compute/network placement into application landing zones, and the platform foundation generally.

Expect scenario questions where the correct answer hinges on: assigning policy at the right scope, modelling management groups on governance not org chart, the single-vs-multi-tenant decision, hub-spoke vs vWAN by scale, and platform-vs-application landing-zone responsibility.

AZ-104 — Azure Administrator (supporting). The operate side of these design areas: creating/managing management groups, subscriptions, RBAC, Azure Policy assignments, virtual networks/peering, Azure Monitor and Backup. AZ-104 tests you on doing what AZ-305 tests you on designing.

AZ-204 — Developer (peripheral). Where it touches: deploying into application landing zones, using managed identities instead of secrets, and consuming platform services (Key Vault, private endpoints) — i.e. living correctly inside the guardrails the landing zone sets.

Beyond Microsoft certs, the enterprise-scale / landing-zone reasoning here is exactly what is probed in cloud-architect interviews and internal architecture review boards.

Glossary

• Cloud Adoption Framework (CAF) — Microsoft’s end-to-end guidance for the organisational cloud journey: strategy, plan, the governed foundation, the operating model, and continuous governance/security/management.

• Well-Architected Framework (WAF) — Microsoft’s framework for assessing a single workload against five pillars (Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency).

• Methodology (CAF) — one of the seven bodies of CAF guidance: Strategy, Plan, Ready, Adopt (foundational/sequential) and Govern, Secure, Manage (operational/continuous).

• Azure Landing Zone (ALZ) — CAF’s opinionated reference implementation of a pre-provisioned, governed Azure foundation that workloads land in.

• Platform landing zone — the shared central subscriptions (Identity, Connectivity, Management) owned by the platform team; consumed, not modified, by application teams.

• Application landing zone — a subscription where a workload runs, vended from the platform with networking, policy, and RBAC inherited; owned by an application team.

• Eight design areas — the eight decisions every ALZ is built from: Azure billing & Entra tenant; Identity & access; Resource organization; Network topology & connectivity; Security; Management; Governance; Platform automation & DevOps.

• Management group — a scope above subscriptions in the Azure hierarchy; the inheritance point for Azure Policy and RBAC (max six levels below root).

• Subscription — the primary unit of scale, management boundary, and billing/quota boundary in Azure; where resources live.

• Hub-and-spoke — a network topology with a customer-managed central hub VNet and peered spokes; maximum control, more operational burden.

• Virtual WAN (vWAN) — a Microsoft-managed networking hub for global transit, branch, and any-to-any connectivity at scale; less control, less operational burden.

• Azure Policy — the governance engine; definitions/initiatives assigned at scope to enforce (Deny), audit (Audit), or remediate (DeployIfNotExists/Modify) standards.

• Subscription vending — automated provisioning of new application-landing-zone subscriptions from the platform, pre-wired with guardrails.

• Azure Verified Modules (AVM) — Microsoft’s single, official, supported IaC module library, available in both Bicep and Terraform, embedding WAF/ALZ best practice.

• ALZ accelerator — Microsoft’s productised deployment of the landing zone: the portal accelerator (wizard) or the IaC accelerator built on AVM (Bicep/Terraform + pipelines).

• CCoE (Cloud Centre of Excellence) — the central team that owns the platform landing zone and the CAF disciplines.

• 5 Rs — the rationalisation model in Plan: Rehost, Refactor, Rearchitect, Rebuild, Replace (with Retain/Retire as dispositions).

• Deployment Stacks — a Microsoft.Resources/deploymentStacks resource that manages a whole set of resources as one atomic unit and can apply deny settings (denyDelete/denyWriteAndDelete) to protect them; a modern replacement for parts of the deprecated Azure Blueprints.

• Azure Blueprints (deprecated) — the older way to package management-group structure, policy, and RBAC as one artefact; deprecated and retiring (11 July 2026) in favour of Deployment Stacks + Template Specs + Azure Policy and the ALZ IaC accelerator.

• DeployIfNotExists (DINE) — an Azure Policy effect that deploys a missing resource (e.g. diagnostic settings) to bring a target into compliance; needs a managed identity holding the definition’s roles, and a remediation task for resources that already exist.

• Modify (policy effect) — an Azure Policy effect that adds, updates, or removes resource properties (e.g. tags); like DINE it requires a managed identity.

• Remediation task — the operation that applies a DINE/Modify policy to resources that already exist (policy otherwise only acts on create/update).

• Managed identity — an Entra ID identity Azure manages for you, so services and policy assignments authenticate without secrets living in code.

• Privileged Identity Management (PIM) — an Entra ID P2 feature for just-in-time, time-bound activation of privileged roles instead of standing access.

• Elevate access — a tenant-root action (Microsoft.Authorization/elevateAccess) that grants a Global Administrator User Access Administrator at the / scope to manage all management groups and subscriptions; a break-glass step, not a daily one.

• Break-glass (emergency access) account — a cloud-only, tightly monitored account excluded from normal Conditional Access, kept for tenant recovery when routine admin access fails.

• enforcementMode — a policy-assignment setting; DoNotEnforce evaluates and reports compliance without applying Deny/DINE (a safe trial mode), versus Default, which enforces.

• caf-enterprise-scale — the long-standing Azure/caf-enterprise-scale/azurerm Terraform module for the ALZ, now converging onto Azure Verified Modules pattern modules (e.g. avm-ptn-alz).

• Five Disciplines of Cloud Governance — the structure of the Govern methodology: Cost Management, Security Baseline, Resource Consistency, Identity Baseline, and Deployment Acceleration.

Next steps

• Next lesson: Choosing an Architecture: Styles & the Ten Design Principles (azure-cloud-architecture-styles-design-principles) — having built the foundation, we turn to what you build on it: the six architecture styles as constraint systems and the ten design principles for Azure applications.
• Build the foundation, design area by design area — the implementation series drills each of the eight to Bicep/Terraform depth: azure-landing-zone-billing-tenant, azure-landing-zone-identity, azure-landing-zone-resource-organization, azure-landing-zone-network, azure-landing-zone-security, azure-landing-zone-management, azure-landing-zone-governance, azure-landing-zone-platform-automation.
• A worked landing-zone blueprint — azure-landing-zone-caf walks an enterprise-scale Azure landing zone end to end (management groups, subscription democratization, hub-spoke, policy, identity) with Bicep and Terraform.
• Subscription vending in depth — caf-subscription-vending-platform-automation and enterprise-scale-landing-zone-management-group-hierarchy-design for the self-service/at-scale mechanics.
• The CAF methodologies, lesson by lesson — azure-caf-strategy, azure-caf-plan, azure-caf-ready, azure-caf-migrate, azure-caf-modernize, azure-caf-innovate, azure-caf-govern, azure-caf-secure, azure-caf-manage.
• Where WAF meets the workloads on this foundation — azure-waf-reliability and azure-waf-security for the per-workload bar, and azure-multi-region-active-active-disaster-recovery for resilience design on top of the landing zone.