Deployment stack does not delete old role assignments when name changes

[Rick-van-Dam]

Describe the bug
We changed the name of a Microsoft.Authorization/roleAssignments@2022-04-01 from name: guid(keyVaultName, roleName, identity.name, subscription().subscriptionId, env) to name: guid(kv.id, roleIdToAssign, identity.principalId) and noticed that the old role assignment is not deleted. This then results in this error:

{
            "code": "RoleAssignmentExists",
            "message": "The role assignment already exists."
}

To Reproduce

1. Deploy a roleassignment using a deployment stack
2. Change name of roleassignment
3. Notice the old assignment is nog deleted and you get an error due to duplicate role assignments

Additional context
This is the part of the build that invokes bicep:

                - task: AzureCLI@2
                  displayName: "Deploy Bicep stack template in ${{ parameters.location }}"
                  inputs:
                    connectedServiceNameARM: ${{ variables.azureSubscription }}
                    scriptType: "pscore"
                    scriptLocation: "inlineScript"
                    inlineScript: |
                      az stack sub create `
                      --location ${{ parameters.location }} `
                      --name ${{ variables.deploymentStackName }} `
                      --template-file ${{ variables.templateFilePath }} `
                      --action-on-unmanage deleteAll `
                      --deny-settings-mode none `
                      $(deploymentArguments) `
                      --verbose

[slavizh]

This is by design. The deletion happens when the resources in the template are deployed not before that. Due to role assignments resource does not allow a role assignment that has the same certain properties to exists with different name you get the error. The issue if any is with the role assignments resource provider. Workaround is to remove the role assignment resource from your template, deploy the stack (that will delete the role assignment at the end), add back the role assignment resource with different name and re-deploy the stack.

[Rick-van-Dam]

Thats quite a hassle and results in longer downtime. Are there any plans to improve this?

[slavizh]

@Rick-van-Dam that is for the bicep team to respond as I am not part of Microsoft. Most likely unlikely due to the reason for the deletion process to be at the end is to guarantee that everything with the deployment was done successfully before proceeding to deletion of unmanaged resources.

[azcloudfarmer]

The goal of Deployment Stacks is to guarantee that the new deployment succeeds before any deletion of resources no longer managed. This is by design because any other implementation would risk downtime for resources being re-deployed.