A landing zone is the set of subscriptions, identity, networking, logging and guardrails that make later Azure work boring. If those pieces are missing, every project invents its own hub, its own DNS hack, and its own “temporary” exception that never expires.
The first release should be small enough to operate. Management groups that match how you actually approve spend. A hub that carries hybrid connectivity, DNS and shared services. Spoke patterns that application teams can copy. Central logging that security can query. Backup and key management with named owners. Policy that blocks the mistakes you have already made, not a thousand unused initiatives.
What does not belong in v1: a perfect CAF diagram, twenty management groups for an organisation with three application teams, and custom policy at a density nobody can explain. Over-governance is how landing zones stall. Under-governance is how you get public storage accounts and mystery peering.
Identity is the usual failure point. Hybrid Entra ID, privileged access, break-glass, and workload identities need a design before the first production subscription is used. Networking is the second: address space, ExpressRoute or VPN, private DNS, and outbound internet paths. Get those two right and most other Azure services become configuration rather than invention.
Treat the landing zone as a product with a backlog. Version it. Document the exceptions. Review them. North Ark’s landing-zone work is successful when an internal team can add a spoke without calling a consultant for every subnet.
All technical perspectives