Terraform operacional: drift, import y recuperación con evidencia

Cuando un plan sorprende, evita el reflejo de “arreglar el state”. Primero identifica cuál de las tres capas cambió:

1. configuración: lo que el repositorio desea;
2. state: la asociación y último snapshot conocido;
3. objeto remoto: lo que el provider observa ahora.

Drift es una diferencia, no un diagnóstico. Puede venir de una edición manual legítima, una política externa, un apply interrumpido, credenciales apuntando a otra cuenta, cambio de default del provider o corrupción/pérdida de state.

La secuencia de diagnóstico

OpenTofu desaconseja el comando refresh porque actualiza state sin oportunidad de revisar el efecto y recomienda la modalidad apply -refresh-only, donde los cambios detectados pueden inspeccionarse antes de confirmarlos. [1]

Ese detalle es crucial: credenciales equivocadas pueden hacer que recursos existentes parezcan ausentes. Un refresh ciego convertiría una observación defectuosa en state oficial.

Importar es crear una asociación, no recrear historia

Los bloques import llevan objetos existentes al workspace mediante una dirección e identidad explícitas, y permiten revisar la operación dentro del flujo normal de plan/apply. [2]

import {
  to = aws_s3_bucket.logs
  id = "trautslab-existing-logs"
}
 
resource "aws_s3_bucket" "logs" {
  bucket = "trautslab-existing-logs"
}

El import no deduce automáticamente toda la intención. El recurso HCL debe representar el objeto de forma suficiente para que el plan posterior no proponga cambios destructivos. OpenTofu exige que cada objeto remoto quede asociado a una sola dirección; importarlo dos veces puede producir comportamiento no deseado. [3]

Elegir la operación mínima

state rm, state mv y state push son cirugía

Estos comandos no arreglan recursos; cambian el mapa. Úsalos solo después de:

• backup verificable con lineage y serial;
• ventana sin escritores;
• lista explícita de addresses afectadas;
• dry run cuando exista;
• revisión por otra persona;
• plan posterior esperado;
• rollback documentado.

state rm deja el objeto remoto sin administración. state mv cambia la dirección asociada. state push puede sobrescribir el snapshot remoto y saltarse protecciones si se fuerza. La operación segura es la más pequeña que restaura la correspondencia conocida.

Fallo realista: borrados masivos que no son drift

Un runner pierde acceso a una cuenta y el refresh interpreta varios objetos como ausentes. El operador ve decenas de eliminaciones en state y decide aplicar para “sincronizar”. La causa no era drift: era identidad. El runbook debe validar cuenta, región, workspace, provider aliases y permisos antes de aceptar cualquier observación remota.

Recuperación como prueba, no como esperanza

Una copia de state no es backup hasta que la restauración se ensaya. El ejercicio debe demostrar que:

1. recuperas la versión correcta, no solo la más reciente;
2. preservas lineage o entiendes por qué cambia;
3. el plan posterior contiene solo el delta esperado;
4. el lock impide escritores durante la restauración;
5. los outputs y smoke checks validan el servicio, no solo el JSON.

Decidir cuál historia debe prevalecer

No todo drift se corrige aplicando el código. Un cambio manual puede ser una mitigación de emergencia que ahora debe incorporarse a configuración; también puede ser una desviación que conviene revertir. Antes de tocar state, identifica propietario, momento, motivo y efecto. La operación correcta depende de qué historia representa la intención autorizada.

Clasifica la diferencia: atributo mutable, objeto reemplazado, recurso movido, binding ausente o recurso eliminado. Para un rename de dirección, moved conserva historia declarativamente. Para un objeto existente sin binding, un bloque import hace revisable la asociación. state rm deja de administrar sin borrar el objeto y por eso requiere confirmar quién asumirá su ciclo de vida. Editar o empujar state queda como recuperación excepcional, con copia, lock y revisión independiente.

Después de reconciliar, exige dos señales: plan sin cambios no explicados y comprobación funcional del servicio. La primera valida el modelo de Terraform; la segunda valida que el objeto sigue cumpliendo su trabajo. Un estado “limpio” puede describir perfectamente una infraestructura rota.

Mantén una cronología del incidente. Incluye el último apply conocido, la primera detección del drift, cambios hechos desde consola, versiones de state consultadas y cada comando de reconciliación. Esa secuencia ayuda a separar causa de reacción: el import puede corregir el binding, pero no explica por qué desapareció.

Antes de cerrar, busca el mismo patrón en stacks vecinos. Una automatización externa, permiso excesivo o procedimiento manual rara vez afecta un único resource address por casualidad. Corrige la fuente de cambios y agrega detección; de otro modo, el plan limpio es solo una pausa entre dos incidentes.

Documenta también el propietario del control preventivo.

Define cuándo volverá a probarse.

Contrato de lab

Simula tres incidentes con un provider local:

• objeto remoto alterado fuera del código;
• recurso existente sin binding;
• state anterior restaurado por error.

Para cada uno entrega cronología, identity context, diff de configuración, seriales, plan antes/después, operación mínima elegida y prueba final de idempotencia. El teardown debe dejar tanto recursos como state en una condición conocida.

Conexiones dentro de la serie

• Antes: CI/CD y credenciales efímeras.
• Volver al inicio: Terraform y OpenTofu para laboratorios reproducibles.
• Siguiente paso práctico: Terraform lab network.