Module Issue: Storage Account - Incorrect Handling of denyEncryptionScopeOverride Parameter

[PetterHL]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Bug

Module Name

avm/res/storage/storage-account

(Optional) Module Version

0.15.2

Description

Issue Summary:

When deploying the Storage Account module with a Blob container, the denyEncryptionScopeOverride parameter in the container's main.bicep template is incorrectly being set to null instead of explicitly retaining the expected false value when configured as such.

This behavior causes potential misconfigurations when deployed on a existing storage account that already has this variable set to false, as you are not allowed to change this property after its creation.

I got this to work on a local verison of the module by changing the property as stated in the Proposed Fix

---

Steps to Reproduce:

1. Deploy a storag account with this property set to false. And then deploy the Storage account AVM module with the same config as the previous storage account:

   denyEncryptionScopeOverride = false

Check the resulting configuration of the container in Azure Portal or via CLI/PowerShell.

Expected Behavior:
The denyEncryptionScopeOverride parameter should explicitly retain the false value in the deployed resource configuration.

Actual Behavior:
The parameter is set to null in the deployed configuration, which is not equivalent to false. And throws the error:

   Container encryption policy missing header: x-ms-default-encryption-scope and x-ms-deny-encryption-scope-override are required

Impact:
Unable to deploy moduel on already existing Storage account with the denyEncryptionScopeOverride = false.

Proposed Fix:

denyEncryptionScopeOverride: denyEncryptionScopeOverride 

(Optional) Correlation Id

No response

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[AlexanderSehr]

Hey @PetterHL,
sorry for the late response. It seems this issue was not created as a module issue for the storage account module which is why the automatic owner assignment (in this case @ktremain) did not not kick in.
The owner will triage the issue and plan when to address it - but you're of course also more than well come to contribute back to the library if you want and can meet the steps of the contribution guide :)
In any case, thanks for raising this issue 💪