CoursesAzure securityGovernance & incident response

Azure Policy & effects

Deny, deployIfNotExists, initiatives at scale.

Advanced30 min · lesson 13 of 15

Everything else in this course is more durable as a default than as a thing each team remembers. Azure Policy is the enforcement engine that makes the non-negotiables automatic — evaluating and, where you choose, blocking or remediating resource configuration across the whole estate.

Effects: audit, deny, deployIfNotExists, modify

A policy definition targets resources by condition and applies an effect. Audit flags non-compliance without blocking; deny stops non-compliant creation at request time — a preventive guardrail; deployIfNotExists auto-provisions a missing control (say, diagnostic settings on every new resource); modify adds or changes properties (like a required tag). Group related definitions into an initiative (policy set) and assign it at a scope, so one assignment enforces a coherent baseline. Prefer deny for the non-negotiables so the misconfiguration never happens, and deployIfNotExists to make the secure default self-healing.

a preventive + a self-healing policy
# Deny effect: block any storage account that allows public blob access.
{
"if": { "allOf": [
{ "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
{ "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": true } ] },
"then": { "effect": "deny" }
}
# Assign an initiative (e.g. the Azure Security Benchmark) at a management group
# so every subscription beneath it inherits the whole baseline at once.
az policy assignment create --name asb --policy-set-definition "Azure Security Benchmark" \
--scope /providers/Microsoft.Management/managementGroups/acme-root

Policy vs RBAC — two planes

Keep the planes straight: RBAC governs who can act, Azure Policy governs what configuration is allowed to exist. They compose — RBAC lets a team deploy resources; policy ensures whatever they deploy is encrypted, private, and logged. Assigning initiatives at management-group scope means the guardrails inherit down to every current and future subscription, which is what turns a written standard into an enforced one.

Two governance planes
RBAC — who can act
role assignments at a scope
principals + permissions
deny assignments
override grants
Policy — allowed config
deny effect
block non-compliant creation
deployIfNotExists / modify
self-healing defaults
RBAC and Policy answer different questions. A secure estate uses both — scoped grants plus configuration guardrails inherited from the top.
Audit-only policy is not a control
A policy in audit mode reports non-compliance but changes nothing — the public storage account still ships. For the true non-negotiables use the deny effect so the bad configuration cannot be created, and deployIfNotExists so the secure default is applied automatically. Audit is for measuring, not for enforcing.