El plan que se aprueba y el que se aplica

Un plan es una fotografía: lo que Terraform haría hoy, con el código y el estado de hoy. Si la etapa de aplicación vuelve a planificar por su cuenta, genera otra fotografía, y entre una y otra pudo cambiar el código de la rama principal o la infraestructura real. Terraform permite guardar el plan en un archivo (-out) y aplicar ese archivo: entonces ejecuta exactamente lo planificado, sin pedir confirmación, porque la confirmación ya ocurrió al aprobarlo. La revisión humana es el control; el archivo es lo que la hace valer.

Quien revisa debe poder decir «esto es lo que se va a aplicar», y la cadena debe garantizarlo.

Abre el laboratorio. La ejecución 0412 es el plan que revisó el equipo; la 0415 es la aplicación. Compara las acciones de las dos. Cuando una etapa de aplicación «descubre» acciones que la revisión no vio, el control de revisión se acabó de romper sin que ningún escáner lo notara.

La etapa de aplicación del archivo de la canalización ejecuta un comando que no recibe ningún plan guardado. Quien aprobó, aprobó un archivo concreto, con nombre: el de la etapa de plan. Ese nombre es el que la aplicación debería haber recibido, y es el vínculo entre «lo revisado» y «lo aplicado».

La documentación oficial advierte que, aunque la salida de la terminal oculte los valores sensibles, un plan guardado los contiene en claro. Eso convierte el archivo en un artefacto sensible: quién puede descargarlo y cuánto tiempo se conserva importa tanto como el estado. Un artefacto legible por todo el proyecto, conservado durante meses, es una copia de datos delicados que nadie vigila.

La canalización publica el plan como comentario de la propuesta para que se revise a gusto. Terraform oculta los atributos marcados como sensibles, pero oculta solo esos. Un valor que viaja dentro de un texto más largo, sin la marca, sale tal cual. Aquí el fallo es de la cadena y del código a la vez: el comentario es legible para todo el proyecto y quedará en el historial de la propuesta.