Azure landing zones, deployed from code

The Azure assessment is mostly about structure and sequencing, because the accelerator solves the build and not the decisions.

• Tenant and hierarchy review. Existing management groups, subscriptions and any inherited assignments, plus whether a single platform landing zone genuinely fits your tenant situation.
• Policy baseline classified. Each definition marked enforce, audit or out of scope, with remediation feasibility assessed for anything using deployIfNotExists or modify.
• Bicep or Terraform decision. Made against existing team skill and the pattern modules you actually need, and recorded as a decision because the whole platform follows it.
• Network topology sized honestly. Hub and spoke against Virtual WAN judged on your real sites, regions and routing needs rather than defaulting to the managed option.
• Log Analytics workspace design. Retention, residency and access requirements checked before logs flow, because the retention bill and any sovereignty constraint both arrive late.
• Australian region verification. Capability availability confirmed in Australia East and Australia Southeast with the date recorded, since parity with other geographies is not guaranteed.

We follow the published accelerator sequence: plan, prerequisites, bootstrap, then run. The bootstrap phase is the one under pressure to be skipped, and it is the one that decides whether you can change the platform later.

• Hierarchy and platform subscriptions first. Management groups established with dedicated identity, management and connectivity subscriptions before any application landing zone is created.
• Assembled from Azure Verified Modules. The platform built from published Bicep or Terraform modules, including the landing zone vending pattern, rather than equivalents written from scratch.
• Pipeline bootstrapped before the platform runs. Version control, service connections and deployment identities established first, so the platform has never existed outside a pipeline.
• Connectivity centralised. Central egress inspection, private circuit termination and shared name resolution in the connectivity subscription, consumed by application landing zones.
• Diagnostics applied by policy. Diagnostic settings deployed through policy rather than per resource, so a new resource cannot silently avoid central logging.
• Locks on shared platform services. Resource locks protecting the shared components whose accidental deletion would affect every workload underneath them.

Most of what a landing zone is for lives here. On Azure the controls are largely available already, and the work is attaching them to the hierarchy deliberately and proving inheritance holds.

• Entra ID groups for every assignment. Role assignments granted to groups at management group or subscription scope, never to individuals, so access follows joiner and leaver processes.
• Privileged access time-bound. Standing administrative access removed in favour of eligible, approved and audited elevation for platform-level roles.
• Defender for Cloud as the baseline. Enabled across every subscription in the hierarchy by policy, reporting against one agreed standard rather than per-subscription defaults.
• Sentinel over central platform logs. Analytics and response sitting in the management or security subscription, reading the platform logs workload teams cannot alter.
• Exemptions scoped and dated. Policy exemptions recorded against a named approver with a review date, rather than widened assignment scopes that disable a control invisibly.
• Tag enforcement for attribution. Mandatory tags applied and inherited through policy effects, so cost attribution works without a monthly reconciliation exercise.

The measure of adoption here is whether application teams use the vending path. If it is slower than opening the portal, they will not.

• Vending faster than the portal. The governed request path timed against manual creation, because a slow pipeline means the control gets bypassed.
• Platform team handover on the real thing. Sessions run against the deployed hierarchy, pipeline and vending workflow rather than a slide deck describing them.
• Application landing zone pattern published. What a team receives by default, what they must not change, and how to request something the baseline forbids.
• Exemption path rehearsed. Walked through with a genuinely blocked deployment before go-live, so the process is tested before it is needed.
• Decision records handed over. One record per structural choice covering hierarchy, topology and the Bicep or Terraform decision, with the reasoning kept.
• Runbooks for predictable work. Onboarding a subscription, adding a region, opening a network path, and responding to a failed policy remediation.

Azure landing zones drift through portal changes and fall behind through skipped module updates. Continuation is mostly about catching both early enough that the fix is small.

• Drift surfaced against the deployed baseline. Out-of-band portal changes detected and routed to a named owner, with repeat offenders treated as a process problem rather than a technical one.
• Module and accelerator currency. Upstream Azure Verified Modules and accelerator releases assessed and taken through the pipeline on an agreed cadence.
• Compliance reviewed by someone who reads it. Results triaged to separate genuine control failures from scope and definition artefacts before anything is escalated.
• Remediation tasks completed. Partially applied deployIfNotExists and modify remediations chased to completion, since half-remediated is a common and misleading end state.
• Log retention and cost watched. Workspace ingestion and retention reported monthly, because this is the platform line item that grows quietly.
• Exemption register reviewed. Each exemption revisited at its review date and either renewed deliberately or removed.