Azure Policy vs Architecture Assessment: Configuration Enforcement Is Not Design Evidence
Azure Policy enforces per-resource configuration at runtime; an architecture assessment evaluates whole-system design. Why you need both, compared in detail. For platform leads.
Marc Dekeyser |
Azure Policy vs Architecture Assessment: Configuration Enforcement Is Not Design Evidence
Every policy in the estate is passing. The compliance dashboard is green. And the workload still sits in one region with no tested failover.
I see this on capable teams. They have a mature Azure Policy estate, everything enforced, and they read that green dashboard as proof the architecture is sound. It isn’t. A perfectly policy-compliant environment can still have a single point of failure, no tested recovery, and a Zero Trust gap that no policy was ever written to catch.
Two different questions are hiding behind that dashboard. Azure Policy asks “is this resource compliant right now?” An architecture assessment asks “is the design sound, and can I prove it?” One is a guardrail. The other is a review. You want both, and neither substitutes for the other.
What Azure Policy actually does
Azure Policy works resource by resource. You define a condition and an effect, Azure applies it across a scope, and it keeps checking. The effect can audit, deny, or remediate. A resource that drifts out of compliance gets flagged, and a non-compliant deployment can be blocked before it ever exists.
The everyday definitions tell you exactly what this is good at. Deny storage accounts with public blob access. Require a specific tag set on every resource. Restrict creation to an allowed list of regions. Enforce disk encryption. Deny public IPs on network interfaces. Each one is a per-resource rule with a yes-or-no answer, and that is the whole point — a rail that keeps every resource inside known-good boundaries.
Here’s what it can’t do. It doesn’t reason about how resources combine. There is no policy that understands “this workload has no failover region,” because that isn’t a property of any single resource. Policy sees resources. Not systems.
What an architecture assessment does
An assessment looks at the whole thing. How the components fit together, measured against the five pillars of the Microsoft Azure Well-Architected Framework — reliability, security, cost optimisation, operational excellence, and performance efficiency — plus Cloud Adoption Framework guidance for governance and landing-zone design.
The findings don’t look anything like policy results. A workload in a single region with no tested failover, and that’s a reliability finding. A recovery time objective stated on paper but never validated. An identity design where one compromised account reaches further than Zero Trust would allow. A cost structure where reserved capacity would move the bill in a way nobody costed. An operational model with no named owner for a dependency the whole thing rests on.
None of those has a yes-or-no answer. Each one is a judgment about the system.
Want one pillar in depth? See the Well-Architected security pillar walkthrough.
Guardrail versus review, side by side
Read this as guardrail versus review, not better versus worse. They sit next to each other because they cover different ground.
| Dimension | Azure Policy | Architecture assessment |
|---|---|---|
| Core question | Is this resource compliant right now? | Is the architecture sound and evidenced? |
| Unit of evaluation | Individual resource | Whole system / workload |
| Framework | Custom and built-in policy rules | Well-Architected Framework + Cloud Adoption Framework |
| Timing | Continuous, at runtime | Periodic or continuous review |
| Can it block a deployment? | Yes (deny effect) | No — it advises |
| Catches single points of failure? | No | Yes |
| Catches missing / untested RTO? | No | Yes |
| Catches end-to-end Zero Trust gaps? | Partially (per-resource only) | Yes |
| Compliance mapping | Per-resource control state | Per-finding to NIS2/DORA/ISO/SOC 2 |
| Output | Compliance state, optional auto-remediation | Findings + remediation guidance / IaC |
| Primary role | Prevent drift (a rail) | Prove design (a review) |
Think of a guardrail on a mountain road. It stops the car leaving the road. It tells you nothing about whether the road goes where you need to be. Policy is the rail. The assessment is the map. Bring both.
Why you need both
Enforcement and evidence are different jobs, and each is blind where the other sees. Policy stops resources from being created or left non-compliant, automatically and forever. An assessment demonstrates, with mapped findings, that the system as a whole holds up on reliability, security, and resilience.
Run policy without an assessment and you get a tidy environment that might be architecturally fragile. Run an assessment without policy and you get a sound design that starts drifting the morning after the review.
They feed each other. An assessment finding — “this workload has no failover region” — becomes a new policy or landing-zone standard that enforces the fix from then on. The assessment finds the gap. The policy keeps it shut. That’s also the honest answer to whether policy-as-code counts as an architecture review: it encodes decisions already made. It doesn’t make the architectural decision for you.
This is the gap PAA works on, and I’ll frame it plainly. It runs the assessment — all five Well-Architected pillars across Azure and Microsoft 365, deterministic compliance mapping, generated Terraform or Bicep remediation — then drift detection holds the design steady between reviews. It sits alongside an Azure Policy estate. It does not replace it. Policy enforces per-resource configuration. The assessment proves the system design. For the wider picture, see the Azure architecture governance checklist.
FAQ
Does passing all Azure Policy checks mean my architecture is sound? No. Policy evaluates individual resources against configuration rules. It can’t see system-level properties — a single point of failure, an untested recovery objective, an end-to-end Zero Trust gap. A fully policy-compliant environment can still be fragile. Policy proves configuration. Only an assessment proves design.
Is policy-as-code the same as an architecture review? No. Policy-as-code encodes decisions already made and enforces them as guardrails. An architecture review asks whether the overall design was sound to begin with. Policy-as-code keeps you inside known-good boundaries. It doesn’t decide where those boundaries belong, or whether the design is resilient.
Can Azure Policy detect a single point of failure? No. Policy reasons about resources one at a time, not about how they combine. A single point of failure — one workload, one region, no failover — is a property of the architecture that no per-resource rule can express. You need a system-level assessment to catch it.
Should I replace Azure Policy with an architecture assessment? No. Different jobs, and you need both. Policy is a continuous runtime guardrail that prevents drift. An assessment is a periodic or continuous review that proves the design holds up. The strongest setup turns assessment findings into new policies, so every gap gets enforced once it’s found.
Where does compliance mapping fit? Policy reports per-resource control state — useful, but granular. An assessment maps each finding to frameworks like NIS2, DORA, ISO 27001, and SOC 2 at the design level. To an auditor, “the architecture meets this control” is a different, often stronger claim than “these resources are configured this way.”
Configuration enforcement is not design evidence. Run Azure Policy to hold the line on every resource. Run an architecture assessment to prove the system those resources add up to is actually sound.
