Bicep部署存储账户首次成功 重新部署default blob服务报前置条件失败

• 本次出现的ContainerOperationFailure错误本质是ETag校验失败：Bicep部署存储账户的blob服务子资源时，默认会在请求头携带上一次部署记录的资源ETag值，仅当服务端当前ETag与请求携带的ETag匹配时才会执行更新，用于避免并发修改冲突。如果两次部署之间，该存储账户的blob服务配置被其他操作（比如Azure门户手动修改、其他自动化脚本更新）改动过，ETag发生变化，就会触发该校验失败。
• 此外你使用的2021-04-01版本Microsoft.Storage/storageAccounts/blobServicesAPI存在已知缺陷：当开启blob还原策略（restorePolicy）时，即使没有修改任何配置，增量重部署也会误触发ETag校验失败。

可按优先级尝试以下修复方法：

1. 给blob服务资源添加跳过ETag校验属性
   在blob_default资源定义中新增skipETagCheck: true属性，直接跳过ETag校验逻辑，适合无并发修改防控需求的场景，修改后的模板片段如下：

resource blob_default 'Microsoft.Storage/storageAccounts/blobServices@2021-04-01' = {
    name: 'default'
    parent: stg
    skipETagCheck: true // 新增该行跳过ETag校验
    properties: {
      changeFeed: {
        enabled: true
      }
      restorePolicy : {
        enabled: true
        days: 6
      }
      containerDeleteRetentionPolicy: {
        enabled: true
        days: 7
      }
      cors: {
        corsRules: []
      }
      deleteRetentionPolicy: {
        enabled: true
        days: 7        
      }
      isVersioningEnabled: true
    }
}

注意：开启跳过ETag校验后，部署会直接覆盖服务端当前的blob服务配置，如果你存在多渠道修改存储账户配置的场景，需要谨慎使用该配置。

2. 升级blob服务资源的API版本
   将API版本升级到2022-05-01及以上，微软已经在后续版本修复了开启还原策略时增量部署误报错的问题，无需额外添加其他属性即可正常重部署。

3. 对齐模板配置与线上实际配置
   如果两次部署之间有手动修改过存储账户的blob服务配置，先将模板中的配置值调整为和线上当前配置一致，再执行部署，避免配置差异导致的校验异常。

内容的提问来源于stack exchange，提问作者anuj khosla