Conceito e mecanismo
Bicep what-if antecipa mudanças e ajuda a discutir efeitos antes do deployment. Não é uma autorização nem uma garantia de cobertura total. Dependências externas e expressões não resolvidas podem impedir a análise de um recurso ou módulo; versões recentes das ferramentas apresentam diagnósticos dessas limitações. Se o módulo da base de dados ficou por analisar, a ausência de diferenças nesse módulo não prova ausência de impacto. Investiga o âmbito em falta, valida inputs e obtém evidência adicional. Um relatório com muitos recursos inalterados não compensa uma lacuna precisamente na dependência crítica. Usa o preview para melhorar a decisão, sem transformar a ferramenta num carimbo de aprovação.
Aplicação guiada
Na manutenção do pipeline, trata testes instáveis como problemas a investigar. Uma exclusão temporária precisa de owner, prazo e visibilidade da lacuna; repetir até verde e apagar falhas distorce evidência. Mede também o custo das otimizações. Se restaurar e guardar cache demora mais do que o trabalho evitado, a cache pode piorar o tempo total. Templates versionados reduzem divergência entre aplicações, mas precisam de adoção rastreada e rollout controlado. Por fim, separa espera e execução: o timeout do job começa quando executa, não quando entra em fila. Um job dentro do limite pode ainda falhar o prazo total da release. Leva fila, dependências, validação e recuperação ao planeamento de janelas e capacidade.
Trinta minutos em fila e quinze em execução não violam necessariamente timeout de vinte minutos, mas consomem 45 minutos da janela.
Armadilhas comuns
Preview parcial como completo; exclusão como correção; cache sempre mais rápida; timeout como prazo total.
Tópicos relacionados: Identidade, segredos e dependências do pipeline · Instrumentação e KQL
Torna lacunas e espera visíveis antes de prometer qualidade ou prazo.
Referência: Bicep what-if · AZ-400 objectives 2026-07-27