Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen 004. Lee de arriba a abajo o salta a una sección.
Un equipo navega manualmente por las consolas en la nube; nadie sabe cómo se suponía que debía verse la producción.
Adoptar IaC. Las configuraciones residen en archivos controlados por versiones: los archivos son la fuente autorizada de la verdad, no la consola en la nube.
Por qué: El rastro de auditoría, la revisión por pares, la reversión y la replicación fluyen del control de versiones. El aprovisionamiento manual no tiene nada de esto.
Elegir entre describir el estado final deseado o programar los pasos para alcanzarlo.
Terraform es declarativo. Usted describe el objetivo; Terraform averigua las llamadas a la API. Ansible, scripts Bash y SDKs personalizados son imperativos.
Por qué: Las configuraciones declarativas son idempotentes y convergen independientemente del estado inicial. Los scripts imperativos deben razonar sobre cada transición.
Un ingeniero quiere que el mismo `terraform apply` sea seguro de volver a ejecutar sin duplicar recursos.
Idempotente por diseño. Aplicar la misma configuración repetidamente converge en el mismo estado, sin duplicados ni desviaciones.
Detectar cuándo la realidad se desvió de lo que dice la configuración (alguien hizo clic en la consola).
`terraform plan -refresh-only` lee el estado actual de la nube e informa las diferencias con el estado sin proponer cambios.
Distinguir el aprovisionamiento inicial de las operaciones continuas.
Día 0 = diseño y planificación. Día 1 = aprovisionamiento inicial (primera aplicación). Día 2 = operaciones continuas: parcheo, escalado, rotación de certificados, remediación de desviaciones.
Por qué: La mayor parte del trabajo de producción es del Día 2. Las herramientas de IaC deben admitir la iteración, no solo el primer despliegue.
Reducir el riesgo de desviación de la consola; requerir que todos los cambios de infraestructura pasen por revisión.
GitOps con IaC: git es la fuente de la verdad, los PRs activan planes, las fusiones activan aplicaciones. Bloquear el acceso directo a la consola a través de SCP/IAM.
La carga de trabajo abarca AWS y GCP; el equipo quiere una sola herramienta, un solo flujo de trabajo.
Terraform con múltiples proveedores en una configuración: `hashicorp/aws` + `hashicorp/google`. Las salidas de un proveedor alimentan las entradas de otro.
Por qué: Núcleo agnóstico del proveedor; los SDKs por nube residen en proveedores conectables. CloudFormation/ARM son de una sola nube.
Pasos del ciclo de vida estándar de Terraform.
`init` (descargar proveedores + backend) → `plan` (previsualizar) → `apply` (ejecutar) → `destroy` (desmontar). `plan` es de solo lectura y seguro.
¿Por qué Terraform necesita un archivo de estado en lugar de consultar la nube en cada ejecución?
El estado asigna direcciones de configuración (`aws_instance.web`) a IDs de recursos reales, rastrea dependencias y almacena metadatos en caché. Sin él, Terraform no puede saber qué recursos de la nube gestiona versus cuáles se crearon en otro lugar.
Elegir entre la CLI de código abierto y HCP Terraform.
Equipo pequeño / solo / sin cumplimiento de políticas → CLI OSS con backend remoto. Múltiples equipos / políticas Sentinel/OPA / ejecuciones controladas por VCS / credenciales dinámicas → HCP Terraform.
Por qué: Ambos ejecutan el mismo binario de Terraform; HCP agrega colaboración, gobernanza e infraestructura de ejecución remota.
Aprovisionar VMs versus configurar software dentro de ellas.
Terraform aprovisiona recursos en la nube (VMs, redes, IAM). Ansible/Chef/Puppet configuran software dentro de las VMs. Son complementarios, no competidores.
Una empresa que solo usa AWS debate entre CloudFormation y Terraform.
CloudFormation tiene una integración más estrecha con AWS, reversión nativa y cero gestión de archivos de estado. Terraform gana en multi-nube, un ecosistema de módulos más grande y la ergonomía de HCL. Elegir CFN si solo se usa AWS y la reversión es lo más importante; Terraform de lo contrario.
Fijar la fuente y la versión del proveedor para instalaciones reproducibles.
Declarar en `terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } } }`.
Por qué: Sin `required_providers` explícitos, Terraform asume espacios de nombres de registro heredados y puede seleccionar versiones incompatibles.
La configuración tiene `required_providers` para AWS pero no un bloque `provider "aws"`.
Terraform crea una configuración de proveedor vacía predeterminada. El proveedor de AWS luego lee `AWS_ACCESS_KEY_ID`/`AWS_PROFILE`/IMDS en su precedencia estándar.
Por qué: Un bloque `provider` explícito es opcional; solo se necesita para anular los valores predeterminados o alias múltiples instancias.
Decidir qué operador de restricción de versión usar.
`~> 5.0` permite `>= 5.0, < 6.0` (cualquier 5.x). `~> 5.0.1` permite `>= 5.0.1, < 5.1.0` (solo actualizaciones de parche). `>= 5.0` sin límite superior. `= 5.2.0` exacto. `!= 5.3.0` exclusión.
Por qué: El operador pesimista `~>` solo permite que crezca el componente de versión más a la derecha.
¿Qué hace realmente `terraform init`?
Descarga proveedores según `required_providers`, inicializa el backend, descarga fuentes de módulos y escribe `.terraform/` más `.terraform.lock.hcl`. Requerido antes de `plan` o `apply`.
Apareció un archivo `.terraform.lock.hcl` después de `init`. ¿Lo confirmo o lo ignoro en git?
Confirmarlo. El archivo de bloqueo registra versiones exactas del proveedor + sumas de comprobación criptográficas. Asegura que cada colaborador y ejecutor de CI instale proveedores idénticos.
Por qué: Sin él, `terraform init` puede elegir una versión compatible más nueva en una máquina diferente, introduciendo diferencias inesperadas.
Estandarizar espacios en blanco, alineación y sangría en todos los archivos `.tf`.
`terraform fmt` reescribe los archivos `.tf` en su lugar al estilo canónico. Ejecutar en hooks de pre-commit y CI.
Detectar errores de sintaxis y tipos incompatibles sin acceder a las APIs de la nube.
`terraform validate` verifica la sintaxis HCL, la consistencia de tipos, los argumentos requeridos y las referencias internas. Solo local, no se necesita autenticación de proveedor.
Por qué: No detecta problemas del lado del proveedor (autenticación, recursos faltantes); esos solo se manifiestan en `plan`.
CI ejecuta `terraform init` repetidamente en muchos proyectos, cada uno descargando los mismos proveedores desde cero.
Configurar `TF_PLUGIN_CACHE_DIR` (o `plugin_cache_dir` en la configuración de la CLI). Los proveedores se descargan una vez y se enlazan simbólicamente a directorios `.terraform/` por proyecto.
¿Las direcciones fuente del proveedor siguen qué formato?
`<hostname>/<namespace>/<type>` - por ejemplo, `registry.terraform.io/hashicorp/aws`. El hostname omitido por defecto es el Registro Público de Terraform. Namespace = proveedor. Type = nombre del proveedor.
Evitar que los colaboradores ejecuten una versión de Terraform CLI incompatible.
`terraform { required_version = ">= 1.5, < 2.0" }`. La CLI se niega a operar si la versión en ejecución no coincide.
Elegir la autenticación del proveedor para un ejecutor de CI/CD.
Lo mejor: credenciales dinámicas de corta duración (confianza OIDC a AWS/Azure/GCP, credenciales de proveedor dinámicas de HCP Terraform). Aceptable: variables de entorno (`AWS_ACCESS_KEY_ID`). Evitar: credenciales codificadas en el bloque `provider`.
Por qué: Los secretos estáticos de larga duración en la configuración son la principal causa de incidentes de credenciales filtradas.
¿Dónde residen las configuraciones de nivel superior?
Un bloque `terraform { ... }` contiene `required_version`, `required_providers`, `backend`, `cloud` y experimentos. Múltiples bloques `terraform` entre archivos se fusionan.
El recurso existe en el estado pero ya no debe ser gestionado por Terraform; el recurso en la nube debe seguir funcionando.
`terraform state rm <addr>`. Elimina del estado sin destruir el recurso en la nube.
Se refactorizó el nombre de un recurso o se movió a un módulo; se quiere evitar la destrucción/recreación.
`terraform state mv <old> <new>`. Actualiza el mapeo de estado sin tocar los recursos en la nube.
Por qué: En Terraform 1.1+, preferir el bloque `moved` en HCL - es revisable, controlado por versiones y funciona en planes de PR.
La URL interna del registro del proveedor cambió; el estado existente todavía hace referencia a la antigua dirección de origen.
`terraform state replace-provider <old-source> <new-source>`. Reescritura de referencias de proveedor en el estado.
La aplicación falló a mitad de ejecución; el bloqueo de DynamoDB está atascado y otros ingenieros están bloqueados.
`terraform force-unlock <LOCK_ID>` (el ID de bloqueo está en el mensaje de error). Verificar que nadie más esté ejecutando antes de desbloquear.
Por qué: Los bloqueos no se liberan automáticamente en caso de fallo porque la fase de limpieza nunca se ejecutó.
Un bucket S3 existente creado manualmente necesita ser gestionado por Terraform sin recreación.
Escribir el bloque de recursos, luego `terraform import aws_s3_bucket.legacy legacy-bucket-name`. El estado ahora registra el bucket existente; los planes subsiguientes solo muestran desviación.
Necesidad de importar muchos recursos de forma reproducible a través de CI en lugar de comandos CLI ad-hoc.
Usar el bloque `import` (Terraform 1.5+): `import { to = aws_s3_bucket.legacy, id = "legacy-bucket-name" }`. Las importaciones ocurren durante `apply`, están controladas por versiones y funcionan en la salida del plan.
Depurar un error críptico del proveedor; se necesitan trazas HTTP completas.
`TF_LOG=TRACE` (el más detallado). `TF_LOG_PATH=./tf.log` escribe en un archivo. Otros niveles: DEBUG, INFO, WARN, ERROR.
Probar una expresión como `merge()` o `cidrsubnet()` contra el estado actual sin aplicar.
`terraform console` abre un REPL interactivo con la configuración + estado actual en el ámbito. Útil para prototipar locals y outputs.
Visualizar el DAG de dependencias de una configuración compleja.
`terraform graph | dot -Tsvg > graph.svg` produce una visualización Graphviz de las dependencias de los recursos.
Leer una salida de Terraform desde un script de CI.
`terraform output -json <name>` emite JSON seguro para el análisis con `jq`. El `terraform output` normal está formateado para humanos y no es seguro para scripts.
Forzar la recreación de un único recurso en la próxima aplicación.
`terraform apply -replace=aws_instance.web` (Terraform 1.x). El `terraform taint` heredado está en desuso.
Por qué: `-replace` es revisable en la salida del plan; `taint` mutaba el estado silenciosamente antes del siguiente plan.
Inspeccionar lo que actualmente se rastrea en el estado.
`terraform state list` muestra todas las direcciones de recursos. `terraform state show <addr>` muestra los atributos de un recurso. Para recursos indexados, use comillas: `terraform state show 'aws_instance.web[0]'`.
Elegir una fuente de módulo.
Ruta local → `./modules/vpc`. Registro público → `terraform-aws-modules/vpc/aws`. Git → `git::https://github.com/org/repo.git//path?ref=v1.0`. S3/HTTP/Mercurial también son compatibles.
Fijar un módulo de registro para permitir solo actualizaciones de parche.
`version = "~> 3.5.2"` permite `>= 3.5.2, < 3.6.0`. Para tolerancia a actualizaciones menores, usar `~> 3.0` (cualquier 3.x). Los módulos de ruta local no admiten `version`.
Módulos internos con visibilidad en toda la organización.
Registro de Módulos Privados de HCP Terraform. Dirección: `app.terraform.io/<org>/<name>/<provider>`. Versiones detectadas a partir de etiquetas Git que siguen semver (`v1.2.0`).
¿Tanto el registro público como el registro privado de HCP Terraform detectan las versiones de los módulos mediante qué mecanismo?
Etiquetas Git que siguen el versionado semántico (`v1.2.0` o `1.2.0`). Al empujar una nueva etiqueta → nueva versión disponible.
Exponer el ARN de un bucket creado a la configuración que lo llama.
Dentro del módulo: `output "bucket_arn" { value = aws_s3_bucket.this.arn }`. El que llama lo lee como `module.<name>.bucket_arn`.
Parametrizar un módulo para que los llamadores puedan suministrar CIDR, nombre, etiquetas.
Los bloques `variable` en la raíz del módulo definen las entradas. Los llamadores las pasan en línea: `module "vpc" { source = "...", cidr = "10.0.0.0/16" }`.
El módulo recibe una contraseña de base de datos como entrada; el valor nunca debe aparecer en la salida de la CLI.
Marcar la variable `sensitive = true`. La salida de apply/plan muestra `(sensitive value)`. Nota: todavía se almacena en texto plano en el estado.
Construir un módulo de "plataforma" que internamente llame a módulos de VPC + EKS + RDS.
Un módulo puede llamar a otros módulos. Conectar las salidas de uno como entradas para el siguiente: `eks_subnet_ids = module.vpc.private_subnet_ids`.
Instanciar el mismo módulo N veces con diferentes entradas (ej. uno por región).
`module "regional" { for_each = toset(["us-east-1", "eu-west-1"]), source = "...", region = each.key }`. Referenciar a través de `module.regional["us-east-1"].output_name`.
El módulo necesita un proveedor con alias (ej. para una región no predeterminada).
El llamador pasa un bloque `providers = { aws = aws.us_west }` en la invocación del `module`. El módulo declara `configuration_aliases = [aws.us_west]` en `required_providers`.
Direccionar un módulo de registro público.
`<NAMESPACE>/<NAME>/<PROVIDER>` - ej. `terraform-aws-modules/vpc/aws`. Las etiquetas Git impulsan las versiones.
Reutilizar el mismo módulo en entornos de desarrollo/staging/producción.
Dos patrones: (1) Espacios de trabajo con una configuración raíz + `*.tfvars` por espacio de trabajo. (2) Configuraciones raíz por entorno (`envs/dev/main.tf`, `envs/prod/main.tf`), cada una llamando a módulos compartidos. El patrón 2 es más común para el aislamiento multi-equipo.
Asegurarse de que CI aplica exactamente lo que se revisó en el plan, sin desviaciones entre los pasos.
`terraform plan -out=tfplan` guarda el plan. Luego `terraform apply tfplan` aplica ese plan exacto. Rehusarse a volver a planificar elimina el riesgo de tiempo de verificación/tiempo de uso.
Decodificar los símbolos de salida del plan: `+`, `-`, `~`, `-/+`, `<=`.
`+` crear. `-` destruir. `~` actualizar en su lugar. `-/+` destruir y luego crear (reemplazar). `<=` leer (fuente de datos). El símbolo de reemplazo significa que un atributo `forces replacement` cambió.
Corregir rápidamente un recurso roto sin tocar el resto de la configuración.
`terraform apply -target=aws_instance.web`. Usar con moderación - evade el seguimiento de dependencias y puede dejar el estado inconsistente. Documentar por qué se usó cada `-target`.
Por qué: HashiCorp dice explícitamente que `-target` es para la resolución de problemas excepcionales, no para el flujo de trabajo normal.
Forzar la recreación de un recurso específico.
`terraform apply -replace=aws_instance.web`. Reemplaza el flujo de trabajo obsoleto `terraform taint`.
Eliminar todo en la configuración actual.
`terraform destroy` (o `terraform apply -destroy`). Planifica lo inverso de la configuración. Requiere confirmación a menos que se use `-auto-approve`.
Destruir un recurso sin afectar a otros.
`terraform destroy -target=aws_instance.web`. Las mismas advertencias de `-target` que apply - usar con moderación.
Detectar la desviación sin proponer cambios.
`terraform plan -refresh-only`. Actualiza el estado a partir de los recursos reales e informa las diferencias, pero no genera un plan de modificación de recursos.
Por qué: Reemplaza el comando obsoleto `terraform refresh` independiente.
El Recurso A debe existir antes que el Recurso B, pero B no hace referencia a los atributos de A.
Agregar `depends_on = [resource_a.name]` a B. Usar solo cuando las referencias implícitas de atributos no pueden expresar la dependencia (ej. la política de IAM debe propagarse antes de que EC2 la use).
Reemplazar un recurso sin tiempo de inactividad.
`lifecycle { create_before_destroy = true }`. Terraform crea primero el nuevo recurso, redirige las referencias y luego destruye el antiguo.
Por qué: El valor predeterminado es destruir y luego crear, lo que provoca tiempo de inactividad. Nota: los recursos dependientes también deben soportar el cambio.
Prevenir la destrucción accidental de la base de datos de producción con `terraform destroy`.
`lifecycle { prevent_destroy = true }`. Hace que `terraform plan` falle si se propone una destrucción para ese recurso.
Por qué: Barrera de última línea: no protege contra `terraform state rm` seguido de destroy.
La aplicación establece una etiqueta en tiempo de ejecución que Terraform sigue revirtiendo.
`lifecycle { ignore_changes = [tags["LastDeployed"]] }`. Terraform ignora la desviación en esos atributos.
Reemplazar una instancia EC2 cada vez que una plantilla de lanzamiento relacionada cambia (sin modificar la EC2 directamente).
`lifecycle { replace_triggered_by = [aws_launch_template.web.latest_version] }` (Terraform 1.2+). La instancia se reemplaza cuando cambia cualquier valor listado.
La pipeline de CI/CD aplica después de un trabajo de plan exitoso; no hay un humano al teclado.
`terraform apply -auto-approve` omite la confirmación interactiva. Combinar con un archivo de plan guardado (`terraform apply tfplan`) para hacer que CI sea determinista.
El proveedor de la nube limita la tasa de Terraform; muchas creaciones de recursos fallan intermitentemente.
`terraform apply -parallelism=5` (predeterminado 10) limita las operaciones de recursos concurrentes.
Dos recursos no tienen dependencias entre sí.
Terraform los crea en paralelo. El DAG impone la secuenciación solo a lo largo de los bordes de referencia.
Por qué: Los recursos a la misma profundidad del DAG se ejecutan concurrentemente hasta `-parallelism`.
Variable definida en `terraform.tfvars`, `TF_VAR_region` env, Y flag CLI `-var=region=...`.
Gana el más alto: CLI `-var` / `-var-file` > `*.auto.tfvars` (orden lexicográfico) > `terraform.tfvars` > entorno `TF_VAR_*` > valor predeterminado de la variable.
Pasar valores de variables específicos del entorno sin subir secretos a git.
`terraform apply -var-file=prod.tfvars`. Los archivos `*.auto.tfvars` se cargan automáticamente. `terraform.tfvars` también se carga automáticamente.
Refactorizar el nombre/ruta de un recurso en HCL sin destruir/recrear.
`moved { from = aws_instance.old_web; to = aws_instance.new_web }` (Terraform 1.1+). Revisable en el plan del PR; reemplaza el `terraform state mv` ad-hoc.
Por qué: Vive en HCL, controlado por versiones, idempotente entre colaboradores. `state mv` es un efecto secundario de CLI de un solo uso.
Eliminar un recurso de la configuración sin destruirlo.
`removed { from = aws_instance.legacy; lifecycle { destroy = false } }` (Terraform 1.7+). Reemplaza el `terraform state rm` ad-hoc. Establecer `destroy = true` para también destruir.
CI necesita saber si un plan tiene cambios sin analizar texto.
`terraform plan -detailed-exitcode`. 0 = sin cambios, 1 = error, 2 = cambios presentes. Impulsa trabajos de PR de "solo plan".
¿Qué contiene realmente el estado?
Mapeo de dirección de recurso a ID de recurso en la nube, instantáneas de atributos, metadatos del grafo de dependencias y referencias de módulos/proveedores. Se utiliza para planificar diferencias y detectar desviaciones.
Un solo ingeniero prototipando localmente - ¿es aceptable el estado local?
Sí, para trabajos desechables individuales. Terraform escribe `terraform.tfstate` junto a la configuración. Cambiar a un backend remoto en el momento en que una segunda persona, un ejecutor de CI o un entorno de producción estén involucrados.
El equipo necesita estado compartido entre ingenieros, con bloqueo + versionado, alojado en AWS.
Backend S3. Configurar `bucket`, `key`, `region`. Añadir `dynamodb_table` para el bloqueo de estado. Habilitar el versionado del bucket + el cifrado del lado del servidor SSE-KMS.
Por qué: S3 + DynamoDB es el backend remoto canónico alojado en AWS. El versionado se recupera de estados corruptos o sobrescritos accidentalmente.
Estado compartido alojado en Azure sin credenciales estáticas en CI.
Tipo de backend `azurerm`. Establecer `use_msi = true` (Managed Identity) o `use_oidc = true` para que el ejecutor se autentique a través de su identidad. El lease de blob nativo maneja el bloqueo.
Estado compartido alojado en GCP con versionado de objetos.
Tipo de backend `gcs`. Configurar `bucket` + `prefix`. GCS tiene generaciones de objetos incorporadas (versionado); bloqueo a través de GCS object lock.
Dos ingenieros ejecutan apply simultáneamente contra el mismo estado respaldado por S3.
La tabla de bloqueo de DynamoDB evita escrituras concurrentes. El primero adquiere el bloqueo, el segundo ve un error `state lock failed` y debe esperar o `force-unlock` si está obsoleto.
Por qué: Sin DynamoDB, las aplicaciones concurrentes pueden corromper el archivo de estado de S3.
HCP Terraform - ¿debo configurar DynamoDB?
No. HCP Terraform maneja el estado, el bloqueo y el cifrado de forma nativa. Solo declara `cloud { ... }` en lugar de un backend.
Migrar de estado local a backend S3.
Agregar el bloque `backend "s3"`. Ejecutar `terraform init -migrate-state`. Terraform copia el estado local a S3 y solicita confirmación.
La configuración del backend cambió (ej. nuevo bucket) pero no se quiere migrar el estado existente.
`terraform init -reconfigure`. Reinicializa el backend e ignora el caché local existente. Usar cuando intencionalmente se comienza de cero.
Gestionar dev / staging / prod con una única configuración raíz.
Workspaces - `terraform workspace new staging`, `terraform workspace select prod`. Cada uno tiene su propio archivo de estado. Referenciar a través de `terraform.workspace` en HCL.
Por qué: Opción ligera. Para un aislamiento real (diferente IAM, cuentas separadas), preferir configuraciones raíz por entorno.
¿Dónde almacena el backend local el estado del espacio de trabajo?
Espacio de trabajo `default` → `terraform.tfstate` en la raíz del proyecto. Otros espacios de trabajo → `terraform.tfstate.d/<NAME>/terraform.tfstate`.
Ejecutar `terraform workspace select prod` mientras existen recursos de staging.
Los recursos de staging no se ven afectados. Cambiar de espacio de trabajo solo modifica qué archivo de estado leerá Terraform a continuación, es un cambio de puntero local.
Ver los espacios de trabajo disponibles y el activo.
`terraform workspace list` (el asterisco marca el actual). `terraform workspace show` imprime solo el nombre actual.
El equipo de seguridad pregunta cómo Terraform maneja las contraseñas de RDS en el estado.
Los valores sensibles se almacenan en **texto plano** en el estado. Mitigaciones: cifrar el backend en reposo (S3 SSE-KMS, HCP nativo), restringir el acceso IAM al bucket de estado y evitar poner secretos en Terraform cuando sea posible.
Por qué: El flag `sensitive = true` solo oculta los valores de la salida de la CLI, no del estado.
El cumplimiento normativo exige el cifrado en reposo del estado.
S3: habilitar SSE-KMS en el bucket. Azure: cifrado de la cuenta de almacenamiento (ON por defecto). GCS: claves de cifrado gestionadas por el cliente. HCP Terraform: cifrado nativo en reposo.
Un ingeniero ejecutó `terraform destroy` contra producción por error. El estado ahora está vacío.
Restaurar la versión anterior del archivo de estado desde el versionado de S3, luego ejecutar `terraform plan` para ver qué cree Terraform que ahora necesita ser creado/importado. Combinar con la restauración del lado de la nube (instantáneas, `aws backup`) para los recursos destruidos.
El archivo de estado parece incorrecto; se siente la tentación de editarlo directamente.
No lo haga. Use los subcomandos `terraform state` (`mv`, `rm`, `replace-provider`, `pull`, `push`). Las ediciones manuales de JSON omiten las comprobaciones de integridad y corrompen el linaje.
Inspeccionar el JSON de estado remoto en bruto o subir un archivo de estado recuperado.
`terraform state pull` escribe el estado remoto actual en stdout. `terraform state push <file>` sobrescribe el remoto con el archivo dado. El push es destructivo - haga una copia de seguridad primero.
Pasar un token de API temporal a través de Terraform sin que se guarde en el estado.
Marcar la variable `ephemeral = true` (Terraform 1.10+). Los valores efímeros nunca se persisten en el estado ni en los archivos de plan. Para exportar a través de una salida de módulo, también marcar la salida `ephemeral = true`.
Por qué: `sensitive` se oculta en la CLI pero se almacena en el estado en texto plano. `ephemeral` realmente nunca se almacena.
Diferencia entre un argumento `sensitive` y un argumento de solo escritura (ej. `password_wo`).
`sensitive` se almacena en el estado en texto plano, solo se redacta en la CLI. El argumento de solo escritura **nunca** se almacena en el estado. Para detectar cambios en los atributos de solo escritura, Terraform utiliza un campo de versión complementario (ej. `password_wo_version`).
Mostrar un elemento de un recurso `count` en el estado.
Poner la dirección entre comillas: `terraform state show 'aws_instance.web[0]'`. Sin comillas, el shell podría interpretar los corchetes.
Diferentes equipos necesitan operar de forma independiente sin interferir en el estado del otro.
Un archivo de estado por equipo (o por entorno por equipo). Backends/buckets separados. Usar la fuente de datos `terraform_remote_state` para leer otro estado en modo de solo lectura.
El equipo de red gestiona la VPC; el equipo de aplicaciones necesita el ID de la VPC.
`data "terraform_remote_state" "network" { backend = "s3"; config = { bucket = "...", key = "network/terraform.tfstate" } }`. Referenciar salidas como `data.terraform_remote_state.network.outputs.vpc_id`.
Por qué: Solo lectura - el estado del equipo de red no está bloqueado ni modificado.
Configuración escrita para Terraform 0.13; se quiere usar 1.x.
Los archivos de estado son compatibles con versiones posteriores: 1.x lee el estado 0.13. HashiCorp recomienda actualizaciones incrementales (0.13 → 0.14 → … → 1.x) ejecutando cada versión contra el estado.
Alguien modificó un grupo de seguridad a través de la consola; se quiere que Terraform re-afirme o acepte el nuevo estado.
Re-afirmar: `terraform apply` - Terraform revierte a la configuración. Aceptar: actualizar HCL para que coincida con la realidad, luego aplicar (sin diferencias). Detectar primero con `terraform plan -refresh-only`.
Tipar fuertemente una variable.
Primitivos: `string`, `number`, `bool`. Colecciones: `list(<type>)`, `set(<type>)`, `map(<type>)`. Estructurales: `object({...})`, `tuple([...])`. Usar `any` solo cuando sea verdaderamente polimórfico.
Restringir `environment` a dev/staging/prod.
`variable "environment" { validation { condition = contains(["dev","staging","prod"], var.environment); error_message = "..." } }`. Se permiten múltiples bloques `validation`; todos deben pasar.
Generar una contraseña de base de datos sin que aparezca en `terraform output`.
`output "db_password" { value = ...; sensitive = true }`. La CLI muestra `(sensitive value)`. Todavía se puede leer a través de `terraform output db_password` o `-json` (intencionadamente, para scripts).
Calcular un valor una vez y reutilizarlo en muchos recursos.
`locals { common_tags = merge(var.tags, { Project = var.project }) }`. Referenciar como `local.common_tags`. No se puede anular desde fuera del módulo.
Buscar una AMI existente sin gestionarla.
`data "aws_ami" "ubuntu" { most_recent = true; filter { ... } }`. Solo lectura. Referenciar atributos como `data.aws_ami.ubuntu.id`.
Crear N recursos similares - elegir `count` o `for_each`.
`for_each` (con mapa o conjunto) cuando los elementos tienen identidad estable (nombres de región, claves de entorno). `count` para "Necesito N copias, el orden no importa, la identidad es solo un índice". Añadir/eliminar en medio de `count` causa destruir/recrear; `for_each` preserva la identidad.
Crear un recurso por cada elemento en una lista de strings.
`for_each = toset(["a", "b", "c"])`. `each.key` y `each.value` dan la cadena. Para mapas: `for_each = var.users` - `each.key` = clave del mapa, `each.value` = valor del mapa.
Generar un número variable de bloques anidados (ej. reglas de entrada).
`dynamic "ingress" { for_each = var.rules; content { from_port = ingress.value.from; ... } }`. El argumento `iterator` puede renombrar el iterador si es necesario.
Obtener una lista de atributos de todas las instancias de un recurso `count`.
`aws_instance.web[*].id` devuelve una lista de IDs. Funciona con `count` y `for_each` (pero `for_each` produce un mapa desordenado, por lo que `values(aws_instance.web)[*].id`).
Establecer un valor basándose en una condición.
Ternario: `var.is_prod ? 5 : 1`. Ambas ramas deben producir el mismo tipo.
Combinar dos mapas; los valores del segundo ganan en caso de colisión de claves.
`merge(local.defaults, local.overrides)`. Gana el mapa más a la derecha. Útil para la composición de etiquetas.
Leer un valor de mapa con un valor predeterminado si falta la clave.
`lookup(var.config, "region", "us-east-1")`. Devuelve el valor predeterminado cuando la clave no está presente. Para estructuras profundamente opcionales, preferir la función `try()` opcional.
Colapsar listas anidadas en una lista plana.
`flatten([["a","b"], ["c"], [["d","e"]]])` → `["a","b","c","d","e"]`. Aplana listas recursivamente; preserva el orden.
Insertar un mapa de Terraform en un documento de política de IAM.
`jsonencode({Version = "2012-10-17", Statement = [...]})`. Produce una cadena JSON. Inverso: `jsondecode()`.
Renderizar un script de datos de usuario con plantilla utilizando valores de variables.
`templatefile("init.sh.tpl", { region = var.region, env = var.env })`. La plantilla usa la sintaxis `${region}`. Alternativa más nueva para renderizado estático: `file()` + `format()`.
Dividir CIDRs de subred de un rango de VPC.
`cidrsubnet("10.0.0.0/16", 8, 0)` → `10.0.0.0/24`. Primer argumento = padre, segundo = bits a extender, tercero = número de subred.
Leer un valor que podría no existir; recurrir a un valor predeterminado.
`try(yamldecode(file("config.yaml")), { defaults = true })`. Evalúa de izquierda a derecha; devuelve la primera expresión sin error.
Iterar sobre archivos que coinciden con un patrón glob.
`fileset(path.module, "configs/*.json")` devuelve un conjunto de rutas. Combinar con `for_each` para gestionar un recurso por archivo.
El mismo proveedor en dos regiones (ej. AWS us-east-1 + us-west-2).
Dos bloques `provider "aws" { alias = "..." }`. Los recursos optan por `provider = aws.us_west`. Los módulos aceptan alias a través de `configuration_aliases`.
Ejecutar un comando de shell en una VM recién creada.
Provisioner `remote-exec` dentro de un recurso. Herramienta de último recurso: preferir cloud-init, datos de usuario o gestión de configuración. Los provisioners no se rastrean en el estado y no se vuelven a ejecutar en caso de desviación.
Ejecutar un comando que no corresponde a un recurso en la nube (ej. invocación de CLI).
`resource "null_resource" "trigger" { triggers = { sha = sha1(file(".")) }; provisioner "local-exec" { command = "..." } }`. Se vuelve a ejecutar cuando cambian los `triggers`.
Verificar continuamente un invariante en tiempo de ejecución (ej. el endpoint de salud devuelve 200) sin bloquear la aplicación.
`check "endpoint" { data "http" "h" { url = "..." }; assert { condition = data.http.h.status_code == 200; error_message = "..." } }`. Se ejecuta en plan/apply; la falla es una advertencia, no un error grave.
Por qué: `check` permite fuentes de datos con alcance utilizables solo dentro del chequeo. `precondition`/`postcondition` son errores graves en plan/apply.
Hacer que el plan falle si una AMI es demasiado antigua.
`lifecycle { precondition { condition = data.aws_ami.x.creation_date > "2024-01-01"; error_message = "..." } }`. Falla grave, evaluada antes/después según corresponda.
Variable con un valor posicional de forma fija.
`type = tuple([string, number, bool])` requiere exactamente tres elementos en ese orden. Diferente de una lista (homogénea, longitud variable).
Tipar fuertemente una entrada estructurada (ej. `database = { instance_class = string, allocated_storage = number }`).
`type = object({ instance_class = string, allocated_storage = number, multi_az = optional(bool, false) })`. `optional(<type>, <default>)` hace que los atributos sean opcionales.
¿Cómo se cargan los archivos `*.tfvars`?
`terraform.tfvars` y `*.auto.tfvars` se cargan automáticamente (orden lexicográfico para `auto`). Otros nombres requieren `-var-file=path.tfvars`.
Escribir pruebas automatizadas para un módulo de Terraform.
Archivos `.tftest.hcl` con `run "name" { command = plan|apply, assert { condition = ..., error_message = ... } }`. `command = plan` no tiene efectos secundarios; `command = apply` realmente crea recursos.
Pasar variables a las ejecuciones de prueba.
El bloque `variables { ... }` a nivel de archivo se aplica a todas las ejecuciones. El bloque `variables { ... }` por ejecución anula para esa ejecución solamente.
Elegir un modo de ejecución de espacio de trabajo en HCP Terraform.
Impulsado por VCS (plan automático al hacer push a git, el más común). Impulsado por CLI (el desarrollador ejecuta `terraform plan/apply` localmente, HCP mantiene el estado). Impulsado por API (ejecuciones de Terraform activadas por API, utilizadas por sistemas de automatización/CD).
Orden de las etapas en una ejecución de HCP Terraform.
plan → estimación de costos (si está habilitada) → verificación de políticas (Sentinel/OPA) → aplicación manual o automática. Los fallos obligatorios de políticas o los fallos de tareas de ejecución detienen la pipeline.
Asegurar que todos los buckets S3 estén cifrados, bloqueando la aplicación si se incumple.
Política de Sentinel con aplicación obligatoria estricta. Inspecciona el plan; el fallo bloquea la aplicación. La aplicación obligatoria suave permite la anulación del administrador. La asesoría solo registra pero nunca bloquea.
Integrar un escáner de seguridad de terceros en la pipeline de ejecución de HCP Terraform.
Tarea de ejecución en la etapa post-plan. HCP POSTea el plan a su endpoint; el endpoint responde pasa/falla. La aplicación obligatoria bloquea la aplicación en caso de fallo; la asesoría solo advierte.
Mostrar el impacto de una solicitud de extracción (pull request) antes de fusionarla.
Los planes especulativos se ejecutan en PRs (o ramas), comentan los resultados de vuelta al PR y nunca se aplican. Se activan automáticamente cuando la integración de VCS está habilitada.
Evitar almacenar claves de acceso de AWS como secretos estáticos en variables de HCP Terraform.
Credenciales dinámicas de proveedor. HCP Terraform solicita credenciales de corta duración a través de la confianza OIDC a AWS/Azure/GCP. Sin claves estáticas; identidades por ejecución; amigable para auditorías.
Por qué: Las claves estáticas se filtran. La confianza OIDC vincula las credenciales al espacio de trabajo + ejecución, expira en una hora.
Compartir las mismas credenciales de proveedor en varios espacios de trabajo.
Conjuntos de variables. Definir una vez a nivel de organización/proyecto, adjuntar a muchos espacios de trabajo. Las actualizaciones se propagan sin ediciones por espacio de trabajo.
¿Qué es el Proyecto Predeterminado en HCP Terraform?
Un proyecto integrado que existe en cada organización y no puede ser eliminado (se permite renombrarlo). Todos los espacios de trabajo le pertenecen a menos que se asignen explícitamente a otro proyecto.
Aplicar un espacio de trabajo descendente cada vez que un espacio de trabajo ascendente finaliza una aplicación exitosa.
Activadores de ejecución. Configurar los espacios de trabajo de origen en el espacio de trabajo dependiente; HCP pone en cola una ejecución en el dependiente después de cada aplicación ascendente exitosa.