El examen AZ-400 aborda IaC desde el ángulo de 'qué herramienta usar y cuándo.' La clave está en entender mediante escenarios concretos por qué ARM Templates y Bicep son similares pero distintos, por qué Terraform se prefiere en entornos multi-nube y dónde aparecen DSC y Cloud-Init. En lugar de memorizar nombres de herramientas, agruparlas por 'qué declaran' aclara mucho el panorama.
Por qué necesitamos IaC: los clics no dejan memoria
Imagina que montas un mueble de IKEA sin las instrucciones. Lo terminas, pero seis meses después necesitas dos piezas idénticas y no sabes por dónde empezar. Crear recursos en el portal de Azure con clics es exactamente lo mismo: no queda registro de quién creó qué, cuándo ni con qué configuración, y reproducir el mismo entorno en staging o producción exige empezar desde cero.
IaC (Infrastructure as Code) declara el 'estado deseado' de la infraestructura como código. Al almacenarlo en Git se genera un historial de cambios, las pull requests permiten revisión por pares y los pipelines de CI/CD automatizan el despliegue. Existen dos enfoques principales.
: describes el estado final y la herramienta determina qué hacer comparando con el estado actual. ARM Templates, Bicep y Terraform funcionan así. : listas los pasos a ejecutar en orden. Los scripts de Azure CLI y PowerShell funcionan así.
El examen se centra principalmente en herramientas declarativas porque garantizan la : ejecutar la misma plantilla diez veces produce siempre el mismo resultado.
ARM Templates: el plano arquitectónico de los recursos Azure
Antes de levantar un edificio, el arquitecto dibuja planos detallados con la posición de las columnas, el tamaño de las ventanas y el número de plantas. ARM Template es ese plano para los recursos de Azure. Se escribe en JSON y Azure Resource Manager lo lee para crear y configurar los recursos solicitados.
Secciones principales de un ARM Template:
: valores que se suministran en el momento del despliegue (nombre del entorno, tamaño de la VM, etc.) : valores calculados intermedios reutilizados en la plantilla : lista de recursos Azure a crear (la sección central) : valores devueltos tras el despliegue (URLs de los recursos creados, etc.)
El principal inconveniente es la verbosidad de JSON. No se pueden añadir comentarios y expresar recursos repetidos requiere bucles que dificultan la lectura. Bicep nació para resolver exactamente este problema.
Bicep: ARM Templates con sintaxis legible para personas
Piensa en la diferencia entre un documento técnico de chef profesional (medidas al gramo) y una receta casera ('un puñado', 'al gusto'). El plato resultante es idéntico. Esa es la relación entre ARM Template y Bicep.
Bicep es un DSL (Domain-Specific Language) construido sobre ARM Templates. Cuando escribes un archivo Bicep, Azure CLI o Azure Pipelines lo transpila internamente a JSON de ARM Template antes del despliegue. Características clave:
: cada línea de Bicep tiene su equivalente en ARM Template. La operación inversa también funciona (). Admite comentarios (, ), sintaxis más corta y seguridad de tipos. La palabra clave permite componer archivos Bicep reutilizables.
La mitad de líneas para el mismo recurso. En los escenarios del examen AZ-400, Bicep es la 'opción IaC nativa de Azure.' Si el equipo trabaja solo con Azure y necesita integración estrecha con el ecosistema ARM, Bicep es la respuesta.
Terraform: el idioma común para la multi-nube
Cuando viajas por varios países, comunicarte en un idioma compartido como el inglés es mucho más eficiente que dominar cada lengua nativa por separado. Para una organización que usa Azure, AWS y GCP simultáneamente, Terraform cumple ese papel de lengua franca.
Terraform es una herramienta IaC de código abierto de HashiCorp, escrita en HCL (HashiCorp Configuration Language). Conceptos clave:
: complemento del proveedor de nube (azurerm, aws, google, etc.) que abstrae las llamadas a la API de cada proveedor. : archivo () que registra el estado actual de los recursos gestionados. Terraform compara el código declarado con este archivo para determinar qué cambiar. : vista previa de los cambios — 'añadir 5, modificar 1, destruir 0' — antes de ejecutar nada. : ejecuta los cambios reales. : almacena el archivo de estado en Azure Blob Storage o Terraform Cloud en lugar de localmente. Imprescindible para el trabajo en equipo.
| Criterio | Bicep | Terraform | |----------|-------|-----------| | Nube objetivo | Solo Azure | Multi-nube | | Lenguaje | DSL (basado en ARM) | HCL | | Gestión de estado | No necesaria (ARM lo gestiona) | Obligatoria () | | APIs Azure más recientes | Soporte inmediato | Requiere actualización del provider |
En escenarios del examen, cuando aparecen 'multi-nube', 'HashiCorp', 'HCL' o 'tfstate', la respuesta es Terraform.
!Bicep vs Terraform
DSC, Cloud-Init y Ansible: herramientas para gestionar el interior del sistema operativo
Si las herramientas IaC son el plano para 'crear VMs', las herramientas de gestión de configuración controlan 'qué se instala y configura dentro de esas VMs'. Esta distinción confunde a muchos candidatos al examen.
es una herramienta de gestión de configuración basada en PowerShell. Declara qué software debe estar instalado, qué servicios de Windows deben estar activos y qué configuraciones del sistema de archivos aplican dentro de la VM. Integrado con Azure Automation State Configuration, detecta y corrige automáticamente la desviación de configuración en flotas de VMs.
es un script de inicialización que se ejecuta la primera vez que arranca una VM Linux. Define instalaciones de paquetes, creación de usuarios y escritura de archivos en formato YAML. Azure, AWS y GCP lo admiten para VMs Linux.
Ansible, Chef y Puppet también pertenecen a este ámbito:
: sin agente, se conecta a los servidores de destino por SSH para aplicar la configuración. : DSL basado en Ruby; usa terminología de Cookbook y Recipe. : DSL declarativo con arquitectura Master-Agent.
Distinción fundamental: ARM / Bicep / Terraform gestionan el aprovisionamiento de infraestructura. DSC / Cloud-Init / Ansible / Chef / Puppet gestionan la configuración del sistema operativo y el software.
Análisis de seguridad IaC: detectar vulnerabilidades antes del despliegue
Una inspección de seguridad contra incendios en un edificio ya terminado es mucho más costosa que revisar las rutas de evacuación en la fase de diseño. El análisis de seguridad IaC funciona con el mismo principio. Antes de que el código Terraform o los ARM Templates lleguen a Azure, las herramientas automatizadas dentro del pipeline detectan configuraciones inseguras.
Herramientas principales:
: análisis estático basado en Python. Compatible con Terraform, ARM, Bicep, Kubernetes y más. Ejecutar analiza todos los archivos IaC del directorio actual en un solo comando. : análisis estático centrado en Terraform, alineado con las recomendaciones de Azure Security Center.
Situar el análisis IaC antes del paso en un pipeline de CI/CD hace que el código con configuraciones inseguras nunca llegue al . Este contenido conecta directamente con el tema de integración de seguridad en pipelines del próximo artículo.
Resumen para el Examen
'IaC nativa de Azure, DSL construido sobre ARM' → Bicep 'Multi-nube, HCL, tfstate, HashiCorp' → Terraform 'Convertir ARM Template a sintaxis legible' → 'Ver los cambios de Terraform antes de aplicar' → 'Almacenar el estado de Terraform para trabajo en equipo' → Remote Backend (Azure Blob Storage o Terraform Cloud) 'Gestión declarativa de software y servicios dentro de una VM' → Azure DSC 'Script de inicialización en el primer arranque de una VM Linux' → Cloud-Init 'Gestión de configuración sin agente por SSH' → Ansible 'Declarativo vs imperativo' → ARM / Bicep / Terraform = declarativo; scripts de Azure CLI = imperativo 'Análisis estático IaC, escaneo de vulnerabilidades en Terraform' → Checkov o tfsec 'Vista previa de cambios en ARM Template / Bicep antes del despliegue' →
Bicep = declarativo nativo de Azure, Terraform = declarativo multi-nube, DSC = gestión de configuración del sistema operativo.