The Miniature Landing Zone

Plate I proved you can build a workload. This one proves something rarer and better paid: that you can build the ground the workloads stand on before anyone deploys one. The brief is the platform team's, not the app team's: "Set up the environment so that a dozen future applications land in a place that is already governed — spending capped, regions constrained, logs centralised, access defined, and the network segmented — without any of them having to think about it." This is platform engineering, and it is the difference between an engineer who fills a subscription and one who designs the estate the subscriptions live in.

Microsoft has a name and a blueprint for this: the Azure landing zone, from the Cloud Adoption Framework. It is organised around eight design areas and a standard management-group hierarchy, and this Plate is a deliberately miniature version — every design area represented at the smallest honest scale, so the shape is complete even though the estate is small.¹

Deliverable

One public GitHub repository: the management-group hierarchy, the hub-and-spoke network, the deny policies, the central logging, and the access model — all as code — plus a README that maps each piece to its Cloud Adoption Framework design area and defends the miniaturisation.

Each row is a landing-zone design area at portfolio scale, the classes that taught it, and the evidence a reviewer will demand. Governance is built top-down: the hierarchy first, then the rules that flow down it.

Governance is code, or it is folklore.

Two boundaries. Miniaturise honestly: the enterprise landing zone separates platform subscriptions for connectivity, identity, and management, adds Azure Firewall in the hub, a bastion, and DDoS protection, and often runs dozens of application landing zones — each a README paragraph under "what enterprise scale adds." But keep every design area present: a landing zone missing its governance policies or its centralised logging is not a small landing zone, it is a subscription with ambitions. The tell of this Plate is completeness of shape, not size of estate.

Like Plate I, this is marked against the Well-Architected Framework's five pillars — but a landing zone weights them differently: its whole purpose is operational excellence and security for other people's workloads, so those two carry the most.

Operational excellenceWAF pillar · weighted

The entire estate is code, deploys from a pipeline, and a new platform engineer could stand it up from the repository. Governance you cannot reproduce is a rumour; this pillar is where a landing zone lives or dies.

SecurityWAF pillar · weighted

Deny policies enforce the guardrails, the network is segmented hub-to-spoke, access is least-privilege and written down, and no workload can be born ungoverned. The security is structural, not behavioural.

ReliabilityWAF pillar

The shared services the spokes depend on — resolution, logging — are designed to survive a component failure, and the estate rebuilds from code if a subscription is lost.

Cost optimisationWAF pillar

The guardrails themselves control cost: allowed-regions stops egress surprises, required-tags makes every dollar attributable, and a budget could attach to any scope. Governance that pays for itself.

Performance efficiencyWAF pillar

The platform imposes no bottleneck on the workloads that land in it — the hub is sized for its shared services, and the topology scales to more spokes without redesign.

The capping deduction fits the Plate's thesis: a policy in audit mode where the brief asked for deny, or a guardrail a workload could bypass, fails the Security pillar — because a landing zone whose rules are optional is exactly the folklore it was built to replace. Governance that does not bind is decoration.

This Plate signals the senior track, so the questions probe judgement about scale and blast radius, not syntax.

"Why a hierarchy instead of one subscription with good habits?"

Because a rule set at the management group inherits to every subscription beneath it, now and every one created next year — governance becomes a property of the estate, not a discipline each team must remember. Habits drift; inheritance does not.

"Walk me through your management-group design."

Root, then a platform group for shared services and a landing-zones group for workloads — the Cloud Adoption Framework shape, miniaturised. Naming the platform-versus-application split is the phrase that tells an interviewer you have read the blueprint, not guessed at it.

"Deny or audit — and why?"

Deny for the guardrails the business cannot cross — regions, tags — because a landing zone exists to make the wrong thing impossible, not merely visible. Audit is for the things you are still measuring before you enforce. Knowing which is which is the governance judgement itself.

"How does a new application land here safely?"

It gets a subscription or resource group under the landing-zones group, inherits the policies and the diagnostic-settings automation the moment it is created, peers into the hub for shared services, and is governed before its first resource exists. Being born governed is the whole product.

"What did you leave out, and what would enterprise scale add?"

Your miniaturisation note: separate platform subscriptions, Azure Firewall and a bastion in the hub, DDoS, many application landing zones. Drawing the line between your version and the full one, unprompted, is the platform-thinking tell the whole Plate exists to demonstrate.