When I first started working with Azure at scale, I assumed the hard part was learning all the services.
It wasn’t.
The hard part was realizing most environments aren’t actually designed—they’re assembled over time.
I’ve seen environments where one early decision ended up forcing months of rework later. Not because Azure is complicated—but because nobody defined the platform up front.
An Azure landing zone isn’t where you deploy applications.
It’s the system that decides how everything else gets deployed.
The Problem
Terraform is usually one of the first things teams introduce when they start getting serious about Azure.
It brings consistency, repeatability, and version control.
But it doesn’t solve the actual problem.
Teams often start writing Terraform before they’ve decided how the platform should be structured. Over time, the Terraform codebase becomes the architecture.
Terraform is doing exactly what it’s told.
The issue is using it before the platform is clearly defined.
What Most Engineers Run Into
- Things start at the resource group level because it’s quick
- Platform and application resources get mixed together
- Different teams solve the same problem differently
- DNS and identity get revisited multiple times
- Logging gets added after something breaks
What an Azure Landing Zone Actually Is
A landing zone defines how control, access, and connectivity are applied across your environment.
- Management group hierarchy
- Subscription structure
- Governance through policy
- RBAC boundaries
- Networking approach
- Logging and security baseline
Management Group Structure (Example)
Tenant Root
├── Platform
│ ├── Management
│ ├── Connectivity
│ └── Identity
├── Landing Zones
│ ├── Corp
│ ├── Online
│ └── Sandbox
└── Decommissioned
This isn’t just about organizing subscriptions.
This is how governance and access are actually applied across your environment.
Management groups are where you assign:
– Azure Policy (what is allowed, denied, or required)
– RBAC roles (who can do what, and where)
And those assignments flow downward.
If you assign something at the Platform level, everything underneath inherits it.
That’s what allows you to define governance once and apply it consistently.
It also means structure matters.
If things are grouped incorrectly, policies and permissions won’t behave the way you expect.
And once workloads are deployed, fixing that becomes much harder.
How Terraform Fits Into This
Terraform is most effective when it codifies decisions that have already been made.
- Management groups
- Policy assignments
- RBAC roles
- Networking baseline
- Shared services
- Logging configuration
A Real-World Scenario
A team I worked with started deploying workloads early to meet delivery timelines.
At first, everything looked fine.
They had applications running, Terraform pipelines in place, and environments stood up quickly. Each team moved independently and solved problems as they came up.
Then the platform started to grow.
That’s when they began introducing:
- Azure Policy to enforce standards
- private endpoints to reduce public exposure
- tighter network controls for compliance
And that’s where the friction showed up.
Some services were reachable from one VNet but not another.
Private endpoints worked in one environment but failed in another because DNS wasn’t consistent.
Policies started blocking deployments that had previously worked, depending on where they were applied.
What made it harder was that none of this was centralized.
- Networking decisions had been made differently across subscriptions
- DNS zones were created in multiple places with no clear ownership
- Policies were assigned at different scopes with overlapping effects
So instead of a single fix, it turned into coordination across multiple teams.
Fixing it required:
- redesigning how VNets were connected
- consolidating and standardizing private DNS
- rethinking where policies should be assigned
- aligning teams on a shared deployment pattern
None of the individual components were broken.
They just weren’t designed to work together from the start.
And by the time those issues surfaced, there were already workloads depending on the existing setup—which made every change more sensitive and harder to implement.
The issue wasn’t Azure.
It was that the platform design came after the platform was already in use.
Private Endpoints: Where This Shows Up Fast
Private endpoints depend on DNS consistency, network design, and clear ownership.
- Resolution issues
- Inconsistent connectivity
- Manual fixes across environments
A Practical Landing Zone Layout
- Management (logging, monitoring)
- Connectivity (networking, firewall, DNS)
- Identity (shared identity services)
- Shared services
- Workloads (applications)
What You Should Do
- Define management group structure early
- Separate platform and workloads
- Define policy and access early
- Design networking and DNS intentionally
- Use Terraform to enforce design
- Keep things modular
- Test before rollout
Final Thoughts
I’ve seen teams spend months improving environments that were built in weeks.
Not because the tools failed—but because the design had to catch up.
An Azure landing zone isn’t a template.
It’s a foundation.
So what comes next?
We start at the top.
In the next article, we’ll walk through management group design and how it shapes everything underneath it.
.