When to use Audit, Deny, DeployIfNotExists, Modify and DenyAction in a landing zone, and what each commits you to.
From Azure Landing Zones (Ultra Transcenders: Beyond the Exam) by Tony Rough (coming December 2026)
The effect is the decision that most affects workload teams, because it determines whether a mistake is reported, corrected or refused.
| Effect | On create or update | On existing resources | Needs a managed identity | Typical landing zone use |
|---|---|---|---|---|
| Deny | Request refused with 403 before reaching the resource provider | Marked non-compliant | No | Hard guardrails: no subnet without an NSG, no unapproved regions |
| Audit | Allowed; warning event in the activity log | Marked non-compliant | No | Monitor-first rollout, low-risk rules |
| AuditIfNotExists | Allowed; checks a related resource after provisioning | Marked non-compliant | No | “Every VM should have an extension” without deploying it |
| DeployIfNotExists | Allowed; deploys a template after a delay if the related resource is missing | Marked non-compliant until remediated | Yes | Diagnostic settings, Defender for Cloud settings, private DNS records |
| Modify | Request altered before it reaches the provider | Marked non-compliant until remediated | Yes | Tags, selected modifiable properties |
| Append | Fields added to the request | Marked non-compliant | No | Where Modify can’t be used |
| DenyAction | Blocks the named action; only delete is supported |
Marked Protected | No | Protecting critical resources from deletion |
| Disabled | Rule not evaluated | Not evaluated | No | Switching off one definition inside an initiative |
Azure Policy evaluates in a fixed order: disabled first, then append and modify (which can change the request), then deny, audit, manual, auditIfNotExists, and denyAction last; auditIfNotExists and deployIfNotExists run again after the resource provider returns success. Every assignment is evaluated independently and the net result is cumulative most restrictive: if any assignment denies, the request fails.
That last rule shapes scope design. Azure Policy is an explicit deny system, so a permissive allow list on a child management group can’t relax a stricter allow list inherited from above. Learn’s answer is to exclude the child scope from the parent assignment and assign the more permissive definition at the child.
Some details decide whether an effect is safe to use:
audit, deny and modify or append are often interchangeable, as are auditIfNotExists and deployIfNotExists, so built-ins usually expose the effect as a parameter. Change the parameter or an override, never the definition.audit as the conflict effect for Modify definitions that use aliases, so an API version where the property isn’t modifiable doesn’t fail requests.PT10M), and up to 360 minutes or a provisioning-based delay can be set; during an evaluation cycle matching resources are only marked non-compliant.cascadeBehaviors set to deny. Policy assignments, locks, deny assignments, deployment stacks and subscriptions are exempt from it.Common pitfall: Expecting DeployIfNotExists and Modify to fix resources that already existed when the policy was assigned - both only act on create or update; existing resources are marked non-compliant and stay that way until someone runs a remediation task.
This note is one section of Azure Landing Zones: Building an Azure Foundation with the Cloud Adoption Framework, an independent guide in the Ultra Transcenders Beyond the Exam series, with comparison tables, diagrams, the common pitfalls and tested companion code, plus a glossary linked to Microsoft Learn.
Due on Amazon in December 2026, in Kindle and paperback editions.
About the book · Azure Landing Zones terms in the glossary · All free notes from Azure Landing Zones
The four environment and four compliance design areas of the Cloud Adoption Framework, what each one decides, and which team usually owns it.
What a first platform landing zone needs on day one, what can safely wait, and how to grow it without redesigning later.
The intermediate root, Platform, Landing zones, Sandboxes and Decommissioned groups: what each is for and why the hierarchy stays shallow.
What each Azure Firewall tier adds, where Basic stops being enough, and how to choose for a hub that many workloads share.
The factors that decide between a customer-managed hub and Azure Virtual WAN, and the constraints that can make the choice for you.
How central private DNS zones and DeployIfNotExists policy register private endpoint records automatically, and the permissions it needs.
How the two infrastructure-as-code options compare for deploying and running an Azure landing zone, and what decides the choice.