This chapter covers Azure Landing Zone (ALZ) design, a critical topic for the AZ-305 exam. You will learn the architectural principles, key components, and implementation strategies for building a secure, scalable, and well-governed cloud foundation. Approximately 10-15% of AZ-305 questions touch on landing zone design, governance, and management group hierarchy. Mastering this chapter is essential for the 'Design identity, governance, and monitoring solutions' domain.
Jump to a section
Designing an Azure Landing Zone is like creating a city's master plan before any building is constructed. The city planner (cloud architect) defines zones: residential (workloads), commercial (shared services), industrial (management), and green spaces (security controls). Each zone has specific rules—building codes (Azure Policy), zoning laws (RBAC), utility connections (networking), and emergency access (monitoring). The city's infrastructure, like roads (virtual networks) and water pipes (DNS), must support future growth without tearing up streets. Without a master plan, you get chaotic sprawl: buildings too close, inadequate roads, and fire trucks that can't reach certain areas. The Azure Landing Zone ensures consistent governance, secure connectivity, and scalable operations from day one. It's not just a design—it's the foundation that prevents costly rework and security gaps as the cloud footprint expands. Just as a city plan accounts for population growth, traffic patterns, and disaster response, a Landing Zone anticipates subscription limits, resource quotas, and regulatory compliance. The analogy holds mechanistically: the 'building permits' are Azure Policy assignments, the 'utility corridors' are hub-and-spoke network topologies, and the 'city ordinances' are management groups with RBAC inheritance. Without this blueprint, each workload team builds its own 'house' without coordination, leading to overlapping IP ranges, ungoverned resource groups, and a tangled mess that IT cannot manage at scale.
What is an Azure Landing Zone?
An Azure Landing Zone is the foundation of a cloud environment that provides the core set of building blocks—networking, identity, security, and management—before any workloads are deployed. It is not a single service but a design pattern codified by the Microsoft Cloud Adoption Framework (CAF). The ALZ ensures that new subscriptions are provisioned with consistent policies, network connectivity, and monitoring. Without it, organizations face 'subscription sprawl,' ungoverned resources, and security blind spots.
Why Landing Zones Exist
Enterprises migrating to Azure quickly realize that raw subscriptions are not ready for production. Without a landing zone, each team creates their own virtual networks, often overlapping IP ranges, and applies inconsistent policies. The ALZ solves this by providing a 'golden template' for subscriptions, ensuring every new environment is born compliant. Key drivers include: - Governance: Enforce corporate policies via Azure Policy and RBAC at scale. - Security: Centralized network security with hub-and-spoke topology and forced tunneling. - Operations: Consistent monitoring, logging, and cost management. - Scale: Support for multiple subscriptions, regions, and teams without manual configuration.
Core Components of an Azure Landing Zone
#### Management Group Hierarchy Management groups organize subscriptions into a tree structure for policy and RBAC inheritance. The ALZ defines a standard hierarchy:
- Root management group (tenant root group) - Intermediate groups for different functions (e.g., Platform, Landing Zones, Sandbox) - Platform group contains subgroups for Management, Connectivity, and Identity. - Landing Zones group contains subgroups for Corp (production workloads) and Online (internet-facing workloads). - Sandbox group for experimentation. This structure allows policies applied at higher levels to flow down to all subscriptions, ensuring baseline compliance.
#### Subscription Organization Subscriptions are placed into management groups based on their purpose. The ALZ recommends a minimum of four subscriptions: - Management: Hosts Log Analytics workspaces, Automation Accounts, and Azure Monitor. - Connectivity: Hosts Azure Firewall, VPN Gateway, ExpressRoute Gateway, and DNS. - Identity: Hosts Active Directory Domain Services (if needed) and Azure AD. - Landing Zones: One or more subscriptions for actual workloads, separated by environment (dev, test, prod) or business unit.
#### Networking Topology The ALZ uses a hub-and-spoke model: - Hub (Connectivity subscription): Central network with shared services (firewall, gateway, DNS). - Spokes (Landing Zone subscriptions): Workload virtual networks peered to the hub. - Forced Tunneling: All internet-bound traffic is routed through the hub firewall for inspection. - Private DNS Zones: Centralized DNS resolution for private endpoints (e.g., Azure Private Link). - Virtual WAN: Optionally used instead of hub-and-spoke for global connectivity.
#### Identity and Access Management - Azure AD: Central identity provider for users and workloads. - RBAC: Fine-grained role assignments at management group, subscription, or resource group scope. - Azure Policy: Built-in policies enforce rules like 'Allowed locations,' 'Deny public IPs,' and 'Require tags.' - Custom Policies: For organization-specific requirements.
#### Management and Monitoring - Log Analytics Workspace: Centralized log collection from all subscriptions. - Azure Monitor: Alerts, dashboards, and action groups. - Automation Accounts: Runbooks for remediation tasks. - Update Management: Patch compliance for VMs. - Azure Security Center: Security posture management and threat detection.
How It Works Internally
When a new subscription is created and placed under the 'Corp' management group, the following happens automatically via Azure Policy: 1. Policy Inheritance: All policies assigned at the 'Corp' group are inherited by the subscription and its resource groups. 2. Network Peering: A script (Azure Blueprint or Terraform) establishes VNet peering between the new spoke VNet and the hub VNet. 3. Route Tables: User-defined routes (UDRs) are configured to force traffic through the hub firewall. 4. DNS Configuration: The spoke VNet uses the hub's custom DNS servers or Azure Private DNS zones. 5. Diagnostic Settings: All resources are configured to send logs and metrics to the central Log Analytics workspace. 6. RBAC: The subscription gets standard role assignments (e.g., 'Network Contributor' for the hub team, 'Owner' for the workload team).
Key Parameters and Defaults
Management Group Depth: Up to 6 levels (including root).
Subscription Limits: Default 50 per management group, can be increased to 980.
VNet Peering: Requires non-overlapping address spaces; Azure supports up to 500 peerings per VNet.
Azure Policy: Maximum 30,000 policies across a tenant; 200 per scope.
Log Analytics Workspace: Retention default 30 days for free tier, up to 730 days for paid.
RBAC: Maximum 4,000 role assignments per subscription.
Configuration Example
Using Azure CLI, you can create a management group hierarchy:
az account management-group create --name Platform --display-name "Platform"
az account management-group create --name LandingZones --display-name "Landing Zones"
az account management-group create --name Corp --display-name "Corp" --parent LandingZones
az account management-group create --name Online --display-name "Online" --parent LandingZones
az account management-group create --name Sandbox --display-name "Sandbox"Then assign a policy at the root:
az policy assignment create --name "AllowedLocations" --policy /providers/Microsoft.Authorization/policyDefinitions/... --scope /providers/Microsoft.Management/managementGroups/rootInteraction with Related Technologies
Azure Blueprints: Deprecated in favor of deployment stacks and policies; previously used to orchestrate landing zone creation.
Terraform/ARM/Bicep: Infrastructure as code tools to deploy landing zone resources.
Azure DevOps: CI/CD pipelines to automate landing zone deployment and policy updates.
Azure Firewall Manager: Central management of firewall policies across hub-and-spoke.
Azure Virtual WAN: Alternative to hub-and-spoke for global networks with integrated SD-WAN capabilities.
Common Pitfalls
Overlapping IP Addresses: Spoke VNets must not overlap with each other or the hub.
Missing Policies: Without 'Deny' policies, users can create resources outside allowed regions.
Insufficient Monitoring: Not configuring diagnostic settings for all resources leads to blind spots.
RBAC Overlap: Assigning multiple roles with conflicting permissions can cause unexpected access.
Best Practices
Start with the Azure Landing Zone Accelerator (ARM templates or Terraform modules).
Use management groups for logical separation, not just subscriptions.
Implement a 'Deny' policy for public IPs on spoke VNets.
Centralize all logging to a single Log Analytics workspace for cross-subscription queries.
Use Azure Policy initiatives to group related policies.
Regularly review policy compliance and remediate non-compliant resources.
Plan for subscription growth; design address spaces with room for expansion.
Define Management Group Hierarchy
Start by creating a management group hierarchy that mirrors your organizational structure. The CAF recommends a flat hierarchy with Platform, Landing Zones, and Sandbox under the root. Platform contains Management, Connectivity, and Identity subgroups. Landing Zones contains Corp and Online subgroups. Each group inherits policies and RBAC from its parent. Use Azure CLI or portal to create groups. Ensure the root group is not renamed. This structure enables policy inheritance and delegation at scale.
Create Core Subscriptions
Provision four subscriptions: Management, Connectivity, Identity, and at least one Landing Zone. Place each into the appropriate management group. The Management subscription hosts Log Analytics, Automation, and monitoring resources. Connectivity hosts networking shared services. Identity hosts AD DS if needed. Landing Zone subscriptions host workloads. Use separate subscriptions for dev/test/prod to isolate environments. This separation ensures that policies and RBAC can be applied granularly.
Deploy Hub Network Resources
In the Connectivity subscription, create a hub virtual network with subnets for Azure Firewall, VPN Gateway, ExpressRoute Gateway, and Azure Bastion. Deploy Azure Firewall with forced tunneling enabled. Configure DNS servers (Azure DNS or custom). Create a route table with a default route (0.0.0.0/0) pointing to the firewall's private IP. Associate the route table with the gateway subnet. Deploy VPN or ExpressRoute gateway for hybrid connectivity.
Configure Spoke VNets and Peering
In each Landing Zone subscription, create a spoke virtual network with a non-overlapping address space. Establish VNet peering with the hub VNet. Configure 'Use remote gateway' on the spoke side and 'Allow gateway transit' on the hub side. Create route tables in the spoke subnets with a default route to the hub firewall. Optionally, use Azure Firewall Manager to propagate rules. Ensure that spoke-to-spoke traffic flows through the hub for inspection.
Apply Azure Policy and RBAC
Assign built-in policies at the appropriate management group scope. Common policies: 'Allowed locations' (restrict regions), 'Deny public IP addresses' (prevent public exposure), 'Require tags' (cost tracking), 'Deploy Log Analytics agent' (monitoring). Create custom policies as needed. Use Azure Policy initiatives to group policies. Assign RBAC roles at management group scope for central teams (e.g., 'Network Contributor' for connectivity team) and at subscription scope for workload owners.
Configure Central Monitoring
Deploy a Log Analytics workspace in the Management subscription. Configure diagnostic settings for all Azure resources (VMs, storage, databases, etc.) to send logs to this workspace. Enable Azure Monitor for VMs and containers. Set up alerts for critical conditions (e.g., firewall health, CPU usage). Use Azure Workbooks for dashboards. Enable Azure Security Center (now Defender for Cloud) for security posture. This centralizes logging and monitoring across all subscriptions.
Scenario 1: Large Enterprise Migration
A financial services company with 50,000 employees migrates 500 applications to Azure. They use the Azure Landing Zone Accelerator to deploy a hub-and-spoke topology with three regions (US East, US West, Europe). The hub in each region contains Azure Firewall Premium, ExpressRoute gateways, and a shared DNS solution. Each application team gets a spoke subscription under 'Corp' management group. Policies enforce that only specific VM SKUs are allowed and all storage accounts must have encryption enabled. Central IT manages policies, while application teams have 'Contributor' role on their subscriptions. The challenge is IP address planning: they use /16 for hub and /20 for each spoke, with a central IPAM tool to prevent overlap. Performance is monitored via a single Log Analytics workspace collecting 2 TB of logs daily. Misconfiguration occurs when a team creates a VNet without peering to the hub, bypassing forced tunneling. This is caught by a 'Deny' policy that requires VNet peering, and the resource is automatically remediated via an Azure Automation runbook.
Scenario 2: SaaS Startup Scaling
A SaaS startup on Azure starts with a single subscription and manually managed resources. As they grow to 200 microservices, they face governance issues: developers create resources in random regions, IP addresses overlap, and security audits fail. They adopt the Azure Landing Zone using Terraform. They create three management groups: 'Platform', 'Workloads', and 'Sandbox'. Under 'Workloads', each environment (dev, test, prod) gets a separate subscription. They use Azure Firewall Manager to centralize firewall policies. A policy initiative called 'Security Baseline' includes 20 policies (encryption, logging, network security). The startup faces a common issue: the Log Analytics workspace reaches its 500 MB/day free data ingestion limit, causing log loss. They upgrade to a paid tier and set daily caps. They also learn that VNet peering is not transitive, so they must use a hub for all spoke-to-spoke traffic.
Scenario 3: Healthcare Compliance
A healthcare provider must comply with HIPAA and GDPR. They deploy an Azure Landing Zone with a dedicated management group for 'Compliance'. All subscriptions under this group inherit policies that enforce encryption at rest and in transit, audit logging for all data access, and restrict data residency to specific Azure regions. They use Azure Policy for 'Allowed locations' (only US regions) and 'Deny public endpoints' for PaaS services. They also deploy Azure Private Link and Private DNS Zones for all PaaS services to avoid public exposure. The central networking team manages the hub and firewall, while each department has a spoke subscription. A frequent issue is that developers accidentally disable diagnostic settings, breaking compliance. They use Azure Policy with 'DeployIfNotExists' effect to automatically enable diagnostics. The provider also uses Azure Blueprints to deploy landing zones with pre-configured compliance controls, though they are migrating to deployment stacks.
What AZ-305 Tests
Objective 1.2: 'Design identity governance and management for Azure resources.' This includes designing a management group hierarchy, subscription strategy, and Azure Policy assignments. Also Objective 1.3: 'Design a landing zone for cloud governance.' The exam expects you to know the CAF recommended structure, policy effects, and RBAC inheritance. Common question types: 'Which management group structure is recommended?' 'How many subscriptions are needed?' 'What policy effect prevents resource creation in non-approved regions?'
Most Common Wrong Answers
'Place all subscriptions under a single management group.' Wrong because it bypasses policy inheritance granularity. The correct answer is to use a hierarchy with Platform, Landing Zones, and Sandbox.
'Use Azure Policy at subscription scope only.' Wrong because policies at management group scope inherit to all child subscriptions, reducing duplication.
'Create one VNet per subscription and peer them all together.' Wrong because this creates a mesh that is hard to manage; hub-and-spoke is recommended.
'Landing Zone is a single Azure service.' Wrong; it's a design pattern, not a service.
Key Numbers and Terms
Management groups: Up to 6 levels deep, 10,000 groups per tenant.
Subscriptions: 50 per management group default, can increase to 980.
Policy effects: Deny, Audit, Append, DeployIfNotExists, Modify.
RBAC: Built-in roles like 'Network Contributor', 'Security Admin'.
Hub-and-spoke: Forced tunneling via UDR with 0.0.0.0/0 to firewall.
Log Analytics: Default retention 30 days (free), 730 days (paid).
Edge Cases
Multiple tenants: ALZ is per tenant; cross-tenant scenarios require separate landing zones.
Azure Virtual WAN: Alternative to hub-and-spoke; exam may ask which to choose for global connectivity.
Policy exemptions: Can be granted at child scope, but must be justified.
Subscription move: Moving subscriptions between management groups may cause policy conflicts; plan carefully.
Eliminating Wrong Answers
Focus on the core principle: landing zones are about governance and scale. If an answer suggests manual configuration per subscription, it's wrong. If it lacks policy inheritance, it's wrong. If it doesn't include central networking, it's wrong. The correct answer always aligns with CAF best practices.
Azure Landing Zone is a design pattern, not a service; it enforces governance and consistency across subscriptions.
The CAF recommends a management group hierarchy: Root -> Platform, Landing Zones, Sandbox -> subgroups.
Minimum four subscriptions: Management, Connectivity, Identity, and at least one Landing Zone.
Hub-and-spoke networking with forced tunneling through Azure Firewall is the standard topology.
Azure Policy at management group scope ensures inheritance and reduces duplication.
Log Analytics workspace centralizes monitoring; retention default is 30 days (free) and up to 730 days (paid).
VNet peering is not transitive; all inter-spoke traffic must go through the hub.
Azure Policy effects: Deny (block), Audit (warn), Append (add tags), DeployIfNotExists (auto-deploy), Modify (alter resource).
Management groups support up to 6 levels deep and 10,000 groups per tenant.
Use the Azure Landing Zone Accelerator (ARM/Terraform) for quick deployment.
These come up on the exam all the time. Here's how to tell them apart.
Hub-and-Spoke Network Topology
Central hub VNet with Azure Firewall and gateways.
Requires manual VNet peering between hub and each spoke.
Limited to a single region per hub; multiple hubs for multi-region.
Fine-grained control over routing with UDRs and firewall rules.
Lower cost for small to medium deployments.
Azure Virtual WAN
Managed global network with Microsoft backbone.
Automated spoke connectivity via Virtual Hub connections.
Native multi-region support with inter-hub routing.
Simplified routing with built-in route tables and security policies.
Higher cost but reduces operational overhead for large deployments.
Azure Blueprints (Deprecated)
Orchestrated deployment of resource groups, policies, and RBAC.
Versioned artifacts with assignments.
Deprecated as of July 2024; no new features.
Limited to subscription-level deployment.
Required manual updates for drift.
Deployment Stacks + Azure Policy
Declarative deployment of resources at management group or subscription scope.
Drift detection and remediation via Azure Policy.
Active development; recommended replacement for Blueprints.
Supports management group-level deployment.
Integrates with Bicep and Terraform.
Mistake
Azure Landing Zone is a specific Azure service like Azure Firewall.
Correct
It is a design pattern and a set of best practices, not a service. Microsoft provides the 'Azure Landing Zone Accelerator' which is a collection of ARM templates and Terraform modules to implement the pattern.
Mistake
You need at least one subscription per workload.
Correct
The CAF recommends starting with a minimum of four subscriptions (Management, Connectivity, Identity, and Landing Zones), but workloads can share a subscription as long as they are isolated via resource groups and RBAC. Subscriptions are a scale and boundary unit, not a per-workload requirement.
Mistake
Azure Policy can only be applied at the subscription or resource group scope.
Correct
Azure Policy can also be applied at management group scope, which is the recommended approach for landing zones to ensure inheritance and consistency across multiple subscriptions.
Mistake
VNet peering is transitive, so you can peer spokes directly to each other.
Correct
VNet peering is not transitive. If you peer Spoke A to Hub and Spoke B to Hub, Spoke A cannot directly communicate with Spoke B unless traffic goes through the hub (or you create extra peerings). Hub-and-spoke forces all inter-spoke traffic through the hub firewall.
Mistake
Once a landing zone is deployed, it never needs to change.
Correct
Landing zones must evolve as the organization grows. You may need to add new management groups, update policies, expand IP space, or adopt new services like Virtual WAN. Treat the landing zone as a living design.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The CAF recommends a minimum of four subscriptions: Management, Connectivity, Identity, and at least one Landing Zone. However, you may need more for dev/test/prod separation or multiple business units. The key is to have separate subscriptions for shared services (management, connectivity, identity) and workloads.
Use Azure Policy with the 'Allowed locations' policy definition. Assign it at the root management group or a high-level group to enforce region restrictions across all subscriptions. Use the 'Deny' effect to block creation of resources outside allowed regions. You can also use 'Audit' to log non-compliant resources.
Yes, Azure Firewall Manager is designed to manage firewall policies across hub-and-spoke topologies. It allows you to centrally create and enforce firewall rules, route settings, and security policies for multiple Azure Firewall instances. It also integrates with Virtual WAN.
Azure Policy evaluates and enforces rules on resource properties (e.g., location, tags, SKU) during creation and updates. RBAC controls who can perform actions on resources (e.g., read, write, delete). Policy is about 'what is allowed' (compliance), while RBAC is about 'who can do what' (access). Both are used in landing zones for governance.
For multi-region deployments, you can deploy a hub VNet in each region and peer them together. Alternatively, use Azure Virtual WAN which provides a global mesh. For policy, apply region-specific policies at the appropriate management group (e.g., 'Allowed locations' per region). For monitoring, use a single Log Analytics workspace per region or a central workspace with data collection rules.
The subscription inherits the policies and RBAC of the new management group. Existing resources are evaluated against the new policies; they may become non-compliant if they violate new policies. Azure Policy has a 'remediation' task to fix non-compliant resources. Plan subscription moves carefully to avoid compliance gaps.
No, Azure Blueprints is deprecated as of July 2024. Microsoft recommends using deployment stacks (with Bicep/ARM) and Azure Policy for new deployments. Existing Blueprints will continue to work but will not receive updates. The Azure Landing Zone Accelerator now uses deployment stacks.
You've just covered Azure Landing Zone Design — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?