Cómo revisar Bicep antes de desplegar en Azure

En pocas palabras: Revisar Bicep antes de desplegar requiere cuatro pasos: compilar con az bicep build a ARM JSON, correr el linter nativo, validar contra un scope real y comparar con what-if. what-if solo muestra el diff de recursos: no evalúa si el cambio es seguro ni si entra en presupuesto, según una guía publicada el 6 de octubre de 2026 por Prateek Singh, fundador de Cloudeval.

Un PR con cambios en main.bicep puede tener el linter en verde, el what-if mostrando solo un puñado de + Create prolijos, y aun así terminar abriendo un storage account a internet o duplicando la factura mensual con un SKU distinto. Ninguna herramienta mintió: revisar Bicep antes de desplegar exige mirar más allá del diff.

Revisar Bicep antes de desplegar significa compilar el archivo a ARM JSON (el formato que Azure Resource Manager realmente procesa), correr el linter nativo, validar el template contra un scope real y comparar el diff con what-if, para después revisar diseño, costo y seguridad sobre ese JSON compilado. what-if responde qué va a cambiar en la suscripción. No responde si ese cambio conviene, es seguro o entra en presupuesto.

¿Qué controles nativos existen para revisar Bicep antes de desplegar?

Existen cuatro controles nativos de Azure, y cada uno detecta algo distinto. az bicep build atrapa errores de sintaxis y tipos, sin tocar la suscripción. El linter revisa URLs hardcodeadas, secretos en outputs y versiones de API viejas, tampoco necesita acceso a Azure. az deployment group validate y what-if sí lo necesitan, porque trabajan contra un scope real.

Ahora bien, ninguno de los cuatro mira diseño, costo ni riesgo cruzado entre recursos. Esa es la columna que falta en la tabla original de la fuente, y es justo el gap que explica por qué un PR puede estar “todo en verde” y romper algo igual. Para más detalles técnicos, mirá si querés entender las diferencias entre ambas plataformas.

Control	Qué detecta	¿Necesita acceso a Azure?	Qué no detecta
az bicep build	Errores de sintaxis y tipos	No	Intención y diseño
Linter de Bicep	URLs hardcodeadas, secretos en outputs, defaults inseguros, versiones de API viejas	No	Topología, costo, riesgo entre recursos
az deployment group validate	Si Resource Manager acepta el template en un scope real	Sí	Si conviene desplegarlo
what-if	El diff a nivel de recurso contra el estado actual	Sí (nivel deploy)	Si ese diff es seguro o accesible en costo
Revisión de diseño, costo y seguridad	Exposición pública, forma de dependencias, drivers de costo	No, para la revisión del template	Comportamiento en runtime, drift en vivo

¿Por qué what-if no alcanza para saber si un cambio es seguro?

what-if no alcanza porque solo compara recursos contra el estado actual de la suscripción, sin evaluar exposición pública ni costo. El caso que describe la fuente es concreto: un PR aprobado con what-if mostrando una lista prolija de + Create y ~ Modify, y dos semanas después alguien descubre que ese cambio “chico” dejó un storage account abierto a internet, o duplicó la factura con un SKU nuevo.

¿Y qué pasó cuando lo aprobaron? Nada raro en apariencia. El diff estaba limpio, el CI estaba verde, alguien hizo click en aprobar.

El tema es que what-if responde una sola pregunta, qué va a cambiar en Azure ahora mismo, y esa pregunta no es la misma que “¿esto es seguro?” o “¿esto entra en presupuesto?”. Subís el cambio, lo validás con el diff en mano, todo parece ordenado, lo mandás a producción y recién ahí, con la factura del mes siguiente o con un scan de seguridad externo, aparece el problema real que ningún comando nativo estaba diseñado para encontrar.

¿Cómo compilar y revisar el Bicep paso a paso antes de desplegar?

El proceso tiene cuatro pasos: compilar a ARM JSON, correr los controles nativos, revisar diseño-costo-seguridad sobre el JSON compilado, y volver a correr what-if justo antes del deploy real. Bicep compila a ARM JSON, y ese JSON es lo que Azure realmente despliega, no el archivo .bicep original. En una vez desplegada la VM podés conectarte por SSH profundizamos sobre esto.

El primer paso va así:

