Avoid shared Bicep module deployment names in concurrent runs

Source facts

Microsoft warns that concurrent deployments of a module with the same fixed name at the same scope can interfere with each other’s outputs. Its example involves two Bicep files targeting one resource group; a deployment can show an output belonging to the other run.

The module’s optional name becomes the nested deployment resource name. Omitting it produces a generated GUID. Microsoft also describes explicitly unique names as a way to avoid the collision. Microsoft Learn.

Applicability

Review pipelines that can overlap in one scope, including manual reruns and independent applications sharing a resource group. Inspect the module deployment name rather than assuming a different parent file gives the nested deployment a different identity.

DSE recommendation

DSE recommends choosing and documenting one collision-avoidance convention. Prefer the generated name where no stable explicit name is needed; otherwise require a demonstrably unique value for each overlapping run. Review downstream consumers of module outputs before changing the convention, and retain deployment identifiers in the release evidence.

Verification

Use a controlled concurrent deployment test with distinguishable expected outputs. Confirm each parent receives its own module result and that the resulting nested deployment names differ. Also test an ordinary single run. Keep the two deployment identifiers and sanitized output comparison so an intermittent collision cannot be mistaken for an application configuration error.

Official references

Microsoft Learn: Bicep modules. Source retrieved September 9, 2026.