Deny policy

A deny policy in Azure Policy handles create and update requests the same way: any Resource Manager operation whose final state violates the policy condition is blocked before it reaches the resource provider.

For a policy like “minimum TLS version for web apps,” the behavior is:

1. Order of evaluation
   When a request comes in to create or update a web app, Azure Policy:
   • Collects all policy assignments that apply to that resource.
   • Evaluates effects in this order for Resource Manager mode:
     1. disabled
     2. append / modify
     3. deny
     4. audit
     5. manual
     6. auditIfNotExists
     7. denyAction
   • If the resource (or the resulting request after append/modify) violates a deny policy, the request is rejected with HTTP 403 (Forbidden) and never reaches the web app resource provider.
2. New web app deployment vs updating an existing web app
   From the policy engine’s perspective, both are Resource Manager operations and are evaluated the same way:
   • New web app (create): If the template/portal request sets minTlsVersion to a value that doesn’t meet the policy, the create operation is denied with 403.
   • Existing web app (update): If an update changes configuration so that minTlsVersion becomes non-compliant, the update operation is denied with 403.
   There is no special “path” difference in how Azure Policy evaluates create vs update; both are evaluated against the policy definition before the request is sent to the resource provider.
3. Existing non-compliant resources (no update)
   For resources that already exist and are non-compliant but are not being updated:
   • During periodic compliance evaluation, Azure Policy marks them as non-compliant under that deny policy.
   • They continue to run as-is until an operation attempts to update them; at that point, any non-compliant update is blocked.
4. How the configuration is checked
   • The policy definition’s if block targets specific fields (for example, the TLS-related property on the web app resource).
   • On each create/update request, Azure Policy evaluates the resulting resource state (after any append/modify effects) against those fields.
   • If the condition is true and the effect is deny, the operation fails with 403 and the portal/ARM deployment shows a RequestDisallowedByPolicy-type error.

So for a minTLS deny policy on web apps, both deploying a new app and updating an existing app are blocked in the same way if the final configuration doesn’t meet the minimum TLS requirement; the difference is only that existing non-compliant apps are merely flagged as non-compliant until an update is attempted.

References:

• Azure Policy definitions deny effect
• Azure Policy definitions effect basics
• Tutorial: Create a custom policy definition
• What is Azure Policy?