1. Enterprise Landing Zones: What & Why
A landing zone is a pre-configured Azure environment with identity, networking, security, and governance already wired up. Teams deploy workloads into landing zones without reinventing foundational controls each time.
- Consistency – every workload inherits the same guardrails
- Speed – new teams are productive in hours, not weeks
- Compliance – policies enforce standards from day one
- Scalability – supports hundreds of subscriptions via automation
2. Azure Landing Zone Conceptual Architecture (CAF)
Platform landing zones host shared infrastructure; application landing zones host business workloads with delegated ownership.
3. Management Group Hierarchy Design
- Max depth = 6 levels (Azure limit); CAF recommends 3–4
- Assign policies/RBAC at the highest applicable MG level
- Never modify the Tenant Root Group directly in production
4. Subscription Vending
Subscription vending automates creating new subscriptions with built-in guardrails—like a vending machine that dispenses pre-configured environments.
- Triggered by a service request or CI/CD pipeline
- Creates a subscription, places it under the correct MG
- Assigns budget alerts, policies, and RBAC roles automatically
- Deploys baseline networking (spoke VNet peered to hub)
- Registers with management tooling (Defender, Log Analytics)
Microsoft provides a subscription-vending Bicep/Terraform module in the ALZ reference implementations.
5. Landing Zone Accelerators
Accelerators are opinionated IaC deployments of the full landing zone architecture:
- Azure Landing Zone (Bicep) – modular Bicep modules, CI/CD ready
- Azure Landing Zone (Terraform) – uses
caf-enterprise-scalemodule - Portal-based – Deploy via Azure Portal wizard (great for PoC)
All accelerators deploy: MG hierarchy, policies, hub networking, logging, and RBAC baseline.
6. Policy-Driven Governance by MG Level
| MG Level | Example Policies |
|---|---|
| Intermediate Root | Allowed locations, diagnostic settings to central Log Analytics, deny public IP on NICs |
| Platform → Connectivity | Enforce NSG on subnets, deny UDRs overriding firewall route |
| Landing Zones | Require resource tags, enforce TLS 1.2, enable Defender for Cloud |
| Landing Zones → Corp | Deny public endpoints on PaaS (private link only) |
| Landing Zones → Online | Require WAF on Application Gateway |
| Sandboxes | Budget cap, deny peering to prod, no ExpressRoute |
Policies inherit downward; assign broad controls high and specific controls at child MGs.
7. Network Topology Choices in Landing Zones
Hub-Spoke (Traditional)
- Azure Firewall or NVA in hub VNet
- VNet peering from each spoke
- Full control over routing/NVAs
- Best for single-region or few regions
- Lower cost at small scale
Virtual WAN (Microsoft-managed)
- Microsoft-managed hub routing
- Automatic any-to-any connectivity
- Integrated SD-WAN partner support
- Best for multi-region / global orgs
- Higher base cost, less routing granularity
Decision guide: Choose Virtual WAN if >2 regions or many branch offices; choose hub-spoke for cost-sensitive single-region deployments or when you need custom NVAs.
8. Real-World Scenario
Enterprise Cloud Adoption with Landing Zone Accelerator
Situation: A financial services company with 300+ developers is migrating from on-premises to Azure. They need strict compliance (PCI-DSS), consistent environments, and fast onboarding of new teams.
Solution:
- Deployed ALZ Terraform accelerator to create MG hierarchy and policies
- Platform team owns Identity, Connectivity (ExpressRoute + Azure Firewall hub), and Management subscriptions
- Corp landing zone enforces private endpoints for all PaaS; Online landing zone mandates WAF
- Subscription vending pipeline creates new workload subs in <30 minutes with tags, budgets, spoke VNet, and Defender enabled
- Policy remediation tasks auto-deploy diagnostic settings when new resources are created
Result: New teams go from request to production-ready subscription in under an hour, with full compliance from day one.
Exam Tip
🎯 AZ-305 loves questions about where to assign policies in the MG hierarchy. Remember: broad/universal controls at the intermediate root MG, workload-specific controls at child MGs. Never assign at Tenant Root Group in production. Also know that subscription vending is the recommended pattern for scaling—not manually creating subscriptions.
Knowledge Check
Q1: In the CAF landing zone architecture, which MG contains shared hub networking and firewall resources?
Q2: What is subscription vending?
Q3: A policy that denies public endpoints on PaaS services should be assigned at which MG level?
Q4: When should you choose Virtual WAN over traditional hub-spoke?