Tu equipo usa Terraform y varias personas aplican cambios. ¿Cómo gestionás el state para evitar corrupción, conflictos y fugas de secretos?

El state es la fuente de verdad que mapea el código con los recursos reales, así que lo trato como un activo crítico.

Almacenamiento y concurrencia:

• Uso un backend remoto, nunca un archivo local ni el state commiteado en Git. Por ejemplo S3, GCS, Azure Blob o Terraform Cloud.
• Activo el locking para que dos

  apply

  no escriban a la vez. En S3 eso era tradicionalmente una tabla DynamoDB; las versiones recientes soportan el lock nativo con

  use_lockfile

  .
• Activo el versionado del bucket para poder recuperar un state corrupto.

Seguridad: el state puede contener secretos en texto plano, aunque estén marcados como

sensitive

. Por eso aplico cifrado en reposo, acceso por IAM con mínimo privilegio y auditoría de accesos. Los secretos los saco de un gestor como Vault o Secrets Manager.

Organización:

• Mantengo states separados por entorno y por componente (red, base de datos, aplicación). Así reduzco el blast radius y el tiempo de plan.
• Comparto datos entre stacks con outputs o data sources, sin un state monolítico.

Proceso:

• Ningún apply se hace desde laptops. El pipeline ejecuta

  plan

  en cada PR, alguien lo revisa y el

  apply

  se hace con el plan guardado.
• Corro un plan programado para detectar drift causado por cambios manuales en la consola.
• Para refactors uso bloques

  moved

  o

  terraform state mv

  , y bloques

  import

  para adoptar recursos existentes, así evito destroy/create accidentales.
• Nunca edito el JSON a mano.

  force-unlock

  solo lo uso tras confirmar que no hay otro proceso activo.

Guardar el state en Git o en local, o creer que sensitive lo cifra. Tener un único state gigante para todo y hacer force-unlock por costumbre sin verificar.