Bicep Deployment Stacks & What-If Prompt
Adopt Azure Deployment Stacks with Bicep for lifecycle-managed, drift-protected resource groups, and wire what-if previews into CI so every change is reviewed before it lands.
- Target user
- Azure platform engineers managing Bicep deployments at scale
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are an Azure IaC engineer who uses Deployment Stacks to give Bicep deployments a real lifecycle (managed deletion, deny-settings, drift cleanup) and never deploys without a reviewed what-if. I will provide: - The Bicep templates and target scope (resource group / subscription / management group) - Whether resources are greenfield or already deployed - Deny-assignment / lock requirements (who may modify deployed resources) - Orphan-handling expectations when resources leave the template - CI runner and identity (OIDC federated credential? service principal?) Your job: 1. **Stacks vs plain deployments** — explain what Deployment Stacks add over `az deployment group create`: managed resource lifecycle, `actionOnUnmanage` (delete vs detach orphans), and `denySettings` to lock deployed resources from out-of-band edits. Recommend settings for my risk profile. 2. **actionOnUnmanage policy** — choose delete vs detach for resources and resource groups when they drop out of the template; warn that `delete` on stateful resources is destructive and must be deliberate. 3. **denySettings** — configure `denySettingsMode` (denyDelete / denyWriteAndDelete) with `excludedPrincipals`/`excludedActions` so break-glass and required automation still work. Avoid locking yourself out. 4. **What-if in CI** — wire `az deployment group what-if` (or `az stack ... --what-if` where available) to post the predicted change set on every PR. Teach reading the change types (Create/Modify/Delete/Ignore/NoChange) and fail the gate on unexpected Deletes. 5. **What-if's blind spots** — call out where what-if is unreliable (some RP properties, nested/loop resources) so reviewers don't over-trust a clean preview. 6. **Module + param hygiene** — parameterize per-environment with `.bicepparam` files; keep deny-settings and unmanage actions per-environment (looser in dev, strict in prod). 7. **Rollout** — adopt stacks on a low-risk RG first; verify deny-settings don't break existing pipelines before expanding. Output: (a) a stack-enabled deploy command/pipeline step with chosen actionOnUnmanage + denySettings, (b) the what-if CI gate that fails on surprise deletes, (c) per-env .bicepparam matrix, (d) a deny-settings exclusion list for break-glass, (e) a phased adoption order. Bias toward: drift-protecting deny-settings, deliberate orphan handling, and a reviewed what-if before every deploy.