Most landing zones don’t fail because people ignore governance.
They fail because governance shows up as a giant pile of policies with no clear purpose. Teams get blocked, exception requests pile up, and everyone learns the wrong lesson: “guardrails slow us down.”
Microsoft’s Cloud Adoption Framework (CAF) frames an Azure landing zone as the standardized way to set up and run Azure at scale, using a modular architecture where you apply controls consistently across subscriptions. It is a foundation for security, compliance, and operations, not a one-time deployment.
So, here’s my take: your day-one goal isn’t “maximum control.” It’s “minimum surprise.”
That means a small set of guardrails that do three things:
Prevent expensive mistakes
Create evidence for security and ops
Establish cost ownership early, before the invoice becomes a debate
This article is Azure-specific, and it stays anchored to CAF and Azure Landing Zones (ALZ).
First, place subscriptions like you mean it
Before policy, fix scope.
CAF’s ALZ model is built around management groups and repeatable patterns so you can apply controls by “workload type,” not by arguing over every subscription.
The standard archetypes you see in ALZ tailoring are:
Corp: workloads that need corporate or hybrid connectivity via shared services
Online: workloads that may be internet-facing and might not need a VNet
Sandbox: isolated testing and exploration with a less restrictive policy set
If you skip this and dump everything into one bucket, every policy conversation turns into a political fight.
The minimum viable guardrail set
I’m going to give you a policy pack that’s intentionally small. It maps cleanly to the ALZ idea of applying controls consistently across subscriptions, without trying to “solve governance” in one sprint.
How to read this
Audit = learn first, don’t break deployments
DeployIfNotExists / Modify = auto-configure a baseline
Deny = only after you’ve proven the rule won’t create chaos
Exemptions = always allowed, but always visible and time-bound
Microsoft’s ALZ reference includes a large set of policy assignments and initiatives across management groups. This is not that. This is the “minimum viable” slice you can start with and expand later.
MVP Guardrails (12 policies, opinionated scopes)
1) Region control (Root or intermediate root)
Goal: stop “oops, we deployed in a random geography”
Policy: Allowed locations
Effect: Audit → Deny
Why it’s MVP: Region sprawl creates security, data residency, and cost headaches fast.
Goal: every resource has an owner and a reason to exist
Policy pattern: Require tags like Owner, App, Env, CostCenter
Effect: Audit → Deny (with exemptions for edge services)
Extra credit: Use Modify policies to inherit tags from subscription/resource group where it makes sense.
This isn’t about reporting aesthetics. It’s about accountability.
3) Activity log export to a central destination (Tenant baseline, applied via MG)
Goal: one place to investigate “who changed what”
Policy pattern: Configure subscription activity logs to stream to a central Log Analytics workspace (or SIEM pipeline)
Effect: DeployIfNotExists
CAF repeatedly emphasizes landing zones as an operational foundation. No central logs means you’re running blind.
4) Resource diagnostic settings (Landing Zones MG, targeted to “core” services first)
Goal: create evidence and reduce incident time
Policy pattern: Deploy diagnostic settings to Log Analytics for a shortlist of services you actually operate (start small)
Effect: DeployIfNotExists
If you want a reference for the “big” version of this approach, ALZ policy initiatives and assignments are documented publicly.
5) Baseline alerts for platform subscriptions (Platform: Management / Connectivity / Identity MGs)
Goal: your platform should yell before it breaks
Policy pattern: Deploy Azure Monitor Baseline Alerts (AMBA) initiatives for platform areas
Effect: DeployIfNotExists
ALZ includes policy initiatives to deploy baseline alerts for areas like management and connectivity.
6) Block public IP creation where it doesn’t belong (Corp MG, sometimes Identity MG too)
Goal: kill accidental exposure
Policy pattern: Deny public IP resources (or at least audit them first)
Effect: Audit → Deny (Corp), Audit-only (Online until you’re ready)
ALZ includes a built-in deny pattern for public IP creation in certain scopes.
7) Block inbound management ports from the internet (Corp + Identity MGs)
Goal: no NSG rules exposing RDP/SSH to the world
Policy pattern: Deny NSG rules that allow management ports from the Internet
Effect: Deny (after you’ve validated exceptions)
ALZ documents a custom policy approach for blocking management port access from the internet.
8) Require NSGs on subnets (Corp MG)
Goal: prevent “flat networks by accident”
Policy pattern: Deny subnet creation without an NSG
Effect: Deny (Corp)
This is another guardrail pattern present in ALZ policy assignments.
9) Sandbox still logs (Sandbox MG)
Goal: keep experimentation, keep auditability
Policy pattern: At minimum, enable audit logging (activity + key diagnostics) to a central destination
Effect: DeployIfNotExists (but keep Sandbox less restrictive overall)
CAF explicitly calls out audit logging for sandbox subscriptions and centralizing those logs.
10) SKU / tier restrictions where it matters (Landing Zones MG, selective)
Goal: prevent surprise bills from premium tiers
Policy pattern: Restrict a short list of “foot-gun” SKUs (example: high-cost database tiers)
Effect: Audit → Deny
Do not go broad here on day one. Pick 3–5 SKUs you’ve been burned by.
11) Encryption-in-transit baseline (Landing Zones MG, targeted)
Goal: avoid weak defaults on common services
Policy pattern: Enforce TLS minimums / HTTPS-only where applicable
Effect: Audit → DeployIfNotExists / Deny (service-dependent)
ALZ assigns initiatives around encryption-in-transit requirements across landing zones.
12) Built-in initiatives as your “bundle” mechanism (MG scopes)
Goal: make policy manageable as code
Policy pattern: Use initiatives (policy sets) rather than one-off assignments
Effect: N/A, this is structure
Microsoft maintains an index of built-in policy initiatives you can reuse instead of inventing everything from scratch.
Rollout rules so this doesn’t turn into a blockade
Start with Audit for 2–4 weeks (get real data, not opinions)
Flip only the “no-brainer Denies” first (public IP in Corp, management ports from internet)
Make exemptions boring: documented owner, reason, and expiry
Ship policy as code: treat changes like releases, not portal clicks
If you want an opinionated platform deployment path, Microsoft’s Landing Zones guidance lays out multiple approaches, including portal-based deployment and IaC paths (Bicep/Terraform), plus policy-at-scale options like EPAC.
The next 15 minutes
If you’re building or tightening a landing zone this week, do this:
Pick your archetype placement: Corp vs Online vs Sandbox
Write your tag minimum (4 tags is enough)
Choose your central log destination
Assign the MVP initiative at the Landing Zones parent MG
Turn on Audit and start collecting noncompliance data
Decide your first two Denies:
public IP creation in the Corp
management ports from the internet
This “operator-first” approach is core to how I write and build: clear scope, clear controls, and repeatable implementation.
Time to Act
If you want my MVP Landing Zone Guardrails Pack, CLICK HERE!
I’ll send:
A one-page “minimum viable policy set” checklist (scopes + effects)
A simple initiative layout you can mirror in Azure Policy as code
An exemption workflow template that doesn’t turn into an exception landfill
What management-group shape are you using right now (single “Landing Zones” parent, or already split into Corp/Online/Sandbox)?