Lesson 24 — Azure Landing Zones & Cloud Adoption Framework

Enterprise Architecture Beyond AZ-104 ~40 min

Why This Matters for Senior Admins

This lesson goes beyond the AZ-104 exam syllabus — intentionally. Every senior Azure administrator who joins an enterprise will be working inside a landing zone, even if nobody called it that when they built it. Understanding the Cloud Adoption Framework and the landing zone model is what separates an admin who can execute tasks from one who understands why the environment is structured the way it is.

When you understand landing zones, you understand why certain policies are applied at certain scopes, why there is a dedicated subscription for networking, why your subscription was automatically pre-configured with specific RBAC assignments, and why deviating from the structure creates governance debt that compounds over time.

This is also the model you will reference when building new environments or when your organisation migrates from ad-hoc Azure usage to a governed enterprise deployment.

Cloud Adoption Framework (CAF) Overview

The Cloud Adoption Framework is Microsoft's proven, prescriptive guidance for enterprise Azure adoption. It is a structured methodology — not a product — that covers the entire journey from initial business case through to ongoing operations management.

CAF is organised into six phases that are iterative, not strictly sequential. Large organisations often run multiple phases in parallel across different workload streams.

CAF Phase Primary Focus Key Outputs
Strategy Define business outcomes and motivations for cloud adoption Business case, cloud motivation statement, stakeholder alignment
Plan Rationalise digital estate, assess skills, build adoption roadmap Digital estate assessment, skills gap analysis, migration backlog
Ready Prepare the Azure environment — landing zones, skills, cloud readiness Landing zone deployment, Azure fundamentals training, environment validation
Adopt Migrate and modernise workloads into the prepared environment Migrated workloads, modernised applications, validated deployments
Govern Baseline governance across Cost Management, Security, Identity, Resource Consistency, and Deployment Acceleration disciplines Policy initiatives, RBAC model, tagging strategy, governance MVP
Manage Operations management — workload operations, platform operations, reliability Operations baseline, workload SLAs, backup and recovery runbooks
Govern is ongoing — not a one-time phase A common misconception is that Govern happens after Adopt. In practice, the Govern phase runs in parallel with Adopt from the beginning. You establish a governance baseline before workloads land, and you evolve governance disciplines iteratively as more workloads and teams onboard. Governance never ends.

What Is an Azure Landing Zone?

An Azure Landing Zone is a pre-configured, scalable environment that provides the foundational infrastructure on which workloads are deployed. It is the output of the CAF Ready phase.

The key principle: a landing zone provides all workloads with a consistent, governed environment — identity, management groups, subscriptions, networking, governance policies, and security baselines — before any application code is deployed. Workloads should not have to build this foundation themselves.

Landing zone ≠ subscription A landing zone is not a single subscription. It is the entire environment — the management group hierarchy, platform subscriptions, governance policies, hub networking, identity configuration, and monitoring infrastructure. Individual workload subscriptions are deployed into the landing zone, not as the landing zone itself.

Two categories of landing zone subscriptions

CAF distinguishes between two types of subscriptions within the landing zone structure:

  • Platform Landing Zones: Subscriptions that host shared infrastructure used by all workloads — the connectivity hub, identity services, and management/monitoring tooling. These are managed by the platform team.
  • Application Landing Zones: Subscriptions for individual workload teams. Each team gets their own subscription (or set of subscriptions) with pre-configured governance, networking, and RBAC. These are managed by the workload teams, within platform-enforced guardrails.

The ALZ Management Group Hierarchy

The Azure Landing Zone reference architecture defines a specific, shallow management group hierarchy. Every subscription belongs to exactly one management group, and policies cascade from top to bottom.

🏢 Tenant Root Group ├─ Platform │ ├─ Management (Log Analytics, Automation, Defender for Cloud, Update Mgmt) │ ├─ Identity (AD DS VMs or Entra Domain Services) │ └─ Connectivity (Hub VNet, Azure Firewall, VPN/ER GW, DNS Resolver) ├─ Landing Zones │ ├─ Corp (VNets peered to hub — can reach on-prem & other Corp workloads) │ └─ Online (internet-facing apps — no Corp network peering) ├─ Sandbox (experimentation — no prod data, no hub peering, liberal policies) └─ Decommissioned (subscriptions being wound down — Deny-All policy applied)

Purpose of each node

