The Terraform exists. Someone cloned it, ran terraform apply with their own credentials, fixed the error, ran it again, and the landing zone was born. Then: a policy tweak applied through the portal “just for now.” A firewall rule added during an incident. A management group moved by hand to unblock a project.
Twelve months later the repository is a historical document. The truth lives in the portal, and the only person who knows the full story is on leave, or has left for a Sydney role, as NZ engineers do.
Why Landing Zones Drift Faster Than Workloads
A workload app changes when its team deploys. A landing zone changes when anything changes: Microsoft updates policy definitions, security requirements shift after an incident, a new NZISM control needs implementation, cost pressure demands a SKU change. High frequency change plus manual deployment equals drift, guaranteed.
And in NZ, the small team problem bites twice: with one or two people holding the operational knowledge, their departure is a continuity incident. IaC discipline is your institutional memory.
The Maturity Path (Pragmatically Ordered)
You do not need everything on day one. You need these, roughly in this order:
1. Everything through a pipeline, including the first deployment
No exceptions, including “temporary” portal fixes. If a change happens in the portal, it is a change request against the repo, even during an incident (apply in the portal if you must, but immediately codify it, make “the repo describes reality” a hard rule with named enforcement).
2. State and identity hygiene
Remote state with locking, least privilege deployment identities (workload identity federation or managed identity, not a human’s account), and separation of platform repo access from workload repos.
3. Environment strategy for the platform itself
Test platform changes in a non production management group or a dedicated test subscription before production. Yes, this costs a small amount of Azure spend. It costs far less than a broken deny policy locking out production pipelines on a Friday afternoon.
4. Policy as code with validation
- Policies versioned in the same repo, deployed through the pipeline
- Static analysis (
tfsec/checkov/PSRule) on the platform code itself, eating your own cooking - A PSRule or policy test harness that catches “this policy change would break vending” before merge
5. Release discipline
Semantic versioning of platform releases, a changelog workload teams can read, and communicated deprecations. Your workload teams are your customers; breaking changes without notice is how platform adoption dies quietly.
6. Drift detection
Scheduled pipeline runs in detection only mode that flag when reality no longer matches the repo. In a small team, automated drift detection is your audit function between reviews.
The NZ Continuity Angle
Concretely: document the “bus number” for the platform. Which repo, which pipeline, which identity, which order to run things. Store it where the next person will find it. In a market where senior engineers are routinely recruited offshore, the platform that survives a key departure is the one where the repo, not a person, holds the truth.
The test:
git clone, follow the README, and you can reproduce the platform’s deployment path without asking anyone. If that fails, the repo is a monument, not a source of truth.
One Block · build from here