Azure Policy Effects: Audit, Deny, Modify

Azure Policy is a service in Azure that allows you to create, assign, and manage policies. These policies enforce different rules and effects over your resources, ensuring that resources stay compliant with your corporate standards and service level agreements. An effect is the behavior that Azure Policy takes when a resource is evaluated against a policy definition. The three primary effects—Audit, Deny, and Modify—are the focus of this chapter, but Azure Policy also includes other effects like Append, DeployIfNotExists, AuditIfNotExists, and Disabled. For SC-900, you need to understand the core three in depth.

Effects are the teeth of Azure Policy. Without effects, a policy is just a statement. Effects determine whether non-compliant resources are simply logged (Audit), blocked from creation or update (Deny), or automatically corrected (Modify). The choice of effect directly impacts your compliance posture and operational overhead. For example, using Deny can prevent security misconfigurations from ever being deployed, but it may block legitimate development if too restrictive. Audit allows you to detect issues without disruption, while Modify automates remediation.

Azure Policy evaluates resources during two main events: resource creation or update (triggered by Azure Resource Manager) and periodic compliance evaluation (every 24 hours by default). The evaluation engine checks each resource against all assigned policy definitions. For each policy, the engine determines which effect applies based on conditions defined in the policy rule. The evaluation order matters: if multiple policies assign different effects to the same resource, the most restrictive effect typically wins. Specifically, Deny overrides Audit and Modify, and Modify overrides Audit. If a policy with Deny effect is violated, the resource creation/update is rejected with an HTTP 403 (Forbidden) status code. If a policy with Audit effect is violated, the resource is created/updated but flagged as non-compliant in the compliance dashboard. Modify effect triggers a remediation task if the resource is non-compliant, which can automatically update the resource.

The Audit effect is the least intrusive. It activates when a resource is non-compliant and logs a warning event in the activity log, but it does not block the request. Audit is ideal for scenarios where you want to know about non-compliance without impacting operations. For example, you might use Audit to track which storage accounts do not have HTTPS-only transfer enabled. The evaluation result is stored in the compliance state of the resource, and you can view it in the Azure Policy compliance dashboard. Audit does not trigger any automatic remediation. It is important to note that Audit does not create a denial; it merely reports. The audit event is written to the activity log with a severity of 'Warning' and a category of 'Policy'.

The Deny effect is the strictest. It prevents a resource from being created or updated if the resource is non-compliant. The denial occurs at the Azure Resource Manager level, before the resource is provisioned. When a user attempts to create or update a resource that violates a Deny policy, the request fails with an error message indicating the policy that was violated. This effect is commonly used to enforce security baselines, such as requiring all managed disks to use encryption at rest. Deny can be applied to properties like location, SKU, tags, or any other property that can be evaluated. One key nuance: Deny only applies to create and update operations; it does not affect existing resources. Existing non-compliant resources are flagged as non-compliant, but they are not deleted. To remediate existing resources, you must combine Deny with a remediation effect like Modify or DeployIfNotExists, or manually fix them.

The Modify effect is used to automatically correct non-compliant resources during creation or update, or via a remediation task. Modify can add, update, or remove properties of a resource. For example, you can create a policy that automatically adds a specific tag to resources if it is missing. Modify works by defining a 'modify' operation in the policy definition, which specifies the property to change and the new value. When a resource is created or updated, the Modify effect runs after the resource is provisioned but before the operation is considered complete. If the resource is non-compliant, the modification is applied. For existing resources, you can trigger a remediation task that scans all resources in scope and applies the modification. Modify is often used in conjunction with Deny to enforce a 'guardrail' approach: Deny blocks blatant violations, while Modify fixes minor ones automatically.

All policy effects are defined within a policy definition's JSON. Here is an example of a policy definition using the Deny effect:

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Compute/virtualMachines"
  },
  "then": {
    "effect": "deny"
  }
}

For Modify, the 'then' block includes a 'details' section with the role definition IDs needed for remediation and the operations:

{
  "if": {
    "field": "tags['costCenter']",
    "exists": "false"
  },
  "then": {
    "effect": "modify",
    "details": {
      "roleDefinitionIds": [
        "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
      ],
      "operations": [
        {
          "operation": "add",
          "field": "tags['costCenter']",
          "value": "default"
        }
      ]
    }
  }
}

For Audit, the 'then' block simply specifies:

"then": {
  "effect": "audit"
}

