CH02-02: Landing Zones and Governance Scope

Goal

The previous section introduced governance as a way to give teams freedom inside clear boundaries. This section explains one of the most important Azure patterns for making that repeatable: landing zones.

A landing zone is not a single Azure service. It is a prepared Azure environment where workloads can be deployed with agreed identity, access, policy, networking, monitoring, security, cost, and operational controls already in place.

The goal is to understand the operating model first. You do not need a full enterprise landing zone implementation yet. You need to know why landing zones exist, what decisions they prepare, and how they use Azure scopes.

The Problem Landing Zones Solve

Imagine every application team starts with an empty Azure subscription and makes its own decisions:

Which region should we use?
Who should have contributor access?
Should the database be private?
Where should logs go?
Which tags are required?
How should cost be reported?
Which security tools should be enabled?
How should the workload connect to shared networks or on-premises systems?

Each team may make reasonable local choices, but the organization can still end up with inconsistent environments. One team uses different tags. Another deploys production into the same subscription as test. Another forgets diagnostic settings. Another exposes a service publicly because the private networking pattern was unclear.

A landing zone turns repeated foundation decisions into a reusable path.

The most important idea is this:

A landing zone makes the governed path the default path.

What a Landing Zone Is

A landing zone is a prepared place for workloads to land.

It usually includes decisions about:

Identity and access.
Management group and subscription placement.
Network connectivity and segmentation.
Azure Policy assignments.
Monitoring and logging.
Security visibility.
Tags, budgets, and cost ownership.
Deployment and operational expectations.

Some organizations use a large enterprise landing zone model with many management groups, platform subscriptions, policies, and shared services. Smaller teams may use a simpler version with only a few subscriptions and a small set of required controls. The size can change, but the purpose stays the same: prepare the foundation so workload teams do not rebuild governance from scratch.

A Simple Landing Zone Structure

A common enterprise pattern separates platform services from workload landing zones:

Microsoft Entra Tenant
  |
  +-- Management Group: Platform
  |   |
  |   +-- Subscription: Connectivity
  |   +-- Subscription: Management
  |   +-- Subscription: Security
  |
  +-- Management Group: Landing Zones
      |
      +-- Subscription: Finance Production
      +-- Subscription: Finance Non-Production
      +-- Subscription: Retail Production
      +-- Subscription: Retail Non-Production

This diagram is simplified, but it shows the important separation.

Platform subscriptions hold shared services that support many workloads. Connectivity might include shared networking and hybrid connectivity. Management might include monitoring and operational tooling. Security might include security posture, investigation, or central logging services.

Workload subscriptions hold application systems owned by business units, product teams, or application teams. Production and non-production are often separated because they have different access rules, policy strictness, cost expectations, and operational risk.

Chapter 3 will go deeper into networking. For this section, the key point is that landing zones prepare the place where networking, security, monitoring, cost, and access decisions can be applied consistently.

Platform and Workload Landing Zones

The word landing zone can be used in two related ways.

A platform landing zone is the shared foundation. It supports many workloads. It may include shared connectivity, central monitoring, security visibility, identity-supporting services, policy assignments, and automation used to create or manage subscriptions.

An application or workload landing zone is the prepared environment where a specific workload team deploys its application, data, integration, or AI resources. It inherits organizational controls and then adds workload-specific design.

The distinction matters because the ownership is different.

Area	Typical Owner	Main Responsibility
Platform landing zone	Platform, cloud foundation, or infrastructure team	Provide shared controls, connectivity, monitoring, and repeatable subscription patterns.
Workload landing zone	Application, product, or business-unit team	Deploy and operate workload resources inside the prepared boundaries.
Security oversight	Security or risk team	Define security requirements, inspect posture, and respond to risk signals.
Financial oversight	Finance, platform, or business owner	Track cost by subscription, tag, product, business unit, or environment.

The platform team should not have to design every application. The application team should not have to invent the whole cloud foundation. Landing zones help each team own the right layer.

Landing Zone Decision Map

The table below shows common landing zone decisions and the Azure controls that often support them.

Decision Area	Example Question	Common Azure Control
Identity and access	Which groups can deploy, operate, or inspect workloads?	Microsoft Entra ID groups and Azure RBAC.
Policy	Which regions, resource types, tags, and security settings are allowed or required?	Azure Policy.
Networking	How does the workload connect privately and safely?	Virtual networks, private endpoints, route tables, firewall patterns, and hybrid connectivity.
Monitoring	Where do logs, metrics, and alerts go?	Azure Monitor, Log Analytics workspaces, alert rules, and diagnostic settings.
Cost ownership	Who pays for this workload and environment?	Tags, budgets, subscription boundaries, and cost reports.
Security evidence	How can central teams see risk and compliance posture?	Policy compliance, security posture tools, logs, and activity records.
Deployment	How should workloads be created consistently?	Infrastructure as code, templates, pipelines, and approved modules.