• Compilar el template: az bicep build --file ./infra/main.bicep --outfile ./infra/main.json, y hacer lo mismo con los parámetros usando az bicep build-params.
• Correr los controles nativos: linter con az bicep lint, validate y what-if contra el resource group correspondiente.
• Revisar el JSON compilado: acá entra la capa de diseño, costo y seguridad que ningún comando nativo cubre. La fuente usa como ejemplo una herramienta propia, Cloudeval. Esa herramienta lee el ARM JSON (no el .bicep directo) y devuelve diagramas de dependencias con hallazgos de costo y seguridad, según aclara el propio autor del artículo, Prateek Singh, fundador de esa empresa.
• Re-correr what-if antes del deploy: el estado de Azure puede cambiar entre el momento del PR y el momento real del despliegue.

Para refactors sin tocar la suscripción, Bicep CLI 0.41.2+ incorpora bicep snapshot, que compara qué desplegaría un .bicepparam sin contactar Azure. Es útil cuando el reviewer no tiene permisos de deploy, algo bastante común, dicho sea de paso.

¿Qué configurar en bicepconfig.json para que el linter detecte riesgos reales?

El linter de Bicep detecta riesgos reales cuando las reglas de seguridad quedan en nivel error, no en warning. Por default, varias reglas relevantes vienen configuradas más flojas, y ahí se pierde la posibilidad de bloquear un merge peligroso en CI.

Las reglas que la fuente marca como críticas:

• outputs-should-not-contain-secrets en error: evita que un secreto termine expuesto en los outputs del deployment.
• secure-parameter-default en error: fuerza a no poner defaults en parámetros que deberían ser secure.
• use-secure-value-for-secure-inputs en error: obliga a usar valores secure en inputs sensibles.
• no-hardcoded-environment-urls en error: bloquea URLs de ambiente quemadas en el código.
• use-recent-api-versions en warning: avisa sobre versiones de API viejas, sin bloquear el merge.

Con eso configurado, az bicep lint --file ./infra/main.bicep corre en CI y bloquea lo que de verdad importa, no cualquier detalle cosmético.

¿Qué limitaciones tiene what-if que hay que tener en cuenta?

