¿Cómo funciona el estado de Terraform y cómo lo gestionas en equipo?

El estado es el registro de Terraform de qué recursos reales corresponden a qué direcciones de configuración, más los atributos cacheados que usa para calcular un plan. Para un equipo tiene que vivir en un backend remoto con bloqueo, como S3 con soporte nativo de lockfile o un backend gestionado, para que no se ejecuten dos apply a la vez. Nunca lo subas a git, ya que guarda secretos en texto plano, y divídelo por radio de impacto en vez de mantener un único fichero gigante.

El estado es el mapa entre lo que escribí en código y lo que existe de verdad en el proveedor, indexado por dirección de recurso, más una caché de atributos para que un plan no tenga que leerlo todo desde cero. En equipo va en un backend remoto con bloqueo, para que dos personas ejecutando apply a la vez no puedan corromperlo. Lo que sorprende a la gente es que el estado contiene los atributos de los recursos tal cual, así que las contraseñas de base de datos y las claves generadas están ahí en texto plano; eso significa que el bucket va cifrado, versionado y restringido al rol del pipeline, no legible por todo el mundo. Sobre la organización, divido por radio de impacto y por ritmo de cambio. La red y las cuentas cambian poco y tienen su propio estado, cada servicio o entorno tiene el suyo, y se leen entre sí mediante data sources o salidas publicadas en vez de un módulo raíz que lo contenga todo. La razón práctica es que un fichero de estado de quinientos recursos hace lento cada plan y enorme cada error. Para recuperar me apoyo en el versionado del bucket más state mv e import en vez de editar el fichero a mano.