2.1.3.1. Implement Azure Policy

💡 First Principle: Azure Policy is a governance service that enforces organizational standards and assesses compliance at scale, ensuring resources remain aligned with corporate, regulatory, and operational requirements through automated rule application.

Scenario: Your company requires all new Virtual Machines to be deployed within specific Azure Regions (e.g., "East US" or "West Europe") and must have an "Environment" tag applied. Developers sometimes forget to apply these tags or deploy in unauthorized regions.

What It Is: Azure Policy is a service that allows you to create, assign, and manage policies to enforce standards and assess compliance for your Azure resources.

Key Components:

• Policy Definition: Describes the conditions to evaluate and the effect to apply. Effects include:
  • Deny: Blocks non-compliant resources from being created or updated.
  • Audit: Flags non-compliance for review in compliance reports.
  • Append: Adds settings to resources (e.g., tags, security settings).
  • DeployIfNotExists: Deploys required resources if missing (e.g., deploying a diagnostic setting to a VM).
  • Modify: Alters resource properties for compliance (e.g., enabling encryption on storage accounts).
• Policy Assignment: Applies a policy definition to a specific scope (management group, subscription, or resource group).
• Initiative Definition: Groups multiple policy definitions to address broader governance goals (e.g., "PCI DSS Compliance Initiative").
• Initiative Assignment: Applies an initiative to a scope, simplifying management of related policies.

Practical Implementation: Policy to Enforce a Tag

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "field": "[concat('tags[', parameters('tagName'), ']')]",
      "exists": "false"
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {
    "tagName": {
      "type": "String",
      "metadata": {
        "displayName": "Tag Name",
        "description": "Name of the tag, such as 'environment'"
      }
    }
  }
}

⚠️ Common Pitfall: Applying a "Deny" policy without first testing it with an "Audit" effect. This can unexpectedly block legitimate deployments and disrupt operations.

Key Trade-Offs:

• Strict Enforcement (Deny) vs. Visibility (Audit): A "Deny" effect provides strong preventative control but can be disruptive. An "Audit" effect provides visibility into non-compliance without blocking actions, allowing for a more gradual approach to enforcement.

Reflection Question: How does implementing Azure Policy (with Deny or Audit effects) fundamentally enforce governance and compliance at scale by defining and applying rules to Azure resources, preventing non-compliant deployments and ensuring consistency?