Landing Zones That Don't Make You Cry

Most landing zone failures aren’t technical. They’re decisions deferred — naming conventions nobody agreed on, a management group hierarchy bolted on after the fact, identity that “we’ll sort out later.” Later never comes, and you spend the next year unpicking it.

Start with the boring decisions

Before a single workload lands, get agreement on:

1. Management group hierarchy — usually Platform, Landing Zones, Sandbox, Decommissioned.
2. Subscription topology — one per workload-environment is a sane default.
3. Naming and tagging — enforced by policy, not by hope.

Policy is your seatbelt

The whole point of a landing zone is that the guardrails exist before the car moves. Deny public IPs by default. Require a specific set of tags. Enforce allowed regions. You can always loosen a policy with an exemption; you can rarely claw back the sprawl that an absent one allowed.

targetScope = 'managementGroup'

resource denyPublicIp 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'deny-public-ip'
  properties: {
    policyDefinitionId: tenantResourceId(
      'Microsoft.Authorization/policyDefinitions',
      '...'
    )
    enforcementMode: 'Default'
  }
}

Treat the landing zone as a product, version it in Git, and ship changes through the same pipeline as everything else. Do that and the next migration is a config change — not a rescue mission.