A landing zone you can’t apply yourself is just someone else’s repo
A landing zone is only real if your team can operate it without the people who built it. The test is concrete — can an engineer who wasn’t in the original engagement clone the repo and vend a new account, inheriting every guardrail, role, and logging default, without a call to the consultant? If the answer is no, you didn’t buy a foundation; you rented a dependency.
Most landing-zone engagements are sold and reviewed on the strength of a diagram: the org structure, the OUs, the network topology, the logging fan-in. The diagram is the easy part. The part that decides whether you got value is invisible in any slide: can your team run it?
The only acceptance test that matters
Forget the architecture review for a second and run this test instead. Pick an engineer who was not part of the build. Hand them the repo. Ask them to vend account #51 — a brand-new account that comes up inside every guardrail, with the baseline roles, the SCPs, the logging, the network scaffolding, all applied automatically.
If they can do it from the repo and a README in an afternoon, you own a landing zone. If they have to reverse-engineer click-ops, or open a ticket with whoever built it, you own a diagram and a dependency.
Why so many “landing zones” fail this test
- Console drift. The diagram says one thing; half of it was clicked in by hand during delivery and never made it back into code. The repo can’t reproduce the environment because the environment was never fully in the repo.
- Bespoke platforms. A consultant builds a clever custom abstraction only they understand. It demos well and is unmaintainable the moment they leave. A foundation should be boring: standard Terraform/OpenTofu, your CI, cloud-native controls.
- No account-vending pattern. The first few accounts were built lovingly by hand. There is no repeatable “vend” path, so account #51 is as much work as account #2 — which is exactly the problem you hired out to solve.
What “you own it” has to mean in practice
Ownership is not a license clause; it’s an operational fact. Concretely:
- The org and account structure is Terraform in your version control, in your accounts.
- There is an account-vending module your team runs to create accounts that inherit the baseline by default.
- Guardrails (SCPs / org policies) are code you can read, change, and PR.
- The handover isn’t a presentation — it’s your team vending a real account, changing a guardrail, and running break-glass, while we watch and then leave.
That last point is the whole game. The handover phase exists to prove the dependency is gone. If a landing-zone engagement doesn’t end with your own engineers operating it unaided, it didn’t end — it just paused until the next invoice.
This is why every Landing Zone engagement we run ends in that live operate-it-yourself handover. The deliverable is your team’s independence, not our diagram.