2.3.1. Azure Policy: Built-in and Custom Definitions
💡 First Principle: Policy lets you declare a rule once — "storage accounts must have HTTPS-only enabled," for example — and have it automatically evaluated (and optionally enforced) against every matching resource in scope, present and future, without relying on anyone remembering to check manually.
Azure ships a large library of built-in policy definitions covering common security and compliance requirements; when nothing built-in fits, you can write a custom policy definition using policy rule language to express organization-specific requirements. Definitions are grouped into initiatives (policy sets) for assigning many related policies together — most regulatory compliance standards in Defender for Cloud are implemented as initiatives under the hood. Each policy has an effect that determines what happens on a non-compliant resource: Deny blocks the deployment outright, Audit allows it but flags non-compliance, Append/Modify can automatically correct certain properties, and DeployIfNotExists can trigger a remediation deployment.
| Effect | What Happens |
|---|---|
| Deny | Blocks the non-compliant deployment or update |
| Audit | Allows the action, logs a compliance flag |
| Append / Modify | Automatically adds or corrects specific properties |
| DeployIfNotExists | Triggers a remediation deployment if a related resource is missing |
⚠️ Exam Trap: An Audit effect will never stop a non-compliant resource from being created — if a scenario requires actively preventing non-compliant deployments rather than just reporting on them, Audit is the wrong effect regardless of how well-written the policy rule is. Look for Deny when the requirement is prevention, not visibility.
Reflection Question: Why might an organization deliberately roll out a new policy with Audit first before switching it to Deny?
