Cerramos el capítulo con un repaso práctico de los comandos que usarás a diario con Terraform. Ya hemos visto algunos por separado; aquí los reunimos en orden, añadimos dos nuevos (fmt y validate) y los ordenamos como un flujo de trabajo real. Considéralo tu chuleta de comandos.

Este es el orden típico de los comandos en un proyecto de Terraform:

Vamos uno a uno.

Qué hace: inicializa el directorio de trabajo. Descarga los providers (subcapítulo 11.1) y configura el backend del estado (subcapítulo 11.3).

Cuándo se ejecuta:

• La primera vez que trabajas en un proyecto.
• Cuando añades o cambias un provider.
• Cuando cambias la configuración del backend.

Es el primer comando que ejecutas en cualquier proyecto nuevo. Sin él, los demás comandos no funcionan porque falta descargar los providers.

Qué hace: formatea automáticamente tus archivos .tf para que tengan un estilo consistente (indentación, alineación, espacios). No cambia la lógica, solo la apariencia.

Por qué usarlo: un código bien formateado es más fácil de leer y evita discusiones de estilo en el equipo. Es como un corrector de estilo automático. Se suele ejecutar antes de guardar o subir cambios. En equipos, se comprueba automáticamente en CI (Capítulo 22).

Analogía: fmt es como el botón «ordenar/alinear» de un documento: deja todo limpio y uniforme sin cambiar el contenido.

Qué hace: comprueba que tu código es válido sintáctica y lógicamente, sin conectarse a AWS ni crear nada. Detecta errores como argumentos mal escritos o referencias inexistentes.

Por qué usarlo: te avisa de errores antes de intentar aplicar nada. Es una comprobación rápida y barata. Si validate falla, no tiene sentido seguir.

Diferencia con plan: validate solo revisa que el código esté bien escrito (no necesita credenciales). plan va más allá: consulta AWS y te dice qué cambios haría. Primero validate (¿está bien escrito?), luego plan (¿qué va a hacer?).

Qué hace: muestra qué cambios haría sin aplicarlos. Compara tu código, el estado y la realidad (subcapítulos 9.4 y 11.2).

Recuerda los símbolos: + crear, ~ modificar, - destruir. Es tu red de seguridad: revisas antes de tocar nada.

Qué hace: ejecuta los cambios de verdad, tras mostrarte el plan y pedir confirmación (yes).

Después de aplicar, tu infraestructura real coincide con tu código, y el estado se actualiza.

Truco: terraform apply ya hace un plan internamente y te lo muestra antes de pedir confirmación, así que puedes revisar una última vez antes de escribir yes.

Qué hace: destruye todos los recursos gestionados, tras confirmación. Ideal para limpiar pruebas y dejar de pagar (subcapítulo 9.4).

⚠️ Irreversible. Genial en pruebas, peligroso en producción. Úsalo con cabeza.

Además de los esenciales, hay otros que irás usando:

Así sería tu día a día creando infraestructura nueva:

Consejo: Acostúmbrate a ejecutar siempre plan antes de apply y a leer el plan con atención. Es el hábito que te salvará de errores costosos. Muchos sustos en la nube se evitan simplemente leyendo bien lo que Terraform iba a hacer.

• El flujo típico es init → fmt → validate → plan → apply → destroy.
• init: prepara el proyecto (descarga providers, configura backend). Primer comando, imprescindible.
• fmt: formatea el código (estilo limpio y uniforme).
• validate: revisa que el código es válido, sin tocar AWS.
• plan: previsualiza los cambios (no aplica nada). Tu red de seguridad.
• apply: aplica los cambios (pide yes). destroy: elimina todo (pide yes, irreversible).
• Hábito de oro: siempre plan antes de apply, y lee el plan con atención.

Con esto cierras el Capítulo 11. Ya tienes todas las piezas teóricas de Terraform: lenguaje, providers, estado y comandos. En el Capítulo 12 lo juntaremos todo construyendo tu primera infraestructura real: una VPC con un servidor EC2, paso a paso.