Azure Policies

Policies are a way to communicate or enforce certain conventions while creating Azure resources. They’re essential for maintaining governance at scale.

Important: Policies apply to newly created resources. Existing resources aren’t automatically remediated unless you configure remediation tasks.

Policy Effects

You can set different actions for when a policy evaluation fails. The most common effects are:

• Deny - Prevent resource creation
• Audit - Allow creation but flag as non-compliant
• Modify - Automatically fix the resource
• DeployIfNotExists - Deploy additional resources if conditions aren’t met

Example: Require Tags on Resources

Here’s a built-in policy that denies resource creation if a required tag is missing:

{
  "properties": {
    "displayName": "Require a tag on resources",
    "policyType": "BuiltIn",
    "mode": "Indexed",
    "description": "Enforces existence of a tag. Does not apply to resource groups.",
    "parameters": {
      "tagName": {
        "type": "String",
        "metadata": {
          "displayName": "Tag Name",
          "description": "Name of the tag, such as 'environment'"
        }
      }
    },
    "policyRule": {
      "if": {
        "field": "[concat('tags[', parameters('tagName'), ']')]",
        "exists": "false"
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

Audit vs Deny

Using audit instead of deny is less disruptive—it won’t block resource creation but will show non-compliant resources in the Azure Policy compliance dashboard. This is useful for:

• Rolling out new policies gradually
• Understanding the impact before enforcing
• Resources that can’t be immediately fixed

Best Practices

1. Start with Audit - Understand impact before denying
2. Use Policy Initiatives - Group related policies together
3. Assign at the right scope - Management group, subscription, or resource group
4. Use exclusions sparingly - They can create security gaps