Management Group / Subscription Purpose Key Policy Behaviour
Tenant Root Group Global governance baseline for all subscriptions in the tenant Global deny policies, audit-all tags, mandatory security baselines
Platform Container for shared platform service subscriptions Platform-specific policies; less restrictive on networking than Landing Zones
Management sub Log Analytics workspace, Azure Automation, Defender for Cloud, Update Management Centralised observability for all workloads
Identity sub Active Directory Domain Services VMs or Entra Domain Services Locked-down — limited to identity workloads only
Connectivity sub Hub VNet, Azure Firewall, VPN/ExpressRoute gateway, Azure DNS Private Resolver Central network inspection point — all Corp traffic routed through here
Corp Workloads that need corporate network connectivity (VNets peered to hub) Require VNet integration; internet egress via Firewall; on-prem reachable
Online Internet-facing applications that do NOT need corp network connectivity Direct internet access permitted; not peered to hub; isolated from corp data
Sandbox Developer experimentation — no production data, no hub peering Permissive policies; automatic expiry recommended; isolated from prod
Decommissioned Subscriptions in wind-down process before cancellation Deny-All Azure Policy — no new resources can be created

The Eight Design Areas of Azure Landing Zones

CAF defines eight design areas that every landing zone implementation must address. These are the architectural decisions you make before deploying a single workload. Skipping any of them creates debt that is painful to retrofit later.

# Design Area What it covers
1 Billing & Azure AD Tenant Enterprise Agreement or Microsoft Customer Agreement structure, billing accounts, enrollment accounts, tenant topology (single vs multiple tenants)
2 Identity & Access Management Microsoft Entra ID configuration, Privileged Identity Management, RBAC model, external identities, hybrid identity (Entra Connect), break-glass accounts
3 Resource Organisation Management group hierarchy design, subscription design and vending strategy, naming conventions, tagging strategy, resource group design
4 Network Topology & Connectivity Hub-spoke or Azure Virtual WAN topology, ExpressRoute/VPN connectivity to on-prem, DNS strategy (Azure Private DNS + DNS Resolver), NVA design, DDoS protection
5 Security Azure Policy security baselines, Microsoft Defender for Cloud plans, Key Vault for secrets management, network security (NSGs, Firewall policy), encryption requirements
6 Management Log Analytics workspace strategy, Azure Monitor alerts, backup policy, update management, change tracking, operational runbooks
7 Governance Azure Policy initiative strategy, RBAC governance model, tagging enforcement policy, cost governance, compliance reporting, policy exemption process
8 Platform Automation & DevOps Infrastructure as Code (Bicep/Terraform), CI/CD pipelines for platform changes, ALZ accelerator adoption, Azure Verified Modules, subscription vending pipeline
All eight design areas must be addressed Many organisations start with design areas 2, 3, and 4 (Identity, Resource Org, Networking) because they feel urgent — and defer design areas 6, 7, and 8 (Management, Governance, Automation). This is the most common landing zone antipattern. Governance and automation debt accumulates faster than technical debt and is significantly harder to retrofit across a running estate.

Subscription Vending Pattern

In an enterprise with dozens or hundreds of subscriptions, manual subscription creation becomes a significant bottleneck — and a source of governance debt. Every manually created subscription is potentially missing required policies, RBAC assignments, or networking configuration.

The problem with manual subscriptions

  • Slow — requires platform team involvement for every request
  • Inconsistent — whoever processes the request may skip steps
  • Creates governance debt — missing baseline policies, wrong management group placement, no networking bootstrap
  • Does not scale — at 50+ subscriptions, manual vending becomes a full-time job

Subscription vending solution

Subscription vending is an automated pipeline (GitHub Actions or Azure DevOps) that accepts a standardised subscription request, validates it, and creates a fully configured subscription automatically:

  1. Request: Workload team submits a request form (YAML/JSON or PR) specifying workload name, environment, cost centre, owner, network requirements, and compliance classification.
  2. Validation: Pipeline validates the request against governance rules (e.g. cost centre must exist, network CIDR must not overlap with existing ranges).
  3. Subscription creation: Pipeline creates the subscription via the Azure Management REST API or Azure Bicep/Terraform.
  4. Management group placement: Subscription is automatically moved into the correct management group (Corp or Online) based on request parameters.
  5. Baseline policy: Azure Policy assignments and RBAC assignments are applied automatically based on the management group and workload classification.
  6. Network bootstrap: A spoke VNet is created with the requested CIDR range, peered to the hub, and routed through the central firewall (for Corp subscriptions).
  7. Handoff: Workload team receives a PR merge confirmation and their subscription is ready to use within minutes.
