Databricks Bicep部署突然失败，遇principalId筛选器不支持错误

报错原因分析 #

你遇到的The filter 'principalId eq ''' is not supported报错，本质是Azure Databricks服务的权限验证逻辑更新导致的。虽然之前部署时无需手动指定principalId，但当前版本的API在引用已存在的托管资源组时，会尝试验证权限，而脚本中existing方式引用托管资源组的逻辑，导致权限检查时出现空的principalId过滤条件，触发报错。

部署脚本修复方案 #

最可靠的解决方式是让Databricks服务自动创建托管资源组，而非手动提前创建后引用。修改后的Bicep脚本如下：

var managedResourceGroupName = 'rg-metadata-${dataBricksName}'

resource databrickworkspace 'Microsoft.Databricks/workspaces@2018-04-01' = {
  name: dataBrickName
  location: location
  sku: {
    name: dataBrickPricingTier
  }
  properties: {
    // 替换为托管资源组名称，而非引用已存在的资源组ID
    managedResourceGroupName: managedResourceGroupName
    parameters: {
      enableNoPublicIp: {
        value: disablePublicIp
      }
    }
  }
}

为什么这样修改？ #

Databricks工作区的托管资源组需要特定的权限配置（授予Databricks服务主体管理权限），手动创建并引用的方式会跳过这些自动配置步骤，导致权限验证失败。让服务自动创建托管资源组，会自动完成所有必要的权限绑定，避免此类报错。

失败状态工作区删除方案 #

如果已经存在无法正常删除的失败工作区，可按以下步骤尝试：

1. 使用Azure CLI强制删除：

az databricks workspace delete --name <你的工作区名称> --resource-group <所属资源组名称> --yes --force

2. 若CLI操作失败，登录Azure门户，进入工作区所属资源组，找到失败的Databricks资源，尝试删除时勾选强制删除选项（部分场景下可见）。
3. 以上方法均无效时，提交Azure技术支持工单，请求后台清理异常资源。

内容的提问来源于stack exchange，提问作者Saugat Mukherjee