Make the wrong thing impossible.

Azure ships hundreds of built-in policies, and you can write your own. The lever that matters is the effect. An Audit policy tells you, later, that something is wrong — useful, but the bad thing already exists. A Deny policy refuses the create outright, so the non-compliant resource never comes into being. This lab uses Deny, because it is both the stronger control and the one you can prove on the spot: you will try to create a storage account with public blob access and watch Azure reject it, then create a compliant one and watch it succeed. Guardrails, not a report you read after the incident.

A rule you can't break beats a rule you're told to keep.

# Windows/Git Bash: stop it mangling /subscriptions/... arguments (harmless on macOS/Linux)
export MSYS_NO_PATHCONV=1

SUFFIX=$RANDOM
RG="campux-lab-policy-rg"
LOCATION="eastus"
DEF_NAME="campux-deny-public-blob"
ASSIGN_NAME="campux-deny-public-blob"

SUB=$(az account show --query id -o tsv)
RG_SCOPE="/subscriptions/$SUB/resourceGroups/$RG"
BAD_SA="campuxbad$SUFFIX"        # 3-24 lowercase alphanumeric
GOOD_SA="campuxgood$SUFFIX"

az group create --name "$RG" --location "$LOCATION"

You don't always write your own. Assign a built-in that audits storage accounts lacking secure transfer — looked up by display name so there's no fragile hard-coded ID.

BUILTIN=$(az policy definition list \
  --query "[?displayName=='Secure transfer to storage accounts should be enabled'].name | [0]" -o tsv)
[ -n "$BUILTIN" ] || echo "!! built-in not found — display name may have changed"

az policy assignment create \
  --name "campux-secure-transfer" \
  --policy "$BUILTIN" \
  --scope "$RG_SCOPE"

The real skill: a rule that denies any storage account with public blob access enabled — if (type is storage account AND allowBlobPublicAccess == true) then deny.

az policy definition create \
  --name "$DEF_NAME" \
  --display-name "Campux: deny storage accounts with public blob access" \
  --description "Denies creation of storage accounts that allow public blob access." \
  --mode Indexed \
  --rules "{ 'if': { 'allOf': [ { 'field': 'type', 'equals': 'Microsoft.Storage/storageAccounts' }, { 'field': 'Microsoft.Storage/storageAccounts/allowBlobPublicAccess', 'equals': 'true' } ] }, 'then': { 'effect': 'deny' } }"

az policy assignment create \
  --name "$ASSIGN_NAME" \
  --policy "$DEF_NAME" \
  --scope "$RG_SCOPE"

Try to create a public-blob storage account — it must be denied. A freshly-assigned policy takes a few minutes to start enforcing, so this loop retries until it's actually blocked (cleaning up anything that slips through while it propagates):

for i in $(seq 1 20); do
  if az storage account create --name "$BAD_SA" --resource-group "$RG" \
       --location "$LOCATION" --sku Standard_LRS --allow-blob-public-access true -o none 2>/tmp/policyerr; then
    echo "attempt $i: not blocked yet — policy still propagating. Deleting and waiting 30s."
    az storage account delete --name "$BAD_SA" --resource-group "$RG" --yes -o none
    sleep 30
  else
    if grep -qi "RequestDisallowedByPolicy\|disallowed by policy" /tmp/policyerr; then
      echo ">>> DENIED on attempt $i — the policy is enforcing."; break
    else
      echo "attempt $i: failed for a NON-policy reason (not proof):"; cat /tmp/policyerr
      az storage account delete --name "$BAD_SA" --resource-group "$RG" --yes -o none 2>/dev/null; sleep 30
    fi
  fi
done

Now the compliant one — public blob access disabled — must succeed:

az storage account create --name "$GOOD_SA" --resource-group "$RG" \
  --location "$LOCATION" --sku Standard_LRS --allow-blob-public-access false -o none \
  && echo ">>> CREATED — compliant storage account allowed."

Clicking policies into the portal doesn't scale or survive an audit. The Bicep version declares the same custom definition and assignment as code. Unlike the identity labs, policy is fully ARM-native, so the whole thing is Bicep — no Graph split. One scope note: policy definitions live at subscription (or management-group) level, so that template targets the subscription, not a resource group.

Assignments and definitions are not inside the resource group — delete them explicitly, then the group.

az policy assignment delete --name "$ASSIGN_NAME" --scope "$RG_SCOPE"
az policy assignment delete --name "campux-secure-transfer" --scope "$RG_SCOPE"
az policy definition delete --name "$DEF_NAME"
az group delete --name "$RG" --yes

You authored and assigned a custom Azure Policy with a Deny effect to enforce storage security, proved it blocks a non-compliant resource while allowing a good one, and saw how the same governance is deployed as code. Keep four things: policy enforces at creation time, so Deny makes a bad configuration impossible rather than merely discouraged; built-ins cover most needs, and when none fits you write an if/then rule with an effect; effects matter — Audit reports, Deny blocks; and scope controls blast radius — definitions at subscription or management-group level, assignments at a subscription, resource group, or below. This completes the Identity & Governance track. Its companion is the Resource Locks lab: policy stops non-compliant creation, locks stop deletion.