Subscription vending is self-service within guardrails This is the key benefit. Workload teams are unblocked — they get their subscription quickly and can start deploying. But they cannot deviate from the platform's governance baseline, because the subscription is pre-configured with mandatory policies that the workload team cannot remove (they don't have Owner access at the management group level).

Policy Governance at Enterprise Scale

In a landing zone, Azure Policy is the primary mechanism for enforcing the governance baseline across all subscriptions. The key design principle is: most restrictive policies at the top, workload-specific refinements lower down.

Policy inheritance pattern

Assignment Scope Example Policies Rationale
Tenant Root MG Audit resources without mandatory tags; require HTTPS on storage accounts; audit public IP addresses; deploy Azure Monitor agent Universal baseline — applies to every subscription in the tenant without exception
Platform MG Allow specific resource types only (e.g. allow networking resources in Connectivity sub); restrict VM sizes Platform subscriptions have different requirements from workload subscriptions
Corp MG Require VNet integration for App Services; deny public endpoints for PaaS services; route all traffic through Firewall Corp workloads must integrate with hub networking — no direct internet egress
Online MG Allow public endpoints; require WAF on Application Gateway; deny VNet peering to Corp network Online workloads are internet-facing but must not bridge to corp network
Subscription level Workload-specific policies (e.g. for a PCI-DSS workload: deny non-encrypted storage) Fine-grained policies that apply only to specific workloads
Policy exemptions require justification Every policy exemption must have a documented business justification, an owner, and an expiry date. Ad-hoc exemptions without these attributes are the fastest way to erode the governance baseline. Treat exemptions like a security exception process — not a fast path around inconvenient rules.

ALZ IaC Accelerator and Azure Verified Modules

Building a landing zone from scratch — all the management groups, policies, subscriptions, hub networking, and automation pipelines — would take a platform team months. Microsoft and the community provide pre-built tooling to accelerate this:

Azure Landing Zone Accelerator

An open-source GitHub repository (Azure/ALZ-Bicep or the Terraform equivalent via Azure/terraform-azurerm-caf-enterprise-scale) that deploys the entire platform landing zone in one pass:

  • Complete management group hierarchy
  • All CAF-recommended Azure Policy definitions and initiatives
  • Platform subscriptions with baseline configuration
  • Hub networking (hub-spoke or Azure Virtual WAN)
  • CI/CD pipeline scaffolding for ongoing platform management

Azure Verified Modules (AVM)

Azure Verified Modules are Microsoft-maintained, tested, and version-controlled Bicep and Terraform modules for common Azure resources and patterns. They follow consistent coding standards and are updated when Azure APIs change.

  • Available at aka.ms/avm
  • Covers resource modules (individual services) and pattern modules (multi-resource architectures)
  • Microsoft commits to maintaining them — you are not responsible for keeping up with Azure API changes
  • Use AVM modules as the building blocks of your subscription vending pipeline and platform IaC instead of writing custom modules from scratch
Treat the landing zone as a product The landing zone codebase is not a one-time deployment artefact. It is an actively maintained product that receives updates as Azure services evolve, as new workload teams onboard with new requirements, and as your governance baseline matures. Assign a platform team with clear ownership. Plan for quarterly reviews of the policy baseline and semi-annual accelerator version upgrades.

Day-2 Operations: Running the Landing Zone

Deploying the landing zone is Day 1. Day-2 operations are the ongoing responsibilities of the platform team:

  • Policy drift detection: Monitor for policy compliance degradation. New resources may be non-compliant if a new policy was added after their creation — trigger remediation tasks.
  • New subscription vending: Process subscription requests from workload teams via the automated pipeline. Review CIDR allocations, workload classifications, and cost centre codes.
  • Networking changes: Add new VNet peerings, expand hub capacity, update Firewall policy rules as new workload types onboard.
  • Platform upgrades: Upgrade ALZ accelerator versions as Microsoft releases new features and policy updates. Test in a non-production management group first.
  • Governance reviews: Quarterly review of policy exemptions (revoke expired ones), RBAC assignments (remove stale service principals), and tag compliance (enforce new mandatory tags via Policy).
  • Cost governance: Review budget alerts, right-sizing recommendations, and reserved instance utilisation across the platform subscriptions.

Practical Implications for Enterprise Admins

If you are joining an enterprise Azure environment as an admin, here is how you orient yourself within the landing zone structure:

What to find out on Day 1

  • Which management group does your team's subscription live in? (Corp or Online? Why?)
  • What Azure Policy initiatives are applied to your subscription — and which ones are blocking deployments you need to make?
  • What does the hub networking provide? (Firewall inspection? On-prem connectivity? DNS resolution?) Which services are you required to route through it?
  • Who owns the platform team? What is the process to request a new subscription or a policy exemption?
  • Where is the Log Analytics workspace that your resources should send diagnostics to?

