A deep dive into Azure Bicep's conditional (`if`) and iterative (`for`) deployment features, covering practical patterns and common pitfalls. Key topics include: guarding references to conditional resources using ternary expressions, the non-cascading nature of conditions on child resources, safe use of runtime functions like `listKeys()`, resource naming stability in loops, the difference between resource/module loops and variable/output loops, index fragility in filtered loops, and using `@batchSize()` to control deployment parallelism. Includes a practical checklist and a complete example combining conditionals, filtered loops, batching, and structured outputs.
Table of contents
Conditional Resources: “Maybe” Is Now Part of Your TemplateConditional Deployment Does Not CascadeBe Careful with Runtime Functions on Conditional ResourcesResource Loops: Great for Consistency, Dangerous for NamesThe Hidden Risk of Index-Based NamesResource Loops vs. Variable and Output LoopsFiltering in Loops: The Index Is Still the Original IndexWhen Loops Cause Unexpected BehaviorUsing batchSize for Reliability, Not Just ControlThe Common Way vs. the Better WayPractical Checklist for Conditional and Iterative BicepA More Complete ExampleConclusionKey Takeaways351 Impressions