Azure Policy effects integrate with Azure Management Groups, Subscriptions, and Resource Groups. Policies can be assigned at any scope, and effects propagate down. For example, a Deny policy assigned at a Management Group applies to all subscriptions under it. Azure Policy also integrates with Azure Blueprints, where policies can be included as artifacts. Blueprints assign policies to subscriptions during blueprint assignment. Additionally, Azure Policy works with Azure RBAC: to perform remediation, the policy assignment needs a managed identity with appropriate permissions (e.g., Contributor role on the resource scope). The Modify effect requires the policy assignment's managed identity to have the necessary role to modify the resource.

When multiple policies apply to the same resource, the evaluation order is alphabetical by policy name, but the effect precedence is: Deny > Modify > Audit. If a Deny policy evaluates to non-compliant, the resource is denied regardless of other policies. If no Deny applies, a Modify effect can run. Audit only logs if no other effect takes action. This precedence ensures that the most restrictive effect wins. For example, if you have an Audit policy that checks for tags and a Modify policy that adds missing tags, the Modify effect will run first (if the resource is non-compliant) and then the Audit policy will see the resource as compliant (after modification). However, if a Deny policy blocks the resource entirely, Modify never runs.

For Modify and DeployIfNotExists effects, you can create remediation tasks to fix existing non-compliant resources. Remediation tasks run asynchronously and can be triggered manually or on a schedule. The compliance state of a resource can be: Compliant, Non-compliant, Conflicting, Error, or Not started. Audit and Deny policies set the compliance state based on evaluation. Modify policies set compliance state after modification. It is possible for a resource to be compliant with one policy but non-compliant with another. The overall compliance state of a resource is the worst state across all policies.

The SC-900 exam tests your ability to choose the correct effect for a given scenario. For example: "You need to ensure that all storage accounts have HTTPS-only transfer enabled. You want to prevent creation of non-compliant storage accounts." Answer: Deny. "You want to be notified when a storage account is created without HTTPS, but you don't want to block it." Answer: Audit. "You want to automatically add a tag to all resources that are missing it." Answer: Modify. Also know that Deny can be overridden by exemptions, but that is a separate topic.

Each effect has its place in a comprehensive governance strategy. On the exam, be prepared to identify which effect meets a given requirement, especially when the requirement includes words like 'prevent', 'log', or 'automatically correct'.

A large enterprise with multiple business units uses Azure Policy to enforce tagging standards. They require that all resources have a 'costCenter' tag. They use a combination of Deny and Modify effects. A Deny policy blocks creation of new resources without the tag, preventing untagged resources from being deployed. However, they also have many existing untagged resources. To fix these, they assign a Modify policy that automatically adds the 'costCenter' tag with a default value 'unknown' to any resource missing it. They then run a remediation task to apply the modification to all existing non-compliant resources. The Deny policy ensures no new untagged resources appear, while Modify cleans up the backlog. The challenge is managing the managed identity permissions: the Modify policy's identity needs Contributor access to all resource groups in scope. They use a custom role with minimal permissions to avoid over-privilege.

A cloud center of excellence team wants to prevent deployment of expensive VM sizes (e.g., Standard_DSv5) in non-production subscriptions. They create a Deny policy that blocks any VM with a SKU that is not in an allowed list. The policy is assigned at the management group level covering all non-production subscriptions. When a developer tries to create a large VM, the request is denied with a clear error message. This prevents cost overruns. However, they also use an Audit policy to report any existing VMs with disallowed SKUs, so they can manually migrate or resize them. The Deny effect is critical because it proactively prevents non-compliant resources. A common issue is that the policy might block legitimate requests if the allowed list is too restrictive, so they maintain a process to update the list via parameter changes.

A financial services company must ensure all storage accounts have encryption at rest enabled (which is default, but they want to enforce it). They use a Deny policy to prevent creation of storage accounts with encryption disabled (though Azure defaults to enabled, a user could disable it). Additionally, they use an Audit policy to detect any existing storage accounts that have encryption disabled. Because encryption is a critical security requirement, they also use a Modify policy to automatically enable encryption on any storage account that is created without it (though this is rare). The Modify effect is configured to set the 'properties.encryption.services.blob.enabled' property to true. They run a remediation task quarterly to catch any drift. The key lesson is that Deny is not enough for existing resources, so Audit and Modify cover detection and remediation. Performance is not a concern because policy evaluation is fast, but remediation tasks can take time for large numbers of resources.