Azure Operations, Calmly

The thirty seconds that catch template surprises before they happen (Rule 4).

az deployment group what-if --resource-group {{resource_group}} --template-file {{template_file}} --parameters {{parameters_file}}

Prerequisites:

az CLI logged in; template + parameters for the real run

Run from:

IaC repo root

Expected output:

Color-coded Create/Modify/Delete preview

Success looks like:

Zero unexpected deletes or modifies in the preview

Follows Rule 4

Who owns what — the first question of every incident and every cost review.

az resource list --tag owner={{owner}} --query "[].{name:name, type:type, rg:resourceGroup}" -o table

Prerequisites:

az CLI logged in

Run from:

Anywhere

Expected output:

Table of the owner's resources

Success looks like:

The list matches what the owner thinks they own

Rule 6, as one line.

az lock create --name {{lock_name}} --resource-group {{resource_group}} --lock-type CanNotDelete

Prerequisites:

Owner or User Access Administrator on the group

Run from:

Anywhere

Expected output:

Lock created

Success looks like:

az lock list on the group shows it

Follows Rule 6

The point of no return — everything inside goes with it. Run the decommission recipe first, not after.

az group delete --name {{resource_group}} --yes --no-wait

Careful: Irreversible for most resource types. --yes skips the confirmation; the recipe IS the confirmation.

Prerequisites:

The decommission recipe completed: contents listed, locks cleared, backups exported, soft-delete afterlife understood

Run from:

Anywhere

Expected output:

Deletion accepted (async)

Success looks like:

Group gone from az group list; no orphaned soft-deleted resources still billing

Follows Rule 8

Tear down a system so that nothing breaks elsewhere, nothing keeps billing from beyond the grave, and there is a way back for the first week.

Prerequisites:

Confirmation from the owner tag's human that the system is dead; a decommission ticket; access to the group

Permissions:

Contributor on the group plus lock-management rights (Owner/UAA) if locks exist

Starting state:

The group still running, expiry tag past due

Tools:

az >=2.60

1. 1.RunInventory what you are about to burn

   az resource list --resource-group {{resource_group}} -o table

   Expect:

   Full contents listed in the ticket

   Verify:

   The owner confirms nothing on the list is a surprise

2. 2.CheckHunt external references

   Search other groups for pointers into this one: private endpoints, VNet peerings, Key Vault references in app settings, DNS records, pipeline service connections. The group's contents can be deleted; the things pointing AT them break.

   Expect:

   A written "referenced by" list, each entry resolved or accepted

   Verify:

   Nothing outside the group calls into it anymore

3. 3.RunExport the template as a fallback

   az group export --name {{resource_group}} > {{archive_path}}

   Expect:

   ARM template archived with the ticket

   Verify:

   File is valid JSON and non-trivial in size

   If it fails here…

   Export skips some resource types (it warns) — note the skips in the ticket; they are what you cannot restore from template alone.

4. 4.CheckIdentify the soft-delete residents

   Key Vaults, Recovery Services vaults, and Cognitive/OpenAI accounts do not fully die with the group — they enter soft-delete, keep their name reserved, and some keep billing. List them now and decide: purge after delete, or keep the recovery window.

   Expect:

   Per-resident decision recorded: purge or retain

   Verify:

   Every soft-delete-capable resource in the step-1 inventory has a decision

5. 5.RunClear the locksoptionalonly when locks exist on the group (they should, if it was prod — Rule 6)

   az lock list --resource-group {{resource_group}} -o table az lock delete --name {{lock_name}} --resource-group {{resource_group}}

   Expect:

   No locks remain on the group

   Verify:

   az lock list returns empty

6. 6.RunDelete the group
   ⌘4Delete a resource groupbash⚠ Destructive⚠ Privileged

   az group delete --name {{resource_group}} --yes --no-wait

   resource_group

   Copy commandfill {{resource_group}} to copy

   Everything above was the confirmation. This is the action.

   Expect:

   Deletion accepted and completes

   Verify:

   az group exists --name returns false

   If it fails here… (1 known failure)

   A delete that fails halfway usually hit a lock on a nested resource — see the attached failure note.

   ⚠ Group delete fails partway: hidden lock on a nested resource

   Deletion runs for minutes then fails; some resources gone, others remain; error cites a lock

   Likely cause: Resource-level locks are separate from group-level locks and az lock list at group scope can be filtered oddly by inherited vs direct

   Fix: Delete the resource-level locks, re-run the group delete. The half-deleted state is safe to re-run; delete is idempotent.

7. 7.CheckPost-delete sweep: the afterlife audit

   az keyvault list-deleted and the equivalent for other soft-delete types; purge the ones marked purge in step 4. Then check the subscription's cost analysis a week later — the line for this system should be zero, not merely smaller.

   Expect:

   No unintended soft-deleted residents; cost line trending to zero

   Verify:

   Cost analysis for the system's tags shows no residual charges after 7 days

   If it fails here… (1 known failure)

   A "deleted" vault still billing = soft delete kept it alive — see the attached failure note.

   ⚠ The deleted resource group that kept billing

   Weeks later the subscription still shows charges for the "deleted" system

   Likely cause: Soft-deleted vaults/accounts retain reserved capacity or storage that bills during the retention window

   Fix: Purge the soft-deleted residents (az keyvault purge / account purge) where policy allows. Add the step-7 afterlife audit to every decommission.

Success looks like:

Group deleted, external references confirmed dead beforehand, exported template archived, no soft-deleted residents still billing

Rollback:

Within the recovery window: redeploy the exported template into a new group and restore data from the pre-delete backups. Soft-deleted vaults can be recovered with az keyvault recover.

Implements Rule 2, Rule 8

You cannot create a new vault with the same name until the soft-deleted one is purged or expires — which surprises every pipeline that tears down and recreates by fixed name. Either purge deliberately (audit first: purge protection may forbid it) or generate unique vault names.

what-if sometimes reports noise-level modifies (tag ordering, identity blocks) that the deploy won't actually change. Learn your templates' known-noise signature — the danger is alert fatigue making someone skim past a real delete one day.