The four environment and four compliance design areas of the Cloud Adoption Framework, what each one decides, and which team usually owns it.
From Azure Landing Zones (Ultra Transcenders: Beyond the Exam) by Tony Rough (coming December 2026)
The Azure landing zone guidance splits its design areas into two groups: four that shape the foundation and four that keep it secure, governed and operable.
The environment design areas are Azure billing and the Microsoft Entra tenant, identity and access management, resource organisation, and network topology and connectivity. Learn says their decisions affect “the platform foundation on which each landing zone depends”, which is a polite way of saying they are expensive to change later.
The compliance design areas are security, management, governance, and platform automation and DevOps. They establish the controls and tooling that keep the estate compliant, and Learn names them as the focus for iterative refinement: new workloads bring new requirements, and a new compliance standard can arrive at any time.
| Letter(s) | Design area | Group | Objective as Learn states it | Chapter in this book |
|---|---|---|---|---|
| A | Azure billing and Microsoft Entra tenant | Environment | Tenant creation, enrolment and billing setup as early steps | Chapter 4: Billing and tenant |
| B | Identity and access management | Environment | The primary security boundary in the public cloud and the foundation for a secure, compliant architecture | Chapter 5: Identity and access for the platform |
| C | Resource organisation | Environment | Subscription design and management group hierarchy that shape governance, operations and adoption as you scale | Chapter 6: Resource organisation; Chapter 7: Subscription vending |
| E | Network topology and connectivity | Environment | Networking and connectivity as an equally foundational part of the architecture | Chapter 8: Network topology I: hub-spoke; Chapter 9: Network topology II: Virtual WAN, hybrid and DNS |
| F | Security | Compliance | Controls and processes to protect your cloud environments | Chapter 11: Security baseline |
| D, G, H | Management | Compliance | A baseline for visibility, operations compliance, and protect and recover capabilities | Chapter 12: Management baseline |
| C, D | Governance | Compliance | Automated auditing and enforcement of governance policies | Chapter 10: Governance at scale with Azure Policy |
| I | Platform automation and DevOps | Compliance | The right tools and templates to deploy landing zones and supporting resources | Chapter 13: Platform automation and DevOps |
The letters A to I come from the Azure landing zone reference architecture diagram. They mark where each design area’s concepts appear on the drawing, so the diagram doubles as a map of the decisions. The diagram’s own description labels D as the security and management subscriptions, E as connectivity, F and G as workload landing zone subscriptions and their resources, and H as the sandbox, which is why management touches three letters and governance shares C with resource organisation.
One naming oddity: the design-areas overview still labels area A “Azure billing and Active Directory tenant”, but the area page itself is now titled “Azure billing offers and Microsoft Entra tenants”. It concerns the Entra tenant your subscriptions trust, not Windows Server Active Directory, which belongs to the identity area.
Common pitfall: Reading the A-to-I letters as the order in which to work through the design areas - the letters label places on the reference diagram, several areas share letters, and the sensible order (covered later in this chapter) follows dependencies, not the alphabet.
This note is one section of Azure Landing Zones: Building an Azure Foundation with the Cloud Adoption Framework, an independent guide in the Ultra Transcenders Beyond the Exam series, with comparison tables, diagrams, the common pitfalls and tested companion code, plus a glossary linked to Microsoft Learn.
Due on Amazon in December 2026, in Kindle and paperback editions.
About the book · Azure Landing Zones terms in the glossary · All free notes from Azure Landing Zones
What a first platform landing zone needs on day one, what can safely wait, and how to grow it without redesigning later.
The intermediate root, Platform, Landing zones, Sandboxes and Decommissioned groups: what each is for and why the hierarchy stays shallow.
What each Azure Firewall tier adds, where Basic stops being enough, and how to choose for a hub that many workloads share.
The factors that decide between a customer-managed hub and Azure Virtual WAN, and the constraints that can make the choice for you.
How central private DNS zones and DeployIfNotExists policy register private endpoint records automatically, and the permissions it needs.
When to use Audit, Deny, DeployIfNotExists, Modify and DenyAction in a landing zone, and what each commits you to.
How the two infrastructure-as-code options compare for deploying and running an Azure landing zone, and what decides the choice.