Terraform Associate
Deep Dive
El estado es el núcleo de cómo Terraform funciona. Entender su estructura, el mecanismo de locking para equipos y cómo manejar el drift son temas recurrentes en el examen.
Contenido
El estado (terraform.tfstate) es el registro de verdad que Terraform mantiene sobre los recursos que gestiona. Es un archivo JSON que mapea cada recurso de tu configuración con su correspondiente recurso real en la nube.
Mapeo config → real
Asocia aws_vpc.main con vpc-0abc123 en AWS. Sin este mapeo, Terraform no sabe qué recursos gestionar.
Cálculo de diff
Para generar el plan, Terraform compara el estado con la configuración deseada. Sin estado, recrearía todo.
Metadatos de dependencias
Guarda las dependencias entre recursos para saber el orden correcto de destrucción.
Cache de atributos
Almacena atributos calculados (como IDs generados por la nube) para usarlos en otras referencias.
⚠️ Nunca edites el tfstate manualmente
Editar terraform.tfstate manualmente puede corromper el estado y causar que Terraform destruya o recree recursos inesperadamente. Usa siempre los comandos terraform state para manipular el estado.
El archivo tfstate es JSON. Conocer su estructura ayuda a entender cómo funciona Terraform internamente.
{
"version": 4, // versión del formato de estado
"terraform_version": "1.6.3", // versión de Terraform que generó este estado
"serial": 7, // número de serie (incrementa en cada apply)
"lineage": "abc-123-...", // UUID único de esta instancia de estado
"outputs": {
"vpc_id": {
"value": "vpc-0abc123def",
"type": "string",
"sensitive": false
}
},
"resources": [
{
"module": "module.vpc", // si es un módulo hijo, sino vacío
"mode": "managed", // "managed" (resource) o "data" (data source)
"type": "aws_vpc", // tipo de recurso
"name": "main", // nombre local
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [ // normalmente 1, múltiples con count/for_each
{
"schema_version": 1,
"attributes": { // TODOS los atributos del recurso (incluyendo sensibles)
"id": "vpc-0abc123def",
"cidr_block": "10.0.0.0/16",
"tags": {"Name": "mi-vpc"}
// ... todos los demás atributos
},
"dependencies": [ // recursos de los que depende
"aws_internet_gateway.main"
]
}
]
}
]
}terraform.tfstate
El archivo de estado principal. Actualizado después de cada apply.
terraform.tfstate.backup
Copia de seguridad automática del estado anterior a cada apply. Solo el más reciente.
El locking del estado previene que dos operaciones de Terraform modifiquen el estado simultáneamente, lo que podría corrompirlo. Terraform intenta adquirir el lock antes de cualquier operación que escriba en el estado.
| Backend | ¿Soporta locking? | Mecanismo de lock |
|---|---|---|
| Local (default) | ❌ No | Sin locking — peligroso en equipos |
| S3 | ✅ Sí* | * Requiere DynamoDB tabla separada configurada |
| Azure Storage | ✅ Sí | Blob lease nativo de Azure (automático) |
| GCS | ✅ Sí | Object locking nativo de GCS (automático) |
| HCP Terraform | ✅ Sí | Locking automático en cada run (plan/apply) |
| Terraform Enterprise | ✅ Sí | Locking automático |
| HTTP backend | ⚠️ Opcional | Depende de la implementación del servidor HTTP |
💡 S3 necesita DynamoDB para locking
El backend S3 almacena el estado, pero S3 por sí mismo no soporta locking. Para habilitar el locking debes crear una tabla DynamoDB y referenciarla con dynamodb_table = "terraform-lock" en la configuración del backend. La tabla debe tener una clave primaria con el nombre LockID de tipo String.
# Si un apply falla y el lock queda "colgado": # Terraform muestra el Lock ID en el mensaje de error terraform force-unlock LOCK_ID # ⚠️ Solo usar si ESTÁS SEGURO de que no hay otro apply en curso # Liberación incorrecta del lock puede causar corrupción del estado
El drift ocurre cuando el estado real de la infraestructura en la nube difiere del estado registrado en el tfstate. Esto sucede cuando alguien modifica la infra manualmente (por consola, CLI de la nube, etc.) sin pasar por Terraform.
Ejemplo de drift
Tu tfstate dice que la instancia tiene instance_type = t3.micro. Alguien la cambió manualmente a t3.large desde la consola de AWS.
Riesgo
Si ejecutas terraform apply sin detectar el drift, Terraform puede revertir el cambio manual o generar conflictos inesperados.
Solución
Ejecutar terraform plan -refresh-only para detectar y reconciliar el drift sin aplicar cambios de configuración.
# Detectar drift (refresca el estado contra la realidad) terraform plan -refresh-only # Salida posible: # ~ aws_instance.web # ~ instance_type = "t3.micro" -> "t3.large" (cambio manual detectado) # Aceptar el drift (actualizar estado para que coincida con la realidad): terraform apply -refresh-only # Revertir el drift (aplicar la configuración como estaba): terraform apply # terraform plan normal también refresca el estado antes de planificar # La diferencia es que -refresh-only SOLO refresca, no aplica cambios de config
El tfstate almacena todos los atributos de los recursos en texto plano, incluyendo contraseñas, claves API, certificados y otros secretos. Esta es una de las razones más importantes para usar un backend remoto con cifrado.
Backend local (default)
El tfstate queda en el disco del desarrollador. Si se sube a Git por error, todos los secretos quedan expuestos.
S3 sin cifrado
El tfstate en S3 sin server-side encryption es accesible para cualquiera con acceso al bucket.
S3 con SSE-KMS
Cifrado en reposo con KMS. Acceso controlado por políticas IAM. Recomendado para producción.
HCP Terraform
Cifrado en reposo automático. Acceso controlado por equipos y permisos de workspace.
🎯 Para el examen
sensitive = trueterraform plan -refresh-only detecta drift sin aplicar cambios¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un equipo usa el backend S3 para almacenar el estado de Terraform. Han configurado el bucket correctamente pero noten que dos miembros del equipo pueden ejecutar terraform apply simultáneamente sin que uno bloquee al otro. ¿Qué falta en la configuración?