# Avoid shared Bicep module deployment names in concurrent runs

> Prevent one deployment's module outputs from being confused with another run targeting the same scope.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-212-avoid-shared-bicep-module-deployment-names-in-concurrent-runs/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:28:24+00:00
- Modified: 2026-09-10T01:20:45+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Prevent one deployment's module outputs from being confused with another run targeting the same scope.

## Potentially affected

Bicep deployments running modules concurrently at the same target scope.

## DSE recommendation

Omit the optional module deployment name or make it unique for each concurrent deployment.

## Article

## 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](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules).

## 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](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules). Source retrieved September 9, 2026.

## Primary reference

- Name: Bicep modules - Azure Resource Manager | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Avoid shared Bicep module deployment names in concurrent runs,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-212-avoid-shared-bicep-module-deployment-names-in-concurrent-runs/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.