Free tool · 5 minutes · Azure CAF
Most Australian Azure estates grew organically. Management groups missing, no central firewall, ad-hoc RBAC, no tagging policy. The Microsoft Cloud Adoption Framework reference is well-defined. Score your estate against it in five minutes — twelve questions, one PDF.
12 questions · 4 domains
Score your Azure estate against the Microsoft Cloud Adoption Framework reference landing zone. Pick the option closest to your current state.
Domain 1
Entra ID integration, management group hierarchy, RBAC at scale, and privileged identity management for Azure roles.
How are management groups structured?
Source: Microsoft Learn: Management group hierarchy — Azure Landing Zone design.
How is RBAC applied?
Source: Microsoft Learn: Azure RBAC best practices; CAF identity guidance.
Is PIM used for privileged Azure roles?
Source: Microsoft Learn: Privileged Identity Management for Azure resources.
Domain 2
Hub-and-spoke or virtual WAN, Azure Firewall vs NVA, private endpoints, DNS, and ExpressRoute or VPN connectivity.
What's the network topology?
Source: Microsoft Learn: Hub-spoke network topology — Azure Landing Zone.
Are Azure PaaS services accessed via private endpoints?
Source: Microsoft Learn: Azure Private Link; CAF network security.
How is DNS resolution handled across VNets?
Source: Microsoft Learn: Private DNS in hub-spoke topologies.
Domain 3
Azure Policy assignments, tag taxonomy, naming convention, Cost Management budgets, and FinOps cadence.
How is Azure Policy used?
Source: Microsoft Learn: Azure Policy — design guidance for landing zones.
Is there a tagging taxonomy applied consistently?
Source: Microsoft Learn: Resource naming and tagging — CAF.
How is cost managed?
Source: Microsoft Learn: Azure Cost Management; FinOps Foundation framework.
Domain 4
Defender for Cloud plans, Sentinel coverage, Azure Monitor + Log Analytics, security baselines, and incident response.
What Defender for Cloud plans are enabled?
Source: Microsoft Learn: Defender for Cloud — landing zone configuration.
How is Microsoft Sentinel deployed?
Source: Microsoft Learn: Microsoft Sentinel deployment best practices.
How is the landing zone deployed and maintained?
Source: Microsoft Learn: Azure Landing Zones Bicep / Terraform accelerator.
Indicative self-assessment only. For a verified result Frontrow Technology runs an in-tenant Azure Landing Zone audit using Azure Resource Graph, Azure Policy compliance reports, and architecture review against the CAF reference.
What the checker covers
Domain 1
Azure Landing Zone identity covers four things: how Entra ID is integrated (cloud-only, hybrid, federated), how management groups segment subscriptions (Microsoft's reference is a 4-tier hierarchy: Tenant Root → Top-level → Platform/Landing Zones → Workload), how RBAC is applied (built-in roles only or custom roles, group-based or per-user), and whether PIM gates privileged Azure roles. Most AU mid-market estates fail on management groups and PIM.
Domain 2
The Microsoft reference is a hub-and-spoke topology (or Virtual WAN for larger estates) with a central connectivity hub containing Azure Firewall, ExpressRoute or VPN gateway, private DNS zones, and Bastion. Spokes are workload landing zones peered to the hub. Most ad-hoc AU Azure estates skip the hub and let each workload have its own NSG-and-internet-egress pattern — fine at 10 subscriptions, fails at 50.
Domain 3
Governance is policy-as-code (Azure Policy assigned at management group scope, deny-non-compliant for resource SKUs and locations), tagging taxonomy enforced via policy (cost-centre, environment, owner, data classification), naming convention applied to every resource, and Cost Management budgets with alert thresholds at the subscription and resource group level. FinOps practice (monthly cost review with engineering and finance) is the human layer on top.
Domain 4
Security baseline is Defender for Cloud enabled across every subscription with the appropriate plans (Servers, App Service, SQL, Storage, Containers, Key Vault), Sentinel ingesting Azure Activity, Defender for Cloud alerts and Entra ID logs, Azure Policy deploying Defender automatically to new subscriptions, and a documented incident response runbook. The Microsoft Security Baseline (formerly Azure Security Benchmark, now Cloud Security Benchmark) maps each control.
Frequently asked questions
An Azure Landing Zone is Microsoft's reference architecture for production-ready Azure subscriptions, defined inside the Cloud Adoption Framework (CAF). It covers identity and access management, network topology and connectivity, governance and policy, security baseline, and operational management. The reference implementation is published as Microsoft Enterprise-scale Landing Zones, available as Bicep and Terraform accelerators.
Four domains drawn from the CAF reference: identity and access management (management groups, RBAC, PIM), network topology and connectivity (hub-spoke, firewall, private endpoints, DNS), governance and cost (Azure Policy, tagging, Cost Management, FinOps), and security baseline and operations (Defender for Cloud plans, Sentinel coverage, IaC). 12 questions, four-tier scoring per domain (Initial / Developing / Defined / Optimised).
Anyone running 10+ Azure subscriptions in production. Below that, you're typically running a small Azure estate that doesn't yet need the full CAF reference. Above 50 subscriptions, this assessment is the cheapest baseline before deciding on a full enterprise-scale landing zone uplift.
Cloud Adoption Framework (CAF) is the platform layer — how the Azure estate itself is structured (subscriptions, management groups, network, governance). Well-Architected Framework (WAF) is the workload layer — how individual applications running on top of the platform are designed for reliability, security, cost, operational excellence and performance. CAF gives you the landing zone; WAF gives you the workload design pattern.
Partially. The principles apply at every scale but the implementation effort doesn't pay back below roughly 10 production subscriptions. For small estates, focus on the highest-leverage items: management groups (even a 2-tier hierarchy), Defender for Cloud paid plans, tagging taxonomy, and PIM on Owner/Contributor. Skip the full hub-and-spoke topology until network egress consolidation becomes an actual cost or security driver.
Sentinel sits in the management subscription of the landing zone, ingesting logs from Azure Activity, Entra ID sign-ins, Defender XDR, Office 365 audit, and any workload-specific data sources. Microsoft's reference deploys Sentinel as part of the platform landing zone, not per workload. Cost typically scales with Defender XDR log volume more than with workload count.
Three phases over 8–12 weeks for a typical AU mid-market estate of 50–150 subscriptions. Phase 1 (weeks 1–4): management group hierarchy, RBAC consolidation, Azure Policy baseline, tagging taxonomy. Phase 2 (weeks 4–8): hub-and-spoke network topology, central firewall, private endpoints, DNS centralisation. Phase 3 (weeks 8–12): Defender for Cloud full coverage, Sentinel deployment, IaC migration of the new landing zone. Existing workloads migrate progressively into the new structure.
Every scoring threshold cites a primary source: Microsoft Learn Cloud Adoption Framework — Enterprise-scale design areas, the Microsoft Well-Architected Framework, and the Microsoft Cloud Security Benchmark. The methodology is authored by Daniel Brown (5x Microsoft MVP), Graeme Lodge (Managing Director), and Sam Williams (Investor & Executive Consultant).
