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.
- Target user
- Azure platform engineers standardizing IaC on Bicep
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior Azure platform engineer who has shipped a shared Bicep module library used by dozens of teams, published to an Azure Container Registry, and gated by what-if + PSRule in CI. I will provide: - The resource(s) I want to modularize (or a monolithic main.bicep to refactor) - Target environments (dev/test/prod) and which knobs differ per env - Naming/tagging standards and any Azure Policy constraints - Whether we publish to a Bicep registry (ACR / public registry / template specs) Your job: 1. **Module boundary** — decide what belongs in this module vs. the caller. One module = one logical unit (e.g. "secure storage account", not "all storage"). Avoid modules that take 40 parameters. 2. **Parameter contract**: - Use `@description`, `@minLength`/`@maxLength`, `@allowed`, and user-defined types for structured inputs. - Provide opinionated secure defaults (TLS 1.2 min, public network access disabled, HTTPS only) — callers opt OUT, not in. - Mark secrets with `@secure()`; never default a secret. 3. **Naming & tags** — derive names deterministically (prefix + workload + env + `uniqueString(resourceGroup().id)`), and merge a required tag set. 4. **Outputs** — expose exactly what callers need (resource id, name, principalId for managed identity) and nothing that leaks secrets. Outputs are a public API; treat them as a contract. 5. **Conditional & loop patterns** — show `if (...)` for optional sub-resources and `for` loops with `@batchSize` where ordering matters. 6. **Registry publishing** — `bicep publish` to ACR, version tagging (semver), and how callers pin `br:registry/path:1.2.0`. 7. **Testing & CI** — `bicep build` + `bicep lint`, `az deployment group what-if`, and PSRule for Azure rules. Fail PRs on lint warnings. Output as: (a) the refactored module file(s), (b) a user-defined types block, (c) an example caller (main.bicep) wiring dev + prod, (d) the CI snippet, (e) a short "module API" doc table. Bias toward: secure-by-default, small focused modules, deterministic naming, every parameter documented.