Bicep existing Resources & Scope Targeting Review Prompt
Audit a Bicep deployment's use of the existing keyword and deployment scopes so references resolve to real resources and modules target the correct subscription, resource group, or management group.
- Target user
- Azure platform engineers writing multi-scope Bicep deployments
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure infrastructure engineer who has debugged enough "resource not found" and "scope mismatch" Bicep failures to review for them on sight. I will provide: - A Bicep template or module set that references pre-existing resources and/or deploys across scopes. - The intended target scope(s): [SUBSCRIPTION / RESOURCE GROUP / MANAGEMENT GROUP / TENANT]. - Any cross-resource-group or cross-subscription references involved. Your job: 1. **Audit every `existing` reference** — confirm each one supplies the right `name`, `scope`, and (where needed) `subscriptionId`/`resourceGroup`, so it resolves to the real resource instead of trying to create a duplicate. 2. **Verify deployment scope** — check the `targetScope` declaration matches how the file is invoked and how its modules set `scope:`; flag any module deploying to the wrong level. 3. **Trace cross-scope outputs** — ensure outputs from a resource-group-scoped module are consumed correctly by a subscription-scoped parent (and vice versa) without circular scope references. 4. **Catch silent creates** — identify any place where a missing `existing` keyword means Bicep would try to CREATE a resource the team meant only to reference. 5. **Check RBAC and naming implications** — note where a scope choice changes which identity needs permissions or which naming/uniqueness constraints apply. 6. **Recommend what-if** — specify the exact `az deployment <scope> what-if` command to preview the change at each scope before applying. Output as: (a) a findings table (file, line, issue, severity, fix), (b) corrected snippets, (c) the per-scope what-if commands, (d) a one-line summary of the riskiest finding. Do not deploy. End every review with the what-if command the team should run to confirm no unexpected creates or deletes before applying.
Why this prompt works
The two failure modes that dominate real Bicep deployments are scope confusion and the missing existing keyword, and they’re insidious because both produce confident-looking templates that fail (or worse, succeed destructively) only at deploy time. A reference without existing doesn’t error in the editor — it quietly becomes a create, which is how teams end up overwriting a shared resource that they only meant to read an output from. This prompt makes the model audit every reference for that exact trap, and to call out silent creates as their own finding category.
Scope targeting is the other half. Bicep lets you declare targetScope and set per-module scope:, but the rules for passing outputs between a subscription-scoped parent and resource-group-scoped child are subtle, and getting them wrong yields opaque “scope mismatch” errors. By forcing the review to trace cross-scope outputs and confirm targetScope matches the actual invocation, the prompt catches the structural bugs that only manifest when someone runs the deployment at the wrong level. It also connects scope to the things scope actually changes — RBAC requirements and naming uniqueness — which is where a “correct” template still fails on permissions.
The non-negotiable closing instruction is what-if. Azure’s az deployment what-if is the equivalent of terraform plan for ARM/Bicep, and it’s the only reliable way to confirm that a change will reference rather than recreate, and won’t delete anything unexpected. By making the prompt end every review with the exact per-scope command, you keep a human in the loop with real data before any apply. Pair it with the Bicep module authoring prompt and the deployment stacks & what-if prompt, and see the IaC category for more Azure tooling.
Related prompts
-
Azure Bicep Module Authoring Prompt
Design clean, reusable Azure Bicep modules with typed parameters, sane defaults, output contracts, and a registry publishing flow — instead of one sprawling main.bicep per environment.
-
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.