Enterprise Lab: Implement an Azure Landing Zone
An Azure landing zone is the governed environment in which workloads can be onboarded repeatedly. This lab designs a management-group hierarchy, platform subscriptions, policies, central connectivity and monitoring, security controls, and subscription vending. It is an architecture and controlled implementation exercise—not a command to restructure a live tenant without executive and platform approval.
Time: several days for a realistic proof of concept · Cost: firewall, gateways, Virtual WAN, DDoS, logs, Defender, and private networking can be significant · Use: a dedicated test tenant or sandbox hierarchy.
Method note: This lab combines executive decisions, tenant hierarchy, policy, networking, subscription vending, and failure tests in one controlled program. Use the method tabs in the governance, networking, and delivery chapters for each deployable component; there is no safe one-click equivalent for the complete landing-zone exercise.
What is the target structure?
Rendering diagram...
Keep the proof of concept scoped. If you cannot create subscriptions, use existing test subscriptions and still validate placement, policy, access, networking, and monitoring.
Phase 1: Discovery and decisions
Document:
- Tenant/billing ownership and subscription creation process.
- Identity model, emergency access, privileged access, and group ownership.
- Region/data-residency rules.
- Network topology and hybrid needs.
- Central logging/SIEM, Defender plans, retention, and cost.
- Required/forbidden services, public exposure, tags, and encryption.
- Workload classes and exceptions.
- RACI and support model.
Use the Azure Landing Zones accelerator and reference implementation rather than designing hierarchy from memory.
Phase 2: Platform code
Create versioned Bicep/Terraform modules for:
- Management groups and subscription placement.
- Custom policy definitions/initiatives and assignments.
- Platform role assignments to Entra groups.
- Management workspace, automation, and diagnostic policy.
- Connectivity hub/Virtual WAN, firewall policy, DNS resolver, DDoS as required.
- Defender/Sentinel configuration.
- Budgets, tags, and ownership metadata.
Preview at each scope. Start policy in audit. Test platform changes in a canary management group/subscription.
Phase 3: Subscription vending
A request should collect workload, owner, cost center, environment, criticality, data classification, regions, connectivity, and expiry. Automation then:
- Creates/selects and places the subscription.
- Assigns platform and workload groups.
- Connects the network and DNS.
- Applies policy and Defender/monitoring baseline.
- Creates budget and tags.
- Delivers an empty application landing zone with documentation.
The vending identity should not grant requesters Owner by default. Use group-based roles and PIM where available.
Phase 4: Onboard Northstar
Deploy a small private App Service or Container Apps API, storage, Key Vault, and monitoring into a vended workload subscription. Prove:
- Required tags/diagnostics are automatically applied or denied.
- Public storage is blocked.
- App identity can read only its own approved storage/vault data.
- Private DNS resolves through hub/spoke/hybrid paths.
- Logs reach central monitoring and security teams.
- Workload team can deploy within its scope but cannot change platform policy/firewall.
- Budget and cost allocation appear correctly.
Phase 5: Failure and exception tests
- Request a disallowed region/SKU and confirm useful denial.
- Create a time-bound policy exemption with compensating control.
- Simulate hub/DNS/logging failure in a safe lab.
- Restore a workload resource from backup.
- Offboard the subscription and remove access/network/DNS cleanly.
Acceptance criteria
- All platform state is reproducible and reviewed.
- No personal identity is a permanent platform dependency.
- Emergency access is tested and monitored.
- Workload onboarding is repeatable with measured lead time.
- Policy compliance and exemptions have owners.
- Network routes/DNS and failure behavior are documented.
- Security/monitoring data arrives with controlled cost.
- The platform has SLOs, on-call, runbooks, and an upgrade process.
Official references