Do not worry if some of these names are still new. The purpose of the table is to show that a landing zone is not one control. It is a collection of prepared decisions.

How Scope Supports Landing Zones

Landing zones depend on scope.

Management groups are useful for broad rules. For example, all production workload subscriptions can inherit a policy initiative that requires approved regions, required tags, and diagnostic settings.

Subscriptions are useful for major boundaries. A finance production subscription can have stricter access than a finance development subscription. A shared connectivity subscription can be managed by the platform team instead of an application team.

Resource groups are useful for workload components. A product team might have one resource group for application hosting, another for data services, and another for observability resources if those components have different deployment or operational needs.

Resources still need service-specific design. A policy can require diagnostics, but the team still needs to choose useful alerts. A subscription can separate production, but the team still needs to design backup, recovery, identity, and network access for each service.

This is why inherited governance is helpful but not enough by itself. Landing zones prepare the foundation. Workload architecture still matters.

Example: Onboarding a Payments Workload

Imagine a payments team needs a new Azure environment.

Without a landing zone, the team might ask for a subscription and then start discovering requirements one by one. Security asks for private access. Finance asks for cost tags. Operations asks for logs. Platform asks which network pattern is being used. Compliance asks whether the workload is in an approved region.

With a landing zone, the path is clearer:

The workload receives separate production and non-production subscriptions.
Those subscriptions are placed under the correct management group.
Required policies are inherited automatically.
Microsoft Entra groups are assigned the right Azure RBAC roles.
Tags and budgets are required from the beginning.
Network connectivity follows an approved pattern.
Logs and security signals flow to agreed monitoring locations.

The payments team still designs the application. It still chooses compute, data, messaging, resilience, and deployment patterns. But the foundation is no longer a blank page.

A Smaller Team Version

Landing zones are not only for global enterprises.

A smaller organization might use a simple model:

Management Group: Product Workloads
  |
  +-- Subscription: Shared Platform
  +-- Subscription: Production
  +-- Subscription: Non-Production

This model can still include useful governance:

A small set of required tags.
Separate production and non-production access.
A standard logging destination.
Approved regions.
Cost budgets and alerts.
A simple network pattern.

The lesson is not that every organization needs a complex management group tree. The lesson is that every organization needs a repeatable way to prepare workload environments.

Common Mistakes

Treating a landing zone as a one-time setup task. A landing zone is part of the operating model. Policies, access, networking, and monitoring need ongoing ownership.
Building one giant shared subscription for every workload. This can make access, cost, quotas, compliance, and operational responsibility difficult to separate.
Making the landing zone too restrictive. If teams cannot deploy ordinary changes responsibly, the governance model will become a bottleneck.
Ignoring non-production. Development and test environments still need ownership, cost controls, policy, and cleanup.
Focusing only on networking. Networking is important, but landing zones also include identity, access, policy, monitoring, security, cost, and operations.
Copying a large enterprise model without adapting it. A smaller organization may need the same principles in a simpler shape.
Assuming the landing zone replaces workload design. The foundation helps, but each workload still needs its own architecture decisions.

If Someone Asks You

If someone asks, "What is an Azure landing zone?" a clear answer is:

An Azure landing zone is a prepared environment where workloads can be deployed with common controls already in place. It usually includes decisions about subscription placement, identity, access, policy, networking, monitoring, security, tagging, cost controls, and operational expectations. The point is to let teams deploy into a known foundation instead of rebuilding governance for every workload.

This answer avoids treating a landing zone as a product name. It explains the architecture purpose.

What You Should Remember

A landing zone is where cloud governance becomes reusable.

The most important idea is this:

A landing zone makes the default path the governed path.

It helps central teams define guardrails while giving workload teams a prepared place to build. The best landing zone is not the most complicated one. It is the one that makes safe, observable, accountable deployment the normal way teams work.

Questions to Check Your Understanding

Why is a landing zone more than a subscription?
What decisions should be prepared before a workload team starts deploying?
Why might platform and workload subscriptions be separated?
How does a landing zone support team autonomy?
What makes an enterprise landing zone different from a simple team landing zone?