Clarify requirements for <linked-deployment-name>

[sopelt]

The documentation should clarify the requirements for <linked-deployment-name> as there seem to be unexpected side-effects when deployment names are not unique in concurrent ARM operations. Without the clarification we have to assume that the name of the deployment might have to be unique to avoid "spilling links/output" between different top-level deployments.

An example (derived from a real-world scenario):

• Web App deployed in stages (e.g. dev + prod, each within a separate resource group)
• A module is used to create a CNAME in a shared resource group (providing a scope)
• If the name is statically provided (e.g. as name: 'cnameDeployment') two different top-level deployments seem to reference the same CNAME module invocation which spills the output from one stage to another.

I assume that combining the deployment().name to the module deployment name (e.g. name: '${deployment().name}-cname') should resolve this issue given that we use unique release IDs as the top-level deployment name.

I think that this quickstart sample might face this issue. I assume that when main.bicep is deployed concurrently the nested nested.flowlogs.bicep is only executed once and referenced as deployFlowLogs.

In the "best case" it seems that concurrent deployments with non-unique nested deployments cause conflicts and fail. The more problematic case would be creation/configuration of resources with wrong values spilled from other deployments.

A clarification and documented best practices for naming modules/nested deployments would be great.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: e1c1cbec-c325-f4b2-af56-6806330ad796
• Version Independent ID: 1b424365-2a0d-3d89-a989-53f20eb17c24
• Content: Bicep modules - Azure Resource Manager
• Content Source: articles/azure-resource-manager/bicep/modules.md
• Service: azure-resource-manager
• Sub-service: bicep
• GitHub Login: @mumian
• Microsoft Alias: jgao

[MonikaReddy-MSFT]

Thanks for bringing this to our attention. We will investigate it further and update you shortly.

[MonikaReddy-MSFT]

@sopelt - Thanks for bringing this to our attention. I'm going to assign this to the document author so they can update the document accordingly.

[tfitzmac]

@sopelt - thanks for this feedback. I was able to reproduce the issue of concurrent deployments with a static module name and the same scope interfering with the output. I'll add clarification to the article.

[tfitzmac]

I have added clarification to the article. It might be Monday morning before it is published.

please-close