Azure Bicep：az what-if输出噪音处理的最佳实践咨询

我正在从零开始部署包含应用程序网关、AKS集群、托管标识等资源的Azure环境，执行az what-if时遇到了不少意外的输出噪音。已知官方正在优化该功能，但想明确现阶段的最佳处理实践：

• 是否要在模板中复制这些变化来消除噪音？
• 是否需要跟踪历史what-if输出并对比来识别实际变更？
• 是否应该分阶段部署，把噪音部分和干净部分分开？
• ...

常见噪音类型与疑问 #

1. 默认属性：模板未指定的默认属性（比如managedCluster的properties.networkProfile.ipFamilies == 'IPv4'），可以通过在模板中添加该属性消除噪音。
2. 外部影响：外部创建的VNet对等连接会在what-if输出中显示为properties.virtualNetworkPeerings的变更噪音，已知重新部署不会删除这些对等连接，但想明确Azure在什么情况下不会覆盖此类外部变更，相关规则说明在哪里？
3. 引用问题：比如properties.principalId: "a09185a3d" => "[reference(resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('test-mi')), '2018-11-30').principalId]"，这类属于已标记待修复的Bug。
4. 双向信息：比如配置资源访问VNet时，会同时在VNet和资源侧显示引用变更，这类冗余信息无需添加到模板中。

简洁工作流实现技巧 #

• 默认属性按需固化：对于频繁出现的默认属性噪音，直接在模板中显式声明对应值，既能消除噪音，也能避免未来默认值变更带来的意外影响。
• 过滤外部变更噪音：对于外部创建的资源变更（如VNet对等连接），可使用az what-if的--exclude参数过滤特定属性或资源的输出；Azure遵循增量部署模型，只要模板中未定义该属性（或未设置为null），就不会覆盖外部对该属性的修改，这是ARM模板的核心规则。
• 忽略已知Bug类噪音：对于官方已标记待修复的引用类Bug，直接跳过此类噪音，重点关注其他实际变更。
• 避免冗余双向配置：对于双向关联的资源（如VNet与资源的访问配置），只需在模板中维护一侧的配置逻辑即可，无需重复添加双向信息，减少噪音源。
• 历史输出对比辅助：如果噪音较多，可将每次what-if输出保存为文件，通过diff工具对比历史版本，快速定位实际变更；也可结合CI/CD工具的变更记录辅助识别。
• 分阶段部署优化：将易产生噪音的资源（如依赖外部变更的VNet）与核心业务资源（如AKS、应用网关）分阶段部署，单独对核心资源执行what-if，减少干扰。

内容的提问来源于stack exchange，提问作者Joachim Nielandt