This chapter covers the three core Azure Policy effects—Deny, Audit, and DeployIfNotExists—that are central to Azure Policy-based governance. For the AZ-500 exam, these effects appear in roughly 10-15% of questions, often integrated with Azure Blueprints, management groups, and RBAC. Understanding when each effect is used, how they interact with resource creation, and their behavior during evaluation is critical for passing the Security Operations domain (Objective 4.3). You will learn the precise mechanism of each effect, including evaluation order, remediation timing, and how to detect and troubleshoot misconfigurations.
Jump to a section
Consider a building inspector in a city. The inspector has three enforcement actions. First, a 'Stop Work Order' (Deny) immediately halts any construction that violates the building code. The inspector physically prevents the contractor from proceeding. Second, a 'Violation Notice' (Audit) records the infraction in the city log but allows work to continue. The inspector notes the violation for future review and potential fines. Third, a 'Corrective Work Order' (DeployIfNotExists) requires the contractor to fix the issue, and if not done, the city hires a subcontractor to perform the correction at the contractor's expense. The inspector does not stop the work but ensures the violation is remediated. Each action has a specific trigger (violation of code), a specific effect (stop, record, or fix), and a specific scope (the entire building or a specific system). The contractor cannot choose which action applies; the inspector (policy) defines it. This mirrors Azure Policy: Deny blocks non-compliant resources, Audit logs them, and DeployIfNotExists remediates them automatically.
What Are Azure Policy Effects?
Azure Policy effects define what happens when a resource is evaluated against a policy rule. The policy rule is a JSON condition (e.g., "field": "type", "equals": "Microsoft.Compute/virtualMachines") that, when true, triggers the effect. The three effects most relevant to the AZ-500 exam are:
Deny: Blocks the resource creation or update if non-compliant. The request fails with an HTTP 403 (Forbidden) status.
Audit: Creates a warning event in the activity log but allows the resource to be created or updated. Non-compliant resources are marked as such in policy compliance.
DeployIfNotExists (DINE): Evaluates existing resources and deploys a specified template (ARM template) to remediate non-compliance. It does not block creation; it triggers after the resource exists.
Other effects exist (Append, Modify, Manual, Disabled, AuditIfNotExists) but are less frequently tested. The exam focuses on the three named above.
How Policy Evaluation Works Internally
When a resource is created or updated via Azure Resource Manager (ARM), the request passes through the policy engine before reaching the resource provider. The engine:
Collects all applicable policies from the resource's management group hierarchy (root management group -> child management group -> subscription -> resource group). Policies are inherited by default unless scoped to a specific management group/resource group.
Evaluates the policy rule against the resource's properties (tags, location, SKU, etc.) and request context (like source IP for network policies).
Applies the effect in order of precedence: Deny > Append > Audit > DeployIfNotExists. If multiple policies match, the most restrictive effect wins. For example, if a Deny policy and an Audit policy both match, the Deny effect takes precedence and blocks the request.
Logs the outcome in the activity log (for Audit) or returns an error (for Deny).
Deny Effect – Deep Dive
The Deny effect is the most restrictive. It prevents the creation or update of non-compliant resources. It is commonly used to enforce:
Allowed locations (e.g., only East US and West US)
Allowed resource types (e.g., only specific VM SKUs)
Required tags (e.g., CostCenter tag must exist)
Network restrictions (e.g., no public IP on VMs)
How it works:
- The policy engine evaluates the request before it reaches the resource provider.
- If the condition is true, ARM returns an HTTP 403 with a message like "Resource '...' was disallowed by policy."
- The resource is never created; no billing is incurred.
- The policy definition must have "effect": "Deny" in the policyRule.effect property.
Key details for the exam: - Deny is evaluated at request time. It does not retroactively affect existing resources. - Multiple Deny policies can conflict. If one Deny policy blocks a resource and another allows it, the Deny wins (most restrictive). - Deny policies cannot be overridden by RBAC; even the Owner role cannot create a resource blocked by a Deny policy. - To create an exception, use policy exemptions (exempt a resource group or resource from the policy assignment).
Audit Effect – Deep Dive
The Audit effect creates a warning in the activity log but does not block the request. It is used for:
Monitoring compliance without enforcement
Testing new policies before switching to Deny
Tracking usage of deprecated resources
How it works:
- The resource is created or updated normally.
- The policy engine writes an audit event to the activity log with status "Audit" and a description of the non-compliance.
- The resource appears as "Non-compliant" in the Azure Policy compliance dashboard.
- The policy definition uses "effect": "Audit".
Key details for the exam: - Audit does not block any operation. It is purely informational. - Audit events are written to the activity log of the subscription where the resource resides. - You can set up alerts on audit events to notify administrators of non-compliant resources. - Audit is often used as a stepping stone to Deny: first audit to see how many resources would be affected, then switch to Deny.
DeployIfNotExists (DINE) Effect – Deep Dive
DeployIfNotExists is a remediation effect. It evaluates existing resources and deploys a template to fix non-compliance. It does not block creation; it runs after the resource exists. Common use cases:
Enabling diagnostic settings on resources (e.g., VM diagnostics, SQL auditing)
Applying network security group (NSG) rules
Installing extensions (e.g., Antimalware extension on VMs)
How it works:
1. The policy assignment includes a deployment property that specifies an ARM template to deploy.
2. When a resource is created or updated, the policy engine evaluates the condition.
3. If the resource is non-compliant, the policy engine triggers a deployment of the template to the same resource group (or a specified resource group) to remediate the issue.
4. The deployment runs as a system-assigned managed identity (specified in the policy assignment) with contributor permissions on the target scope.
5. The policy effect is "effect": "DeployIfNotExists".
Key details for the exam: - DINE only triggers on create/update operations, not on a schedule. To remediate existing resources, you must run a remediation task manually or on a schedule. - The managed identity must have the necessary permissions (e.g., Contributor on the resource group) to deploy the template. - DINE does not block the original resource creation. The resource is created first, then the remediation runs. - If the remediation fails, the resource remains non-compliant, and an error is logged. - DINE policies can be used with Azure Blueprints to enforce standards at scale.
Evaluation Order and Precedence
When multiple policies apply to a resource, the effects are applied in this order:
Deny – If any Deny policy matches, the request is denied immediately. No further evaluation occurs.
Append – Adds fields to the resource (e.g., tags) before creation. Only applies if no Deny matched.
Audit – Logs non-compliance but does not block.
DeployIfNotExists – Runs remediation after creation.
Note: AuditIfNotExists and Manual follow similar patterns but are less common.
Policy Definition Structure
A policy definition is a JSON object with these key sections:
{
"properties": {
"displayName": "Require tag on resources",
"policyType": "Custom",
"mode": "Indexed",
"policyRule": {
"if": {
"field": "tags['CostCenter']",
"exists": "false"
},
"then": {
"effect": "Deny"
}
}
}
}mode: All (evaluate all resource types) or Indexed (only resources that support tags and location). For tag policies, use Indexed.
if: Condition using fields like field, value, like, contains, exists. Fields include type, name, location, tags, sku.family, etc.
then: Effect to apply.
For DeployIfNotExists, the then section includes a details block with the ARM template and managed identity:
"then": {
"effect": "DeployIfNotExists",
"details": {
"type": "Microsoft.Compute/virtualMachines/extensions",
"existenceCondition": {
"field": "type",
"equals": "Microsoft.Compute/virtualMachines/extensions"
},
"deployment": {
"properties": {
"mode": "incremental",
"template": { ... }
}
},
"roleDefinitionIds": ["/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"]
}
}type: The resource type to check for existence (e.g., the extension).
existenceCondition: Additional condition to determine if the resource already exists.
roleDefinitionIds: The role (by GUID) assigned to the managed identity. Contributor is b24988ac-6180-42a0-ab88-20f7382dd24c.
Interaction with Azure Blueprints
Azure Blueprints can include policy assignments. When a blueprint is assigned, the policies are applied to the target subscription. The effects work identically. Blueprints also support assigning policies at different scopes (management group, subscription, resource group).
Remediation Tasks for DeployIfNotExists
To remediate existing non-compliant resources, you create a remediation task:
In the portal: Azure Policy > Compliance > Select policy > Remediate.
Via PowerShell: Start-AzPolicyRemediation -Name "remediation1" -PolicyAssignmentId "/subscriptions/.../providers/Microsoft.Authorization/policyAssignments/..."
Via CLI: az policy remediation create --name remed1 --policy-assignment "..."
Remediation tasks run the DINE deployment on all non-compliant resources at the time of task creation. They do not run continuously; you must schedule or trigger them.
Common Misconfigurations
Deny policy too broad: A Deny policy on "type": "Microsoft.Compute/virtualMachines" with effect Deny blocks all VMs. Use conditions to allow specific ones.
DINE missing managed identity permissions: The managed identity must have the role specified in roleDefinitionIds. If not, remediation fails.
Audit policy not logging: Ensure the policy assignment is at the correct scope and the resource is within that scope.
Policy conflicts: Two policies with same effect but different conditions can cause unpredictable results. Use policy initiatives to group them.
Troubleshooting
Check activity log for audit events (filter by event source "Policy").
Use Azure Resource Graph to query non-compliant resources.
For Deny errors, the error message includes the policy name and assignment ID.
Use Get-AzPolicyState -ResourceId to see policy evaluation details.
Exam Tips
Remember: Deny blocks, Audit logs, DINE remediates.
DINE does not block; it fixes after creation.
The most restrictive effect wins in case of conflict.
Policy evaluation happens at ARM level, before resource provider.
Custom policies can be created, but built-in policies cover most common scenarios.
Define policy rule condition
Create a JSON policy definition that specifies the condition to evaluate. For example, check if a tag exists: `"field": "tags['CostCenter']", "exists": "false"`. The condition can use fields like `type`, `name`, `location`, `tags`, `sku.family`, or request context like `source`. The mode must be set to `All` or `Indexed` depending on the resource types. This step is crucial because the condition determines which resources trigger the effect. A poorly written condition can cause unintended blocks or missed audits.
Assign policy to scope
Assign the policy definition to a management group, subscription, or resource group. The policy will evaluate all resources within that scope. You can also exclude sub-scopes using `notScopes`. The assignment includes parameters (e.g., allowed locations list) and the effect. For DINE, you must also specify the managed identity and deployment template. The assignment creates a policy assignment object in Azure.
Trigger resource creation/update
When a user or automation creates or updates a resource via ARM, the request is intercepted by the policy engine. The engine collects all applicable policy assignments from the resource's scope hierarchy. It evaluates each policy's condition against the resource properties and request context. This happens synchronously before the resource provider processes the request. If a Deny policy matches, the request fails immediately with HTTP 403.
Apply effect based on evaluation
If the condition is true, the effect is applied. For Deny, the request is blocked and an error is returned. For Audit, the resource is created, and an audit event is written to the activity log. For DINE, the resource is created, and then a deployment is triggered to remediate the non-compliance. The deployment runs asynchronously using the managed identity. The order of effects is Deny > Append > Audit > DINE. Only the highest precedence effect is applied.
Log compliance state
After evaluation, the policy engine updates the compliance state of the resource. For Audit and DINE, the resource is marked as 'Non-compliant' in the Azure Policy compliance dashboard. For Deny, no resource is created, so no compliance state exists. Audit events are stored in the activity log for 90 days. You can query compliance using Azure Resource Graph or PowerShell. Remediation tasks can be run to fix existing non-compliant resources for DINE policies.
Enterprise Scenario 1: Enforcing Allowed Regions
A global enterprise wants to ensure all resources are deployed only in approved Azure regions (e.g., East US and West Europe). They create a custom Deny policy that checks "field": "location", "notIn": ["eastus", "westeurope"] with effect Deny. The policy is assigned at the root management group. Any attempt to create a resource in other regions (e.g., Southeast Asia) fails with a 403 error. This prevents accidental data sovereignty violations. However, a developer complains they cannot deploy a test VM in East Asia for a proof-of-concept. To handle this, the enterprise creates a policy exemption for a specific resource group used for testing. This scenario is common and tests the understanding of Deny effect and exemptions.
Enterprise Scenario 2: Auditing Unencrypted Disks
A financial institution must ensure all managed disks have encryption enabled. They assign an Audit policy that checks "field": "Microsoft.Compute/disks/encryptionSettingsCollection.enabled", "equals": "false" with effect Audit. This does not block creation but logs non-compliant disks. The security team sets up an alert on the activity log for Audit events. They then run a remediation task using a DINE policy that enables encryption on existing disks. The DINE policy deploys an ARM template that enables encryption. The managed identity must have Contributor permissions on the disk resource group. This scenario tests the difference between Audit (monitoring) and DINE (remediation).
Enterprise Scenario 3: Deploying Antimalware Extension
A company requires all Windows VMs to have the Microsoft Antimalware extension installed. They create a DINE policy that checks if the extension exists ("type": "Microsoft.Compute/virtualMachines/extensions", "name": "IaaSAntimalware"). If not, the policy deploys the extension using an ARM template. The policy is assigned at subscription level. When a new VM is created, the extension is automatically installed. For existing VMs, a remediation task is run. A common issue is that the managed identity lacks permissions, causing the remediation to fail. The exam tests that DINE does not block VM creation; it only remediates after creation.
AZ-500 Exam Focus on Policy Effects
The AZ-500 exam (Objective 4.3) tests your ability to configure and interpret Azure Policy effects for security governance. Specific sub-objectives include:
4.3.1: Configure Azure Policy for security compliance (Deny, Audit, DeployIfNotExists)
4.3.2: Implement policy initiatives and assignments
4.3.3: Manage policy compliance and remediation
Common Wrong Answers
"DeployIfNotExists blocks non-compliant resources" – This is false. DINE does not block; it remediates after creation. Candidates confuse it with Deny.
"Audit effect prevents resource creation" – Audit only logs; it does not block. Candidates think Audit is like a warning that stops the action.
"Deny effect can be overridden by RBAC" – False. Deny policies are enforced regardless of RBAC permissions. Even the subscription Owner cannot create a resource blocked by Deny.
"All policies are evaluated after resource creation" – False. Deny and Audit are evaluated before creation; DINE runs after.
Specific Numbers and Terms
The default evaluation order: Deny > Append > Audit > DeployIfNotExists.
HTTP status code for Deny: 403.
Activity log retention for audit events: 90 days.
The Contributor role GUID: b24988ac-6180-42a0-ab88-20f7382dd24c.
Policy mode: All vs Indexed. Indexed is for resources that support tags and location.
Edge Cases and Exceptions
Policy inheritance: Policies are inherited from management groups down to subscriptions and resource groups. But a Deny policy at a higher scope cannot be overridden by a lower scope Allow (since Deny is most restrictive).
Multiple effects: If a resource matches both a Deny and an Audit policy, the Deny takes precedence and blocks the request. The Audit event is not generated because the request never completes.
DINE on existing resources: DINE only triggers on create/update. To remediate existing resources, you must run a remediation task. The exam may ask when to use remediation tasks.
Policy exemption vs. exclusion: Exemption (with exemptionCategory) allows a resource to be exempt from evaluation. Exclusion (using notScopes) removes a scope from policy assignment. The exam tests the difference.
How to Eliminate Wrong Answers
If a question says a policy "prevents" or "blocks" creation, and the effect is Audit or DINE, eliminate that answer.
If a question says a policy "stops" creation, only Deny fits.
If a question involves automatic remediation after creation, it's DINE.
If a question involves monitoring without blocking, it's Audit.
Look for keywords: "block" -> Deny, "log" or "warn" -> Audit, "deploy" or "fix" -> DINE.
Deny effect blocks resource creation with HTTP 403 and cannot be overridden by RBAC.
Audit effect logs non-compliance to activity log but does not block resource creation.
DeployIfNotExists effect deploys an ARM template to remediate non-compliance after resource creation.
Policy evaluation order: Deny > Append > Audit > DeployIfNotExists; only the most restrictive effect applies.
For DINE policies, the managed identity must have the role specified in roleDefinitionIds (e.g., Contributor GUID b24988ac-6180-42a0-ab88-20f7382dd24c).
Remediation tasks are required to apply DINE policies to existing non-compliant resources.
Policy exemptions (not exclusions) allow specific resources to be exempt from policy evaluation.
Audit events are stored in activity log for 90 days; use alerts to monitor non-compliance.
Custom policy definitions require mode: All or Indexed; Indexed is for tag/location policies.
Policy inheritance flows from root management group down to resource groups; Deny at higher scope cannot be overridden.
These come up on the exam all the time. Here's how to tell them apart.
Deny Effect
Blocks resource creation/update with HTTP 403.
Most restrictive effect; takes precedence over others.
Used to enforce mandatory requirements (e.g., allowed locations).
Cannot be overridden by RBAC.
No resource is created if non-compliant.
Audit Effect
Allows resource creation/update; logs non-compliance.
Less restrictive; does not block.
Used for monitoring and compliance reporting.
Can be used to test policies before switching to Deny.
Resource is created but marked non-compliant.
DeployIfNotExists Effect
Remediates non-compliance by deploying a template.
Triggers after resource creation.
Requires managed identity with permissions.
Does not block creation.
Can be used to automatically enable diagnostic settings.
Audit Effect
Only logs non-compliance; no remediation.
Triggers before resource creation (evaluation).
No permissions needed beyond policy assignment.
Does not block creation.
Used for visibility and alerting.
Mistake
DeployIfNotExists blocks resource creation if non-compliant.
Correct
DeployIfNotExists does not block creation. It allows the resource to be created and then deploys a remediation template. The resource is created first, then the policy engine triggers the deployment asynchronously.
Mistake
Audit effect prevents the resource from being created.
Correct
Audit effect does not block creation. It allows the resource to be created or updated and writes an audit event to the activity log. The resource is considered non-compliant but exists.
Mistake
Deny policy can be bypassed by users with Owner role.
Correct
Deny policies are enforced at the Azure Resource Manager level and cannot be overridden by any RBAC role, including Owner. The only way to create the resource is to modify or remove the policy assignment or create an exemption.
Mistake
Policy effects are evaluated after the resource provider creates the resource.
Correct
Policy evaluation happens before the resource provider processes the request for Deny and Audit effects. DeployIfNotExists runs after creation, but Deny and Audit are evaluated synchronously before the resource is created.
Mistake
Multiple policies with different effects all apply to the same resource.
Correct
Only the most restrictive effect applies. The order is Deny > Append > Audit > DeployIfNotExists. If a Deny policy matches, no other effect is applied. If no Deny matches, Audit may apply, but DINE may also apply separately.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Deny policies are enforced at the Azure Resource Manager level and apply to all users regardless of RBAC role. Even the Owner role cannot create a resource that violates a Deny policy. To allow a specific resource, you must create a policy exemption or modify the policy assignment.
No. DeployIfNotExists (DINE) does not block resource creation. The resource is created first, and then the policy engine triggers a deployment to remediate the non-compliance. If the remediation fails, the resource remains non-compliant. DINE is used for automatic remediation, not enforcement.
Audit evaluates the resource itself (e.g., check if a tag exists). AuditIfNotExists evaluates a sub-resource or extension (e.g., check if a diagnostic setting exists on a SQL database). Both log non-compliance but do not block. AuditIfNotExists is used when the compliance condition depends on a related resource.
Create a remediation task. In the portal, go to Azure Policy > Compliance, select the policy, and click 'Remediate'. You can also use PowerShell: `Start-AzPolicyRemediation -Name 'remediation1' -PolicyAssignmentId '<id>'`. The remediation task runs the DINE deployment on all non-compliant resources at that time.
The Deny effect takes precedence because it is more restrictive. The request is blocked with HTTP 403, and no Audit event is generated because the resource was never created. The Audit policy only applies if no Deny policy matches.
Yes, but it is not typical. For tags, Deny is more common to block creation if tags are missing. DINE could be used to add missing tags after creation, but it requires a managed identity with write permissions. The Append effect is also an option to add tags during creation.
Audit events are stored in the Azure Activity Log for 90 days. After that, they are automatically deleted. To retain them longer, export the activity log to a Log Analytics workspace or storage account.
You've just covered Azure Policy Effects: Deny, Audit, DeployIfNotExists — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?