Common mistakes to avoid

Mistake Why it's a problem
Creating resources outside the landing zone (e.g. in a personal subscription) No governance baseline, no hub networking, no monitoring, not visible to the platform team — creates shadow IT
Requesting policy exemptions without business justification Erodes governance baseline; exemptions accumulate and are never reviewed; leaves compliance gaps
Creating ad-hoc subscriptions outside the vending pipeline Missing baseline policies, wrong management group placement, no networking bootstrap — creates governance debt for the platform team to clean up
Not tagging resources consistently with required tags Cost allocation breaks down; chargeback to business units becomes impossible; compliance reporting has gaps
Bypassing hub networking with direct internet egress Traffic not inspected by Firewall; no central logging; potential compliance violation for Corp workloads

Check Your Understanding

Click any option to see immediate feedback.

1. What is the difference between a Platform Landing Zone and an Application Landing Zone in the CAF reference architecture?

Platform Landing Zones host shared infrastructure — the connectivity hub, identity services, and management/monitoring tooling — used by ALL workloads. Application Landing Zones are subscription environments for individual workload teams with their own VNets peered to the platform hub. The distinction maps to the Platform and Landing Zones management groups in the hierarchy.

2. A workload team's Corp subscription cannot reach on-premises resources. Which platform subscription should contain the VPN/ExpressRoute gateway that provides this connectivity?

The Connectivity subscription hosts the hub VNet, Azure Firewall, VPN/ExpressRoute gateway, and DNS resolver. Centralising these in one subscription enables a single management point for all network traffic and inspection. Corp workload subscriptions have spoke VNets peered to the hub — they do not deploy their own gateways.

3. What does subscription vending automate, and why is it important at enterprise scale?

Subscription vending automates subscription creation, management group placement, baseline policy assignment, networking bootstrap, and RBAC. This ensures all new subscriptions are created consistently with governance guardrails, without manual intervention by the platform team — enabling self-service for workload teams while maintaining control.

4. In the CAF methodology, which phase is responsible for defining governance disciplines like Cost Management, Security, Identity, Resource Consistency, and Deployment Acceleration?

The CAF Govern phase defines baseline governance across the five disciplines: Cost Management, Security Baseline, Identity Baseline, Resource Consistency, and Deployment Acceleration. Critically, Govern is an ongoing discipline that runs in parallel with Adopt — not a one-time task. Governance evolves as cloud adoption matures.

5. What are Azure Verified Modules (AVM), and why should they be used for platform infrastructure instead of custom-written modules?

Azure Verified Modules (AVM) are Microsoft-maintained, tested Bicep and Terraform modules that follow best practices. Using them for platform infrastructure reduces custom code maintenance burden and ensures the modules are updated when Azure service APIs change — you benefit from Microsoft's maintenance investment instead of maintaining the equivalent logic yourself.

6. What happens to a subscription that is moved to the Decommissioned management group, and why?

The Decommissioned management group is where subscriptions go when their workloads are being shut down. A Deny-All Azure Policy is applied, preventing any new resource creation. The subscription is moved here before cancellation to quarantine it — preventing accidental deployments while the decommission process completes and existing resources are verified as safely removed.
Primary source for this lesson Azure Landing Zone Documentation — Microsoft Cloud Adoption Framework (Microsoft Learn)

Read the landing zone overview, the eight design areas, and the ALZ accelerator documentation. If you work in an enterprise environment, also read the subscription vending article and the Azure Verified Modules quickstart.

Questions for your teacher (the AI agent)
This lesson covered the conceptual architecture of landing zones. Deepen your understanding with these:
  • Walk me through what happens step-by-step when a new Corp workload subscription is vended — from request to first deployment.
  • What are the trade-offs between hub-spoke networking and Azure Virtual WAN in a landing zone? When would you choose each?
  • How does a platform team manage breaking changes to the ALZ accelerator across an estate that already has dozens of deployed subscriptions?
  • Design a management group hierarchy for a financial services firm with retail banking, investment banking, and shared IT — each with prod, staging, and dev environments.
Coming up: Lesson 25 — Azure Cost Management & FinOps The final lesson covers the financial dimension of Azure administration. You'll learn how to use Azure Cost Management to analyse and forecast spend, configure budgets and alerts, leverage Reserved Instances and Savings Plans for significant discounts, and implement FinOps practices for enterprise cost accountability.