Check for previous/existing GitHub issues
Issue Type?
Bug
(Optional) Module Version
0.5.3
(Optional) Correlation Id
No response
Description
Issue:
When using this module with an azurerm_management_lock applied to the storage account, Terraform is unable to destroy the full infrastructure due to incorrect deletion order. The internal resource dependencies do not account for the lock, which causes dependent resources like azurerm_role_assignment or azurerm_private_endpoint to fail deletion attempts while the lock is still in place.
How to Reproduce:
module "storage_account" {
source = "Azure/avm-res-storage-storageaccount/azurerm"
version = "0.5.3"
name = "mystorageacct"
# other required params
}
resource "azurerm_management_lock" "example" {
name = "CannotDelete"
scope = module.storage_account.resource_id
lock_level = "CanNotDelete"
}
resource "azurerm_role_assignment" "example" {
principal_id = "..."
role_definition_name = "Storage Blob Data Contributor"
scope = module.storage_account.resource_id
}
terraform apply → succeeds
terraform destroy → fails with lock-related error
Expected Behavior:
The management lock should be deleted first, and only then should dependent resources and the storage account be removed.
Actual Behavior:
Terraform attempts to delete resources like azurerm_role_assignment and azurerm_private_endpoint before the lock, causing deletion to fail due to an active lock.
Suggested Fix:
Introduce depends_on relationships to enforce proper destroy order between the management lock and its dependent resources. Alternatively, expose outputs or variables that make it easier for consumers to wire these dependencies manually.
Check for previous/existing GitHub issues
Issue Type?
Bug
(Optional) Module Version
0.5.3
(Optional) Correlation Id
No response
Description
Issue:
When using this module with an azurerm_management_lock applied to the storage account, Terraform is unable to destroy the full infrastructure due to incorrect deletion order. The internal resource dependencies do not account for the lock, which causes dependent resources like azurerm_role_assignment or azurerm_private_endpoint to fail deletion attempts while the lock is still in place.
How to Reproduce:
terraform apply → succeeds
terraform destroy → fails with lock-related error
Expected Behavior:
The management lock should be deleted first, and only then should dependent resources and the storage account be removed.
Actual Behavior:
Terraform attempts to delete resources like azurerm_role_assignment and azurerm_private_endpoint before the lock, causing deletion to fail due to an active lock.
Suggested Fix:
Introduce depends_on relationships to enforce proper destroy order between the management lock and its dependent resources. Alternatively, expose outputs or variables that make it easier for consumers to wire these dependencies manually.