what-if tiene tres limitaciones concretas que la propia fuente detalla. Necesita permisos de deploy, incluyendo Microsoft.Resources/deployments/*, algo que los reviewers muchas veces no tienen. Eso solo ya explica por qué en varios equipos nadie corre what-if en el momento de la revisión, sino recién al desplegar. Sobre eso hablamos en para profundizar según tu rol en Azure.

Los defaults que Azure asigna automáticamente pueden aparecer como cambios en el diff, aunque en la práctica nada vaya a cambiar. Eso genera ruido: alguien ve un ~ Modify inesperado, se asusta, y termina siendo un falso positivo.

Y los recursos que se despliegan vía templateLink, incluyendo template specs, no se expanden en el diff de what-if. Si un módulo referenciado cambia, what-if no lo va a mostrar. Hay que revisarlo aparte, siempre.

¿Qué checklist usar antes de cada deploy de Bicep?

Un checklist de pre-deploy para Bicep combina los controles nativos con la revisión de diseño, costo y seguridad, y termina siempre con un what-if recién corrido. Esta es la lista que propone la fuente:

• az bicep build pasa y el ARM JSON compilado está committeado y actualizado.
• az bicep lint limpio, con las reglas de seguridad relevantes en error.
• az deployment group validate pasa en el scope objetivo.
• El diff de what-if coincide con la descripción del PR, sin Delete o Modify sorpresa.
• Templates linkeados y nested revisados aparte, porque what-if no los expande.
• Diagrama de dependencias revisado, sin exposición pública, de identidad o de subnet no intencionada.
• Hallazgos de alta severidad triageados: arreglados, waived con motivo, o en ticket.
• Costo mensual estimado contra presupuesto, con justificación de los SKU elegidos.
• Áreas “not assessed” anotadas, no asumidas como seguras.
• what-if vuelto a correr justo antes del deploy real.

Como criterio editorial propio para equipos que recién arrancan con esto: conviene empezar el gate en modo comment_only (si usan algún tool de CI con ese tipo de configuración), medir falsos positivos durante dos o tres semanas, y recién después pasar a bloqueo duro. Bloquear desde el día uno sin haber calibrado el umbral suele terminar en gente que desactiva el check entero. Esto se conecta con lo que analizamos en revisar la seguridad de tus repositorios también es clave.

Qué significa esto para equipos que trabajan infraestructura en Latinoamérica

Para equipos de DevOps en la región, el punto práctico es que estos controles no necesitan licencias caras ni infraestructura adicional: az bicep build, el linter y bicep snapshot corren local, sin tocar la suscripción. Eso reduce la fricción de dar permisos de Azure a cada reviewer, algo que en equipos chicos suele ser un dolor de cabeza administrativo.

Si el equipo además gestiona hosting o dominios propios además de la infraestructura en Azure, conviene no mezclar responsabilidades: para esa parte, donweb.com es una opción pensada para necesidades de hosting y dominios en Argentina, separada de la capa de IaC que se discute acá.

Errores comunes al revisar Bicep antes de desplegar

• Aprobar un PR solo porque what-if está en verde: el diff limpio no dice nada sobre exposición pública ni sobre costo. Hay que mirar el diagrama de dependencias, no solo la lista de cambios.
• Dejar el ARM JSON compilado desactualizado: si main.json no refleja el último main.bicep, cualquier herramienta que lea el JSON (como el linter o una revisión de diseño) está analizando algo que ya no es el código real. La fuente resuelve esto con un paso de CI que falla si hay diferencia entre ambos archivos.
• Confundir “not assessed” con “seguro”: que una herramienta no haya evaluado algo no significa que esté bien. Es, directamente, un hueco en la revisión.
• No volver a correr what-if antes del deploy real: el estado de Azure cambia. Un what-if de hace una semana puede no reflejar lo que hay en la suscripción hoy.

Preguntas Frecuentes

¿Cómo previsualizar cambios de un deployment en Azure antes de aplicarlos?

Corriendo az deployment group what-if con el mismo template y los mismos parámetros que vas a desplegar. El comando lista cada recurso que se crearía, modificaría o borraría, y necesita permisos de deploy sobre el scope.

¿Qué diferencia hay entre what-if y el linter de Bicep?

El linter revisa el código fuente .bicep en busca de patrones inseguros (secretos en outputs, URLs hardcodeadas) sin necesitar acceso a Azure. what-if, en cambio, compara el template contra el estado real de la suscripción y necesita permisos de deploy. Son controles complementarios, no sustitutos.

¿Por qué what-if muestra cambios que en realidad no van a pasar?

Porque Azure asigna ciertos valores por default que what-if interpreta como una modificación, aunque el recurso quede exactamente igual. Ante un Delete o Modify inesperado, conviene primero contrastarlo contra la descripción del PR antes de asumir que algo se va a romper.

¿Se puede revisar un archivo Bicep sin tener acceso a la suscripción de Azure?

Parcialmente. az bicep build, el linter y bicep snapshot corren en local sin tocar Azure. validate y what-if, en cambio, necesitan acceso de deploy al scope real, así que esa parte no se puede evitar.

¿Cómo bloquear un merge si el costo estimado supera el presupuesto?

Configurando un gate de CI con un tope de costo mensual sobre el ARM JSON compilado, y poniendo ese job como check obligatorio en la protección de la rama. La fuente recomienda arrancar en modo de solo comentario, calibrar el umbral, y después pasar a bloqueo real del merge.

Conclusión

Lo que cambia con esta guía no es la herramienta, es el orden de las preguntas. what-if sigue siendo, según la propia fuente, “la única respuesta real a qué cambia en esta suscripción ahora mismo”, pero esa pregunta es distinta de si el cambio conviene. Para un equipo que ya tiene CI con Bicep, el ajuste concreto es chico: subir cuatro reglas del linter a error, agregar un paso que falle si el ARM JSON compilado está desactualizado, y sumar una capa de revisión de costo y seguridad sobre ese JSON antes de aprobar cualquier PR. Lo que no hay que hacer es confiar en que un diff limpio alcanza. Nunca alcanzó. Para equipos que recién arrancan con bicep snapshot en refactors sin tocar la suscripción, conviene correrlo primero en modo manual, antes de sumarlo como gate obligatorio en el pipeline.

Fuentes

• Review Bicep before deployment: what-if, linter and cost – artículo original de Prateek Singh, actualizado el 6 de octubre de 2026