Bicep doesn't delete storage container when commenting it out

[mostafaSbakr]

Bicep version Bicep CLI version 0.20.4

I have an Azure Bicep template that deploys a storage account and a container. However, when I rename the container or comment out the container resource in the template, the delete operation is not triggered. Instead, it creates a new container and does not delete the old one. I use Mode Complete to deploy. Any idea why this happens?

To Reproduce I have a main.bicep file containing

param location string = resourceGroup().location

param storageAccountName string = 'test${uniqueString('newstring')}'
param storageContainerName string = 'testcontainer'

module storagAccounts '../resources/storage/storageAccounts.bicep' = {
  name: 'storageAccounts'
  params: {
     location: location
     storageAccountName: storageAccountName
  } 
}

module blobServices '../resources/storage/blobServices.bicep' = {
name: 'blobServices'
params: {
  storageAccountName: storagAccounts.outputs.storageAccountName
 }
}

module blobContainer '../resources/storage/containers.bicep' = {
 name: 'blobContainer'
 params: {
   containerName: storageContainerName
   blobServicesName: blobServices.outputs.blobServicesName
   storageAccountName: storagAccounts.outputs.storageAccountName
 }
}

storageAccounts.bicep containing

targetScope = 'resourceGroup'

@minLength(3)
@maxLength(24)
param storageAccountName string

param location string

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }

  tags: {
    environment: 'test'
  }

}

output storageAccountId string = storageAccount.id
output storageAccountName string = storageAccountName

blobServices.bicep containing

param storageAccountName string 
param blobServicesName string = 'default'

resource blobServices 'Microsoft.Storage/storageAccounts/blobServices@2023-01-01' = {
  name: '${storageAccountName}/${blobServicesName}'
}

output blobServicesName string = blobServicesName

and a container.bicep containing

param storageAccountName string
param blobServicesName string
param containerName string

resource storageContainer 'Microsoft.Storage/storageAccounts/blobServices/containers@2023-01-01' = {
  name: '${storageAccountName}/${blobServicesName}/${containerName}'
  properties: {
    publicAccess: 'None'
  }
}

output storageContainerName string = storageContainer.name

To deploy I use a PowerShell command

New-AzResourceGroupDeployment -Name deployment1 -Mode Complete -Location westeurope -TemplateFile modules/main.bicep -ResourceGroup testResourceGroup -Force

[alex-frankel]

Instead of complete mode, which has a variety of limitations, we are now encouraging you to use Deployment Stacks which should give you the behavior you are looking for. Can you give that a try and let us know if it works for you?

@azcloudfarmer / @mumian -- should we update the "Complete Mode" docs to clarify this?

[mostafaSbakr]

Thanks for the reply. However, using New-AzResourceGroupDeploymentStack -Name dep1 -ResourceGroupName testResourceGroup -TemplateFile modules/main.bicep -DenySettingsMode none -Force then commenting out the module call for the container resource also fails to trigger the delete operation. Also, renaming the container creates a new one without deleting the old one.

[alex-frankel]

My guess is that because there are modules being deployed to a parallel scope (RG -> other RG), we are not counting resources in the parallel RG as "managed". Does that sound right @snarkywolverine / @azcloudfarmer Can you try starting the deployment from the parent subscription (targetScope = 'subscription') and seeing if delete happens in that case?

[dantedallag]

@mostafaSbakr by default, when updating an existing stack (New/Set), we detach unmanaged resources from the stack, but don't delete them. If you would like to cleanup the resources that become unmanaged, you can specify the -DeleteResources switch when running the command. You can read more about this behavior in the "Control detachment and deletion" section of the doc Alex linked.

[mostafaSbakr]

@dantedallag That did it, When using the -DeleteResources switch, the resources that get deleted providing it is the same DeploymentStack resource (same name). If the name of the stack is changed it does not track other stacks in the same resource group, I guess that is the default behaviour as well. Thanks for the reply