You are already running Azure Policy. Build a landing zone, connect a server to Arc or switch on Defender for Cloud, and assignments start evaluating your estate within the hour. In most tenants I am called into, nobody chose them.
The policy you did not write
An Azure landing zone deployment assigns the Microsoft Cloud Security Benchmark at the intermediate root management group, and every subscription placed beneath it inherits that assignment whether the workload team knows it or not. The archetype management groups below carry more. Diagnostic settings arrive by policy. Tag inheritance arrives by policy. The rules that make a Corp landing zone behave differently from an Online one are policy assignments and nothing else. Defender for Cloud writes its entire regulatory compliance view through the same engine, so enabling a framework there creates an initiative assignment that someone will later find in the compliance blade and wonder about. Arc delivers machine configuration through it. If you worked through the Landing Zones series on this site, you assigned most of that deliberately, and the deliberation was about the landing zone. The policy came along as plumbing.
I have yet to review an estate where anyone could name every assignment in force and say why it was there. That is not a criticism of the people running those estates. Policy arrives bundled with things worth having, it works quietly when it is right, and the compliance percentage on the summary page reads like a score rather than a design document. What makes it worth your attention is that a policy assignment is a standing instruction to the platform, evaluated against every resource in scope, indefinitely, by an engine that never asks whether you still mean it.
What Policy governs, and what it leaves to RBAC
Role-based access control answers one question: may this principal perform this operation at this scope. Azure Policy answers a different one: is the resulting state of this resource acceptable. The two are evaluated independently and both have to pass. An owner of a subscription has every operation available and still cannot create a virtual machine in a region a deny assignment excludes. That is the design working as intended. Authority over an estate is not the same thing as licence to reshape it, and the principal holding the most permissions is usually the one able to do the most damage in the least time.
So I treat Policy as the durable half of a governance design and RBAC as the perishable half. Role assignments follow people, and people move. A deny on resource locations outlives the person who wrote it, the team that owned the subscription, and usually the project that justified it. That durability is the reason to use the product and it is also the reason to be careful with it, which is most of what this series is about.
The rules are readable by the governed
One property of Azure Policy has no real equivalent elsewhere in the platform. Every policy object, definitions and initiatives and assignments alike, is readable by every principal holding any role at that scope or below. A reader on a subscription can enumerate the rules constraining it. Microsoft made that choice deliberately and documents it as transparency to all users and services for what policy rules are set in their environment.
Almost every argument I have refereed between a platform team and an application team about a blocked deployment could have been settled by the application team reading the assignment themselves.
I have almost never seen a workload team use it, because it does not occur to them that they can. Tell them. It changes the relationship between the team writing guardrails and the teams living inside them, since the guardrails stop being a rumour and become a document with your name on it.
Reading is universal. Writing is not, and the split is sharper than people expect. Resource Policy Contributor covers most of the authoring surface. Contributor can trigger a remediation task, which deploys and alters real resources, but cannot create or update a definition or an assignment. Granting the managed identity on a remediating assignment its roles requires User Access Administrator, because that grant is a privilege escalation and the platform treats it as one. Anyone able to create a deployIfNotExists assignment and grant its identity is handing out standing write authority to an object rather than a person. That is the subject of the remediation article later in this series, and it is the part of this product I see mishandled most often.
Both ways to get this wrong
The failure that gets written up is drift. Resources land in regions nobody approved, without tags, without diagnostic settings, and the gap surfaces through an auditor or a bill. It is slow and embarrassing and almost entirely recoverable, because everything drift produces can be inventoried and fixed on a schedule you control.
The other failure moves faster and I have watched it more often. A deny assignment goes on at management group scope on a Thursday afternoon because someone wanted the estate clean before the sprint closed, and by Friday morning three deployment pipelines are failing with a 403 naming a policy that nobody on those teams has permission to change. Or a remediation task runs across forty thousand resources with an identity holding Contributor at the root, rewriting a setting on production resources that were non-compliant for a reason somebody knew and never wrote down. Or delete protection goes on, the resource group gets deleted anyway because the cascade behaviour sat at a default the author never read, and the assignment reported compliant throughout.
Both failures come from the same absent discipline, which is treating a change to policy as a change to production. Microsoft documents a full framework for rolling an assignment out in tiers, holding the effect at audit while you widen the blast radius deliberately, and hardly anyone uses it. If you read one article in this series, read the one on rollout.
What it costs
Azure Policy is free for Azure resources. No per-assignment charge, no per-evaluation charge, nothing for the compliance data. That is worth saying plainly, because I have sat in meetings where a governance programme was scoped down over a cost that does not exist.
The one meter is guest configuration on Arc-enabled servers, billed per server per month at a flat rate no matter how many configuration assignments that server carries, and standing at $6 as at August 2026. Azure virtual machines are not billed for it. There is also a preview bundle, Essential Machine Management, priced at $9 per server per month once billing begins. Machine configuration belongs to the Arc series on this site and this series does not re-derive it. The pricing question comes up in the first meeting every time, though, so the short answer belongs here: assigning policy across your Azure estate costs nothing, and configuring the inside of a machine that is not in Azure costs $6 a month.
Why organisations actually adopt this
Everything above is the architect’s case. The organisational case is usually simpler and it is worth naming, because it is the reason the budget exists. Somebody signed an obligation. ISO 27001, PCI DSS, HIPAA, NIST 800-53, an internal standard the security function published, or a customer contract with a security schedule attached. That obligation has to be met continuously rather than annually, across an estate that changes daily, and demonstrated to somebody who will ask for evidence.
Azure Policy is the only mechanism in the platform that turns a written obligation into a thing measured every day without anybody being asked. Microsoft ships most of the major standards as initiatives you can assign in an afternoon, which is genuinely valuable and comes with a limit stated plainly on every one of their mapping pages: what you get is a partial view, because controls map imperfectly onto rules and some controls no rule addresses at all. Understanding that limit is most of the difference between a compliance programme and a dashboard, and this series gets to it properly later.
The second organisational reason is quieter and, over years, larger. A rule expressed as policy survives the people who agreed it. A rule expressed as a documented standard, a code review convention, or a conversation in an onboarding session does not.
Where this goes
The series is built in four movements and they run in the order I would actually work.
First, enough of the object model to read what you are looking at, then the catalogue Microsoft already ships, because almost every rule you are about to write exists and is maintained by somebody else. The second movement implements it: the effects and what each commits you to, a guardrail set, and remediation, which is where a policy stops reporting and starts acting on your behalf through an identity you granted.
The third movement is where the work actually lives. What to do when a Microsoft built-in is nearly right, given that you cannot edit one and can only duplicate it, and what that copy costs you afterwards. Then what to do when nothing exists at all, and how to tell that apart from not having looked properly.
The fourth movement is operating the result: exemptions as the ledger of accepted risk, rolling changes out without breaking production, reading the compliance number honestly, proving a regulatory standard, and running the whole estate from a repository rather than a portal. The last article is the decision about which control answers which question, and where Policy should stop.
Every article assumes you have an Azure estate already worth governing. The worked examples run on Northfork Supply Co., the estate the Landing Zones series built, because the guardrails I would write for Northfork are the ones I would write for you.
Azure Policy
Next: [AP 2] The Object Model: Definitions, Initiatives, and the Explicit Deny ›
