Final Reference Implementation

This page brings the series together into one coherent target architecture: the minimum viable platform for a small-to-medium organization, how it matures over time, and the order that makes deployment practical rather than overwhelming.

Purpose

This is the reference the rest of the series builds toward. It shows the full target architecture, the sequence to deploy it in, the difference between a minimal and a mature landing zone, and a final checklist to validate the platform before serious workloads arrive.

Design Reasoning

A good reference implementation does not mean deploying everything at once. It means making deliberate decisions in the right order. For a small-to-medium organization the starting point should be small but not weak:

Clear management group hierarchy
Platform subscriptions
Group-based RBAC
Critical Azure Policies
Central logging
Network and DNS foundation
Security baseline
Infrastructure as Code pipeline
Documented workload onboarding process

Maturity comes later — through product lines, refined PIM, custom policies, advanced monitoring, security integrations, and more automated self-service.

Architecture Decision Record

Decision	Choice	Rationale
Implementation order	Platform contract before serious workloads	Once workloads run, corrections to RBAC, DNS, diagnostics, and ownership become much harder.
Starting posture	Minimal viable landing zone, then iterate	A small but complete foundation is operable immediately and matures without re-architecting.

Tradeoff: Building the platform first delays the first workload. Retrofitting the platform under live workloads costs far more — in change windows, risk, and trust — than the delay it avoids.

Target Architecture

flowchart TD
A[Tenant root] --> B[contoso]
B --> C[platform]
B --> D[landing-zones]
B --> E[sandbox]
B --> F[decommissioned]
C --> C1[identity subscription]
C --> C2[management subscription]
C --> C3[connectivity subscription]
C2 --> M1[Log Analytics]
C2 --> M2[Alerts and action groups]
C2 --> M3[Defender and security reporting]
C3 --> N1[Hub VNet or Virtual WAN]
C3 --> N2[Azure Firewall or controlled egress]
C3 --> N3[Private DNS and resolver]
C3 --> N4[VPN or ExpressRoute where required]
D --> D1[corp]
D --> D2[online]
D1 --> W1[production workload subscription]
D1 --> W2[non-production workload subscription]
D2 --> W3[online workload subscription]

Target architecture: management groups, platform subscriptions, and application landing zones

The architecture combines every baseline from the series: the management group hierarchy for inheritance; platform subscriptions for connectivity, management, and identity; application landing zones under corp and online archetypes; a connectivity baseline (hub, egress, DNS); a monitoring baseline (central workspace, alerts); a security baseline (Defender, Key Vault RBAC, managed identities); a policy baseline (locations, tags, public access, diagnostics); and an automation baseline (IaC with review gates).

Recommended Deployment Sequence

Phase	Implement
First	Management group hierarchy, platform subscriptions, Entra groups, tenant-wide critical guardrails
Second	Management subscription with central logging and alerts; connectivity baseline with DNS planning
Third	Policy baseline hardening, Defender baseline, naming and tagging automation
Fourth	Subscription vending and workload onboarding workflow
Later	Product lines, refined PIM, custom policies, optional Sentinel, advanced operations

Minimal Viable Landing Zone vs Mature Landing Zone

Area	Minimal viable landing zone	Mature landing zone
Management groups	platform, landing-zones, sandbox, decommissioned	Additional archetypes and regulatory scopes where justified
Subscriptions	Connectivity, management, at least one production and non-production workload	Multiple product lines, optional identity or security subscriptions
RBAC	Groups and least privilege	PIM for groups, refined delegation, access reviews
Policy	Locations, tags, resource types, storage public access, diagnostics	Fine-grained initiatives, exemption workflow, custom policies
Networking	Hub-spoke, private DNS zones, NAT or firewall as required	Multi-region hubs or Virtual WAN, advanced segmentation
Monitoring	One central workspace, Activity Logs, resource logs, baseline alerts	Workbooks, retention tiers, SIEM or SOC integration
IaC	Bicep or Terraform with a clear repository structure	Azure Verified Modules, mature CI/CD, guardrailed self-service

Validation Steps

1
# Hierarchy and access
2
az account management-group entities list
3
az role assignment list --all --output table
4

5
# Governance compliance summary (policyinsights extension)
6
az policy state summarize --management-group contoso
7

8
# Monitoring and networking foundations
9
az monitor log-analytics workspace list --output table
10
az network private-dns zone list --output table

Final Validation Checklist

Management group hierarchy deployed, with a default group for new subscriptions
Platform subscriptions (connectivity, management, optional identity) in place
Group-based RBAC; no direct user assignments; PIM for privileged roles
Critical Azure Policies enforced (locations, tags, public access, diagnostics)
Central Log Analytics workspace receiving Activity Logs and resource logs
Network and DNS foundation with a private endpoint DNS plan
Defender for Cloud enabled; Key Vault on RBAC; managed identities in use
Platform deployed via IaC with what-if / plan review gates
Documented workload onboarding process and subscription vending

Scope and limitations

This series is optimized for a small-to-medium organization starting from a clean tenant. It does not fully cover complex multinational scenarios, sovereignty-specific designs, country-specific regulated hierarchies, dedicated SOC or Sentinel architecture, advanced multi-region networking, or workload-specific accelerators (AKS, AVD, AI). For those, create separate architecture decision records per country, tenant, platform type, or regulated workload category.

Common Mistakes

The recommendation is simple: implement the platform contract before onboarding serious workloads. Once workloads are running, the most common — and most expensive — late fixes are the RBAC group structure, DNS for private endpoints, missing diagnostic settings, unclear subscription ownership, inconsistent policy exemptions, and the absence of central visibility. Design and validate these early.

Before publishing or adopting this as your own platform reference, replace placeholder names such as contoso, confirm your preferred region naming, validate every CLI command against your installed Azure CLI version, confirm which policies are built-in versus custom, and decide whether Bicep or Terraform is your primary implementation path.