Azure Policy effects: Deny, Audit, Modify, and the one that self-heals
A policy's rule decides what it is looking for; its effect decides what happens when it finds it. Pick the wrong effect and you either block your own team or quietly log a problem forever. Here is what each one does.
Azure Policy is how you turn "please tag your resources" and "no resources outside these regions" from a wiki page into something the platform enforces. Every policy definition has exactly one effect, and Microsoft is precise about it: the effect "determines what happens when the policy rule is evaluated to match." Same rule, different effect, completely different outcome — so the effect is the lever that decides whether a policy observes, blocks, fixes, or repairs. Learn the handful you will actually use.
Deny — the wall
Deny blocks a non-compliant create or update before it happens. Try to make a resource in a forbidden region or without a required tag, and the request fails. This is enforcement in the strongest sense: the wrong thing cannot be created, so there is no cleanup later. It is also the effect that generates support tickets when it is too strict, so you point it at the rules that genuinely must never be broken.
Audit — the clipboard
Audit lets the resource through but records it as non-compliant, so it shows up in your compliance reporting. Nothing is blocked; you just get a truthful clipboard of what does not meet the standard. Audit is how you discover the shape of a problem before you enforce it — roll a rule out as Audit, see how much is already non-compliant, then decide whether you can safely switch it to Deny.
Append and Modify — the quiet fixers
Append adds a field to a resource as it is created (a required setting, say), and Modify adds, updates, or removes properties — most commonly tags — on new or existing resources. Instead of denying an untagged resource and making a human retype it, a Modify policy can stamp the tag on for them. That is enforcement that does not teach people to type "tbd" just to get past the wall. One catch worth knowing: because Modify changes resources, it needs a managed identity to carry out the remediation.
DeployIfNotExists — the effect that heals
This is the one that makes governance feel alive. DeployIfNotExists checks whether a related resource or setting exists and, if it does not, deploys it. Create a resource with no diagnostic settings and a DeployIfNotExists policy can deploy them for you, so telemetry starts flowing without anyone remembering to configure it. Governance stops being a checklist and becomes self-healing: the estate notices what is missing and fixes it. Like Modify, it acts on your behalf, so it also requires a managed identity for remediation. (Its read-only cousin, AuditIfNotExists, only flags the absence rather than fixing it.)
| Effect | When a rule matches, it… | Reach for it when… |
|---|---|---|
| Deny | blocks the create/update | the rule must never be broken |
| Audit | allows it, marks non-compliant | you want visibility before enforcing |
| Append / Modify | adds or changes properties (e.g. tags) | you would rather fix than reject |
| DeployIfNotExists | deploys what was missing | settings should exist automatically |
| AuditIfNotExists | flags the missing related resource | you want to report the gap, not fill it |
Deny stops the wrong thing. DeployIfNotExists makes the right thing appear. Governance that only says no is only half a system.
Several assignments can hit one resource, at the same or different scopes, each independently evaluated. The net result, in Microsoft's words, is cumulative most restrictive: if any applicable policy denies, the resource is blocked. So there is no gap for a resource to slip through — overlapping policies tighten, never loosen.
The pattern to remember
Roll new rules out as Audit to see reality, promote the non-negotiable ones to Deny, use Modify to enforce tags without friction, and use DeployIfNotExists so required settings deploy themselves. That progression — observe, enforce, fix, heal — is the difference between a governance strategy that people route around and one that quietly keeps the estate correct while everyone gets on with their work. When an interviewer asks how you would enforce a standard across a hundred subscriptions, that four-word arc is the answer.