Lecciones en español / Terraform Associate / Hoja de repaso · English

Hoja de repaso de Terraform Associate Terraform Associate (004)

Cada consejo para el examen y término clave de las lecciones gratuitas de Terraform Associate, por dominio. Usa la opción Imprimir de tu navegador para guardarla como PDF.

Dominio 1: Infrastructure as Code (IaC) with Terraform (8%)

Consejos para el examen

Las preguntas del examen definen IaC por sus propiedades: código guardado en control de versiones y aplicado por una herramienta. Si una respuesta describe documentar pasos manuales o automatizar clics en la consola sin una fuente de verdad, no es el beneficio de IaC por el que se pregunta.
Si una pregunta te pide qué beneficio de IaC permite ver quién cambió la infraestructura y cuándo, la respuesta es el control de versiones y el historial de auditoría; si pregunta por entornos de desarrollo y producción idénticos, la respuesta es la consistencia.
El examen lo formula como "Terraform es declarativo: describes el estado final deseado". Si una respuesta dice que Terraform ejecuta tus pasos en el orden en que los escribiste, es incorrecta; el orden de los bloques en los archivos no importa.
Espera una pregunta de verdadero o falso del tipo "ejecutar terraform apply dos veces sin cambios en la configuración creará recursos duplicados". Es falso: Terraform es idempotente y la segunda ejecución no hace cambios.
Si te preguntan qué componente contiene el código que habla con la API de una nube, la respuesta es el provider, no Terraform core. Core se encarga del lenguaje, el grafo, el estado y el flujo de trabajo.
Las preguntas del examen contrastan Terraform con CloudFormation o las plantillas ARM: la ventaja de Terraform es gestionar muchos providers, incluidas varias nubes, con un solo flujo de trabajo. No es que el mismo bloque resource funcione en todas las nubes.
Si una pregunta te pide si Terraform puede gestionar cosas como equipos de GitHub, registros DNS o dashboards de monitoreo, la respuesta es sí, siempre que exista un provider para la API del servicio.
Cuando el examen pregunte qué herramienta es mejor para crear redes e instancias en la nube, elige Terraform; para gestionar paquetes y archivos dentro de servidores en ejecución, elige la gestión de configuración. Los provisioners son un último recurso.
Debes saber que el orden de reemplazo predeterminado de Terraform es destruir y luego crear, y que create_before_destroy lo invierte. En la salida del plan, -/+ significa reemplazar (destruir y luego crear), mientras que +/- significa crear y luego destruir.

Términos clave

Infrastructure as Code (IaC, infraestructura como código): Gestión de la infraestructura mediante archivos de definición legibles por máquina que una herramienta aplica, en lugar de cambios manuales.
Configuration (configuración): En Terraform, el conjunto de archivos .tf de un directorio que en conjunto describen la infraestructura deseada.
HCL: HashiCorp Configuration Language, el lenguaje declarativo en el que se escriben las configuraciones de Terraform.
Configuration drift (deriva de configuración): Diferencias que se acumulan entre entornos o entre el diseño registrado y la realidad, normalmente por cambios manuales no registrados.
ClickOps: Nombre informal para aprovisionar infraestructura a mano mediante una consola web.
Repeatability (repetibilidad): La capacidad de producir de nuevo la misma infraestructura a partir del mismo código y las mismas entradas.
Consistency (consistencia): Los entornos construidos a partir de las mismas definiciones coinciden entre sí, lo que reduce las sorpresas de "funciona en staging pero no en producción".
Audit trail (rastro de auditoría): El registro, proveniente del control de versiones y de los logs del pipeline, de quién cambió la infraestructura, cuándo y por qué.
CI/CD: Integración continua y entrega continua; pipelines automatizados que prueban y despliegan cambios.
Declarative (declarativo): Describir el estado final deseado y dejar que la herramienta determine los pasos para alcanzarlo.
Imperative (imperativo): Especificar la secuencia exacta de comandos o pasos a realizar.
Desired state (estado deseado): La infraestructura descrita por la configuración, que Terraform intenta hacer realidad.
Provisioner: Una función de Terraform que ejecuta scripts o comandos durante la creación o destrucción de un recurso; se recomienda solo como último recurso.
Idempotence (idempotencia): La propiedad de que repetir una operación produce el mismo resultado que hacerla una vez, sin cambios adicionales.
Drift (deriva): Una diferencia entre la infraestructura real y lo que describen la configuración y el estado, normalmente por cambios manuales.
Refresh (actualización): La parte de la planificación en la que Terraform lee del provider los atributos actuales de los objetos gestionados.
Perpetual diff (diff perpetuo): Un cambio que aparece en cada plan porque un valor no es determinista o la API lo normaliza de forma diferente.
Terraform core: El binario principal de Terraform que analiza la configuración, construye el grafo de dependencias, gestiona el estado y conduce el flujo de trabajo.
Provider (proveedor): Un plugin que permite a Terraform gestionar una plataforma o servicio específico traduciendo las solicitudes en llamadas a su API.
Plugin: Un ejecutable separado que core lanza y con el que se comunica mediante RPC; los providers son plugins.
Data source (fuente de datos): Una consulta de solo lectura, proporcionada por un provider, que obtiene información sobre objetos existentes.
Multi-cloud (multicloud): Usar dos o más proveedores de nube pública juntos.
Hybrid cloud (nube híbrida): Combinar servicios de nube pública con infraestructura privada o local (on-premises).
Native IaC tool (herramienta de IaC nativa): La herramienta de aprovisionamiento propia de un proveedor de nube, como CloudFormation o las plantillas ARM, que solo gestiona los recursos de ese proveedor.
Cross-provider reference (referencia entre providers): Una expresión en el recurso de un provider que usa un atributo del recurso de otro provider, lo que crea una dependencia implícita.
Service-agnostic (independiente del servicio): Capaz de gestionar cualquier servicio que exponga una API, siempre que exista un provider para él.
Terraform Registry: El catálogo público donde se publican providers y módulos, y desde el cual terraform init los descarga de forma predeterminada.
Utility provider (provider de utilidad): Un provider como random, local, tls o http que da soporte a las configuraciones sin gestionar una plataforma en la nube.
Branch protection (protección de ramas): Reglas de una plataforma Git, como las revisiones obligatorias, que pueden codificarse con un provider de Git.
Provisioning (aprovisionamiento): Crear y gestionar los propios recursos de infraestructura, como servidores y redes, normalmente mediante APIs.
Configuration management (gestión de configuración): Instalar y mantener software y ajustes dentro de servidores existentes, como hacen Ansible, Chef, Puppet o Salt.
cloud-init / user_data: Un mecanismo para pasar un script o una configuración de primer arranque a una máquina virtual nueva.
Immutable infrastructure (infraestructura inmutable): Una práctica en la que los componentes desplegados nunca se modifican; los cambios se hacen reemplazándolos por versiones nuevas.
Mutable infrastructure (infraestructura mutable): Servidores que se actualizan y parchean en el lugar durante su vida útil.
Snowflake server (servidor copo de nieve): Un servidor cuya configuración ha derivado hasta volverse única y difícil de reproducir.
Golden image (imagen dorada): Una imagen de máquina preconstruida y versionada que contiene el sistema operativo y el software, usada para lanzar instancias idénticas.
create_before_destroy: Un ajuste de lifecycle que hace que Terraform cree el reemplazo antes de destruir el original.

Dominio 2: Terraform fundamentals (11%)

Consejos para el examen

Recuerda la división: required_version fija la CLI de Terraform; required_providers fija los providers. Ninguno acepta variables, porque el bloque terraform solo admite valores literales.
Si una pregunta muestra source = "hashicorp/aws" y pide la dirección completa, el hostname predeterminado oculto es registry.terraform.io.
Regla del límite superior para ~>: quita el último componente escrito y suma uno al nuevo último componente. ~> 2.1.3 significa < 2.2.0; ~> 2.1 significa < 3.0.
Archivo de bloqueo: haz commit de él. Directorio .terraform/: no hagas commit de él. Y el archivo de bloqueo cubre providers, no módulos.
Los providers se instalan con terraform init, no con plan ni apply, y de forma predeterminada vienen del Terraform Registry público. Agregar o cambiar un provider siempre requiere ejecutar init de nuevo.
El namespace es la pista rápida: hashicorp/... significa official. Los providers partner los mantiene la empresa de tecnología dueña de la API; los community, personas o grupos.
La referencia es aws.west, no "aws.west" ni aws-west. Los recursos sin argumento provider usan la configuración predeterminada (sin alias).
No necesitas una configuración ni un comando separados por cada provider. Una configuración, un init y un apply pueden gestionarlos todos, y las referencias entre ellos crean dependencias automáticamente.
Si te preguntan por el propósito principal del estado, elige asociar los recursos de la configuración con objetos del mundo real. Los metadatos como las dependencias y la caché para el rendimiento son los otros propósitos listados.
sensitive = true oculta los valores en la salida, no en el estado. La protección correcta para los secretos en el estado es un backend seguro, cifrado y con control de acceso, además de valores efímeros o argumentos de solo escritura cuando estén disponibles.

Términos clave

terraform block (bloque terraform): El bloque de nivel superior para ajustes sobre el propio Terraform, como required_version, required_providers y backend.
required_version: Una restricción de versión que la CLI de Terraform en ejecución debe cumplir; de lo contrario, los comandos fallan.
terraform version: Comando que muestra la versión de Terraform instalada, la plataforma y, en un directorio inicializado, las versiones de los providers.
Version constraint (restricción de versión): Una cadena de una o más condiciones, como >= 1.12.0, < 2.0.0, que una versión debe cumplir.
required_providers: Bloque dentro de terraform que declara el nombre local, la dirección source y la restricción de versión de cada provider.
Source address (dirección source): El identificador HOSTNAME/NAMESPACE/TYPE que le indica a Terraform desde dónde descargar un provider.
Namespace (espacio de nombres): La parte de la dirección source que corresponde al publicador, como hashicorp o el nombre de una empresa o usuario.
Local name (nombre local): El nombre de un provider específico del módulo, usado en los bloques provider y asociado a los prefijos de los tipos de recursos.
Semantic versioning (versionado semántico): Esquema de versiones MAJOR.MINOR.PATCH en el que los cambios major pueden romper la compatibilidad, minor agrega funciones y patch corrige bugs.
Pessimistic constraint (~>) (restricción pesimista): Permite que solo aumente el componente de versión especificado más a la derecha.
Exact constraint (=) (restricción exacta): Permite solo una versión específica; también es la única forma de seleccionar una versión preliminar.
Exclusion (!=) (exclusión): Rechaza una versión específica y permite otras que admitan las condiciones restantes.
Dependency lock file (archivo de bloqueo de dependencias): .terraform.lock.hcl, que registra las versiones exactas de los providers y los checksums de los paquetes seleccionados por terraform init.
terraform init -upgrade: Vuelve a seleccionar las versiones más recientes de providers (y módulos) permitidas por las restricciones y actualiza el archivo de bloqueo.
Checksum (hash): Una huella digital de un paquete de provider que se usa para verificar que el archivo descargado es el esperado.
.terraform directory (directorio .terraform): Directorio de trabajo local donde init guarda los providers y módulos descargados; no se incluye en commits.
Provider schema (esquema del provider): La definición del provider de sus tipos de recursos, data sources, argumentos y atributos.
Plugin cache (caché de plugins): Un directorio compartido opcional donde init guarda los paquetes de providers para reutilizarlos entre directorios de trabajo.
Provider mirror (mirror de providers): Una copia local o de red de los paquetes de providers que se usa en lugar del registro público, por ejemplo en redes aisladas.
Computed attribute (atributo calculado): Un valor establecido por el provider o la plataforma después de la creación, como un ID, en lugar de por tu configuración.
Official provider (provider oficial): Provider propiedad de HashiCorp y mantenido por HashiCorp, publicado bajo el namespace hashicorp.
Partner provider (provider de socio): Provider escrito y mantenido por una empresa externa que forma parte del Technology Partner Program de HashiCorp, publicado bajo el namespace de la empresa.
Community provider (provider comunitario): Provider publicado por personas o grupos de la comunidad, sin garantía de soporte de HashiCorp ni de un proveedor.
Archived provider (provider archivado): Un provider que ya no se mantiene, que sigue disponible para que las configuraciones existentes sigan funcionando.
provider block (bloque provider): Configuración de un provider, como la región, el endpoint o los ajustes de autenticación, que normalmente se coloca en el módulo raíz.
alias: Un argumento que da nombre a una configuración adicional, no predeterminada, del mismo provider.
provider meta-argument (meta-argumento provider): Un argumento en un bloque resource o data, como provider = aws.west, que selecciona una configuración específica del provider.
Meta-argument (meta-argumento): Un argumento que maneja el propio Terraform y que puede usarse en cualquier tipo de recurso, como count, for_each, depends_on, provider y lifecycle.
Resource type prefix (prefijo del tipo de recurso): La parte de un tipo de recurso antes del primer guion bajo, como docker en docker_container, que selecciona el provider.
terraform providers: Comando que muestra los providers que requieren la configuración y sus módulos.
Dependency graph (grafo de dependencias): El mapa interno de Terraform de qué objetos dependen de cuáles, usado para ordenar las operaciones en todos los providers.
Partial apply (apply parcial): Un apply que se detiene después de que algunos cambios tienen éxito; el estado registra el trabajo completado para que la siguiente ejecución pueda continuar.
State (estado): El registro de Terraform de los objetos reales que gestiona, sus atributos y metadatos, guardado en terraform.tfstate o en un backend remoto.
Resource address (dirección de recurso): El identificador de un recurso en la configuración y el estado, como aws_instance.web o module.net.aws_vpc.main.
Backend: Dónde guarda Terraform el estado, como el disco local, HCP Terraform o un servicio de almacenamiento en la nube.
State locking (bloqueo del estado): Un mecanismo que impide que operaciones concurrentes escriban el mismo estado al mismo tiempo.
terraform.tfstate: El archivo de estado local predeterminado, un documento JSON que registra los recursos gestionados y sus atributos.
sensitive (sensible): Un indicador en variables y outputs que oculta los valores en la salida de la CLI; los valores igual se guardan en el estado.
Ephemeral value (valor efímero): Un valor que existe solo durante una ejecución de Terraform y nunca se persiste en el estado ni en los archivos de plan.
Serial and lineage (serial y lineage): Metadatos del estado: el serial aumenta con cada escritura, y el lineage identifica el historial de un único estado.

Dominio 3: Core Terraform workflow (19%)

Consejos para el examen

Conoce el orden y el propósito: Write (código), Plan (previsualización y revisión), Apply (aprovisionamiento). En los equipos, el plan se revisa junto con el código antes de aplicar nada.
-migrate-state mueve el estado al nuevo backend; -reconfigure no. -upgrade cambia las versiones de providers y módulos. Ninguna de las opciones de init cambia la infraestructura real.
Validate no contacta las APIs de los providers ni el estado remoto, y no necesita valores de variables, pero sí necesita terraform init primero. Errores como un ID de imagen inexistente solo se detectan en el plan o el apply.
Memoriza los símbolos: + crear, - destruir, ~ actualizar en el lugar, -/+ reemplazar (destruyendo primero), +/- reemplazar (creando primero), <= leer. Plan nunca cambia la infraestructura, aunque sí hace refresh desde los providers.
-refresh=false omite la comprobación de la realidad; -refresh-only hace solo esa comprobación y actualiza el estado. terraform refresh está obsoleto en favor de apply -refresh-only.
Aplicar un archivo de plan guardado no pide aprobación y no acepta nuevas variables. Sin archivo de plan, apply pide confirmación a menos que se use -auto-approve, y solo la palabra exacta yes permite continuar.
terraform destroy equivale a terraform apply -destroy. terraform plan -destroy solo previsualiza. Para eliminar un recurso en el trabajo normal, borra su bloque y aplica en lugar de usar destroy con -target.
fmt solo procesa el directorio actual a menos que agregues -recursive, y -check nunca escribe archivos. fmt comprueba el estilo, no la corrección.
Si una pregunta pide la forma recomendada de forzar la recreación de un recurso, elige terraform apply -replace=ADDRESS, no terraform taint, que está obsoleto.
El paralelismo tiene un valor predeterminado de 10 y cambia cuántas operaciones se ejecutan a la vez, nunca el orden. El orden viene del grafo: referencias implícitas más depends_on, invertido para destroy.

Términos clave

Core workflow (flujo de trabajo central): El ciclo Write, Plan y Apply de Terraform para cambiar la infraestructura.
Speculative plan (plan especulativo): Un plan que se ejecuta solo para revisión, como en un pull request, y que no puede aplicarse.
Remote backend (backend remoto): Almacenamiento compartido del estado, como HCP Terraform, que permite a un equipo usar un solo estado de forma segura con bloqueo.
Pull request: Una solicitud para fusionar cambios de código que permite a los compañeros revisarlos, a menudo con la salida del plan adjunta.
terraform init: Comando que inicializa un directorio de trabajo: configura el backend e instala módulos y providers.
-migrate-state: Opción de init que copia el estado existente a un backend recién configurado.
-reconfigure: Opción de init que configura el backend desde cero, ignorando los ajustes guardados y sin migrar el estado.
Partial configuration (configuración parcial): Dejar los ajustes del backend fuera del código y proporcionarlos con -backend-config en el momento de init.
terraform validate: Comando que comprueba la sintaxis y la consistencia interna de la configuración sin contactar servicios remotos.
Internal consistency (consistencia interna): Si las referencias, los nombres de argumentos, los tipos y los argumentos obligatorios de la configuración concuerdan entre sí y con los schemas de los providers.
Provider schema (esquema del provider): La lista del provider de tipos de recursos, argumentos y tipos, que validate necesita y que se obtiene con terraform init.
-json: Opción que muestra los resultados de la validación en un formato legible por máquina.
Execution plan (plan de ejecución): La previsualización de Terraform de las acciones de crear, actualizar, reemplazar y destruir necesarias para coincidir con la configuración.
-/+ (replace, reemplazar): Símbolo del plan que significa que el objeto existente se destruirá y se creará uno nuevo.
(known after apply): Anotación del plan para valores que el provider solo determinará cuando se lleve a cabo el cambio.
Saved plan (plan guardado): Un plan escrito con -out=FILE que puede aplicarse más tarde exactamente como se revisó.
-var / -var-file: Opciones que establecen valores de variables de entrada en la línea de comandos o desde un archivo; tienen la precedencia más alta y gana la última.
-target: Limita la planificación a recursos o módulos específicos y sus dependencias; solo para uso excepcional.
-refresh-only: Modo de plan o apply que actualiza el estado para que coincida con la infraestructura real sin cambiar esa infraestructura.
-replace: Fuerza el reemplazo de una instancia de recurso específica en el plan.
terraform apply: Comando que lleva a cabo un plan para crear, actualizar o destruir infraestructura y registra los resultados en el estado.
-auto-approve: Omite la confirmación interactiva yes; pensado para automatización con aprobación en otro lugar.
Stale plan (plan obsoleto): Un plan guardado cuyo estado cambió desde que se creó; Terraform se niega a aplicarlo.
Tainted (contaminado): Marca en el estado para un recurso que se sabe dañado, como después de una creación fallida, de modo que se reemplazará.
terraform destroy: Comando que destruye todos los recursos gestionados por la configuración; es un alias de terraform apply -destroy.
plan -destroy: Crea un plan de destrucción para previsualizarlo, y opcionalmente guardarlo, sin destruir nada.
Reverse dependency order (orden inverso de dependencias): Destroy elimina los dependientes antes que los objetos de los que dependen.
prevent_destroy: Ajuste de lifecycle que hace fallar cualquier plan que destruiría el recurso.
terraform fmt: Comando que reescribe los archivos de configuración en el estilo canónico de Terraform sin cambiar su significado.
-check: Opción de fmt que informa los archivos sin formato y termina con un código distinto de cero sin modificarlos.
-diff: Opción de fmt que muestra las diferencias de formato.
-recursive: Opción de fmt que también procesa los archivos de los subdirectorios.
terraform taint: Comando obsoleto que marcaba un recurso en el estado para reemplazarlo en el siguiente apply.
terraform untaint: Comando que quita la marca tainted de un recurso en el estado.
Tainted resource (recurso tainted): Un recurso marcado en el estado como dañado, normalmente después de una creación o un provisioner fallidos, que se reemplazará.
Dependency graph (grafo de dependencias): Grafo acíclico dirigido de los objetos de la configuración que Terraform usa para ordenar las operaciones.
-parallelism: Opción que establece el número máximo de operaciones concurrentes durante plan, apply o destroy; el valor predeterminado es 10.
terraform graph: Comando que genera el grafo de dependencias en formato DOT para visualizarlo.
Cycle (ciclo): Una dependencia circular entre objetos que hace imposible ordenar el grafo; Terraform la informa como error.

Dominio 4: Terraform configuration (22%)

Consejos para el examen

Los data sources se direccionan con el prefijo data. y Terraform nunca los destruye. Si una pregunta del examen pide cómo usar un objeto existente que Terraform no debe gestionar, la respuesta es un data source.
Terraform ordena las operaciones usando referencias, no el orden de los archivos. Si una pregunta pide cómo sabe Terraform que debe crear la red antes que la subred, la respuesta es la dependencia implícita de aws_vpc.main.id.
Precedencia de menor a mayor: variables de entorno TF_VAR_, terraform.tfvars, terraform.tfvars.json, *.auto.tfvars en orden léxico, y luego -var y -var-file. Los archivos que no siguen esos patrones de nombre solo se cargan mediante -var-file.
El bloque es locals, pero la referencia es local.name. Los valores de un módulo hijo solo son accesibles mediante outputs, como module.NAME.OUTPUT_NAME.
Las listas son ordenadas e indexadas; los sets son no ordenados y únicos; los maps tienen claves de tipo cadena. Objects y tuples son las versiones estructurales que permiten tipos mezclados. for_each necesita un map o un set, así que convierte las listas con toset().
Debes saber qué produce cada tipo de corchete: [for ...] da una lista o tupla, {for ... : k => v} da un mapa u objeto. Splat funciona con listas, no con mapas, y dynamic genera bloques anidados, no recursos.
Terraform no admite funciones definidas por el usuario en HCL. Para probar el comportamiento de una función, usa terraform console, que evalúa expresiones sin modificar la infraestructura.
for_each acepta mapas y sets de cadenas, no listas, y da claves estables. Los índices de count se desplazan cuando se eliminan elementos del medio. No puedes usar ambos en un mismo bloque.
Usa depends_on solo para dependencias ocultas. Recuerda que prevent_destroy no impide la destrucción si se elimina todo el bloque del recurso, y que los valores de lifecycle deben ser literales, no variables.
Recuerda la severidad: los fallos de validation, precondition y postcondition son errores que detienen la ejecución, mientras que una aserción fallida de un bloque check es solo una advertencia.
La trampa favorita del examen: sensitive solo oculta los valores en la salida de la CLI. No los cifra ni los mantiene fuera del archivo de estado.
Los secretos leídos de Vault mediante un data source normal terminan en el estado de Terraform. Vault no cambia eso; protege el estado y prefiere secretos de corta duración o efímeros.

Términos clave

Resource block (bloque resource): Declara un objeto de infraestructura que Terraform crea, actualiza y destruye.
Data block (data source, bloque data): Declara una consulta de solo lectura de información existente que Terraform lee pero no gestiona.
Resource address (dirección de recurso): La forma de referencia TYPE.NAME para los recursos y data.TYPE.NAME para los data sources, ampliada con rutas de módulos y claves de instancia.
Local name (nombre local): La segunda etiqueta de un bloque resource o data, elegida por ti y única por tipo dentro de un módulo.
Reference (referencia): Una expresión que usa un valor de otro objeto, como aws_vpc.main.id o var.region.
Implicit dependency (dependencia implícita): Una relación de orden que Terraform deduce automáticamente a partir de una referencia entre objetos.
Computed attribute (atributo calculado): Un atributo que el provider establece después de la creación, como un ID, que a menudo se muestra como known after apply.
moved block (bloque moved): Un bloque que le dice a Terraform que la dirección de un recurso cambió, para que actualice el estado en lugar de reemplazar el objeto.
Input variable (variable de entrada): Un parámetro de un módulo declarado con un bloque variable y referenciado como var.NAME.
TF_VAR_ environment variable (variable de entorno TF_VAR_): Una variable de entorno llamada TF_VAR_<name> que establece una variable del módulo raíz; tiene la precedencia más baja.
terraform.tfvars: Archivo de definiciones de variables que Terraform carga automáticamente desde el directorio del módulo raíz.
nullable: Ajuste de variable (true de forma predeterminada) que controla si se acepta null; cuando es false, null se reemplaza por el default.
sensitive (sensible): Ajuste de variable que oculta el valor en la salida de la CLI, pero no lo mantiene fuera del estado.
Output value (valor de output): Un valor con nombre que exporta un módulo; se muestra en el módulo raíz y se accede como module.NAME.OUTPUT en los módulos hijos.
Local value (valor local): Una expresión con nombre definida en un bloque locals y referenciada como local.NAME, que solo puede usarse dentro de su módulo.
terraform output: Comando que lee del estado los valores de output del módulo raíz, con las opciones -raw y -json.
terraform_remote_state: Data source que lee los outputs del módulo raíz del estado de otra configuración.
Collection type (tipo de colección): list, map o set: muchos valores que comparten el mismo tipo de elemento.
Structural type (tipo estructural): object o tuple: una forma fija cuyos atributos o posiciones pueden tener tipos distintos.
set: Una colección no ordenada de valores únicos sin índice.
optional(): Modificador en un tipo object que hace que un atributo pueda omitirse, opcionalmente con un default.
Type conversion (conversión de tipos): El cambio automático o mediante funciones de un valor a un tipo compatible, como toset() sobre una lista.
Conditional expression (expresión condicional): condition ? a : b, que elige uno de dos valores según un booleano.
for expression (expresión for): Una expresión que construye una lista o un mapa transformando, y opcionalmente filtrando, otra colección.
Splat expression (expresión splat): La forma abreviada [*] que extrae un atributo de cada elemento de una lista, como aws_instance.web[*].id.
String template (plantilla de cadena): Una cadena con interpolación ${...} o directivas %{...}.
dynamic block (bloque dynamic): Una construcción que genera bloques anidados repetidos a partir de una colección usando for_each y content.
Built-in function (función integrada): Una función proporcionada por Terraform, como join o cidrsubnet, que puede llamarse en expresiones; no se admiten funciones definidas por el usuario.
terraform console: Comando interactivo para evaluar expresiones contra la configuración y el estado actuales sin hacer cambios.
lookup: Función que devuelve un valor de un mapa por su clave, o un default cuando falta la clave.
cidrsubnet: Función que calcula el rango de direcciones de una subred dentro de un bloque CIDR más grande.
count: Meta-argumento que crea un número de instancias direccionadas por índice entero.
count.index: El índice, empezando en cero, de la instancia actual en un bloque con count.
for_each: Meta-argumento que crea una instancia por cada elemento de un mapa o set, direccionada por clave.
each.key / each.value: En un bloque con for_each, la clave y el valor del elemento actual; son idénticos para los sets.
depends_on: Meta-argumento que declara una dependencia explícita que ninguna referencia a un atributo expresa.
create_before_destroy: Ajuste de lifecycle que crea el objeto de reemplazo antes de destruir el anterior.
prevent_destroy: Ajuste de lifecycle que hace fallar con un error cualquier plan que destruya el recurso.
ignore_changes: Ajuste de lifecycle que lista los atributos cuyo drift Terraform no debe intentar corregir.
replace_triggered_by: Ajuste de lifecycle que reemplaza el recurso cuando cambian los recursos o atributos referenciados.
validation block (bloque validation): Una regla dentro de un bloque variable con condition y error_message que rechaza valores de entrada incorrectos antes de planificar.
precondition: Una condición de lifecycle (o de output) que se evalúa antes de crear o cambiar un objeto; su fallo es un error que detiene la ejecución.
postcondition: Una condición de lifecycle que se evalúa después de crear, actualizar o leer un objeto; puede usar self para inspeccionar el resultado.
check block (bloque check): Un bloque de nivel superior con condiciones assert, opcionalmente con un data source de alcance limitado, cuyos fallos producen advertencias en lugar de errores.
sensitive = true: Marca una variable o un output para que su valor se oculte en la salida de la CLI; el valor igual se guarda en el estado.
Ephemeral variable (variable efímera): Una variable declarada con ephemeral = true cuyo valor está disponible durante una ejecución, pero nunca se escribe en el plan ni en el estado.
Ephemeral resource (recurso efímero): Un bloque ephemeral que obtiene un valor temporal (como un secreto o un token) en cada ejecución sin persistirlo.
Write-only argument (argumento de solo escritura): Un argumento de recurso que acepta un valor y lo pasa al provider, pero nunca lo guarda en el plan ni en el estado; suele ir acompañado de un argumento de versión.
HashiCorp Vault: Una herramienta de gestión de secretos que guarda, controla el acceso, audita y genera dinámicamente secretos.
Dynamic secret (secreto dinámico): Una credencial que Vault genera bajo demanda con un lease y revoca automáticamente cuando el lease vence.
Vault provider (provider de Vault): El provider de Terraform que se usa para configurar Vault y leer secretos de él mediante data sources o recursos efímeros.
Lease (arrendamiento): El período durante el cual un secreto de Vault es válido antes de que deba renovarse o se revoque.

Dominio 5: Terraform modules (11%)

Consejos para el examen

Si una pregunta pide qué convierte a un directorio en un módulo, la respuesta es simplemente que contiene archivos de configuración de Terraform; el módulo raíz es aquel desde el que ejecutas los comandos.
Conoce las formas de las direcciones: ./ o ../ significa local, tres partes separadas por barras significan registro público, un hostname más tres partes significa registro privado, y git:: o ?ref= significa un origen Git.
Los argumentos de un bloque module (salvo los meta-argumentos) se corresponden uno a uno con los bloques variable del hijo; una variable obligatoria faltante o un argumento no declarado son ambos errores.
Los valores bajan solo mediante los argumentos del bloque module y suben solo mediante los outputs; un hijo nunca puede leer directamente los valores var. del padre.
Las configuraciones de provider predeterminadas se heredan automáticamente; las que tienen alias nunca se heredan y deben pasarse con el mapa providers en el bloque module.
version es solo para módulos de registro; los módulos Git se fijan con ?ref=. Recuerda también que el archivo de bloqueo no fija las versiones de los módulos.
Agregar o cambiar el source o la version de un módulo requiere init (o get); cambiar solo los valores de entrada del módulo no. Nunca hagas commit del directorio .terraform.
Prefiere for_each sobre count cuando las instancias son distintas y pueden eliminarse individualmente; los índices de count se desplazan cuando se elimina un elemento del medio.
Los nombres de archivo son una convención, no un requisito: Terraform fusiona todos los archivos .tf de un directorio, pero la estructura estándar (main, variables, outputs, README) es lo que esperan el registro y los revisores.

Términos clave

Module (módulo): Cualquier directorio que contenga archivos de configuración de Terraform; Terraform trata todos los archivos .tf que contiene como una unidad.
Root module (módulo raíz): El módulo del directorio de trabajo donde se ejecutan los comandos de Terraform; la cima del árbol de módulos.
Child module (módulo hijo): Un módulo llamado por otro módulo mediante un bloque module.
Module address (dirección de módulo): La ruta hasta un recurso a través del árbol de módulos, como module.network.aws_subnet.private.
source argument (argumento source): El argumento obligatorio del bloque module que le dice a Terraform dónde encontrar el código del módulo.
Registry source (origen de registro): Una dirección de módulo con la forma NAMESPACE/NAME/PROVIDER, precedida de un hostname en los registros privados.
Local path source (origen de ruta local): Una ruta de módulo que empieza con ./ o ../ y que Terraform lee directamente del disco sin descargarla.
Double-slash subdirectory (subdirectorio con doble barra): La sintaxis // en una dirección source que selecciona un subdirectorio dentro de un repositorio o archivo comprimido descargado.
module block (bloque module): Un bloque que llama a un módulo hijo, dándole un nombre local, un source y valores para sus variables de entrada.
Input variable (variable de entrada): Una variable declarada en el módulo hijo que quienes lo llaman establecen como argumento en el bloque module.
Required input (entrada obligatoria): Una variable de módulo sin default; quienes llaman deben proporcionarla o Terraform informa un error.
Meta-arguments (meta-argumentos): Argumentos que maneja el propio Terraform en un bloque module: source, version, count, for_each, providers y depends_on.
Module scope (alcance del módulo): La regla de que cada módulo tiene su propio espacio de nombres y ve solo sus propias variables, locals y recursos.
Output value (valor de output): Un valor que un módulo exporta con un bloque output, que quien lo llama puede leer como module.NAME.OUTPUT.
Re-exporting (volver a exportar): Declarar un output del módulo raíz cuyo valor es un output de un módulo hijo, para que aparezca en terraform output.
TF_VAR_ environment variable (variable de entorno TF_VAR_): Una variable de entorno que establece una variable de entrada del módulo raíz; no llega directamente a los módulos hijos.
Provider alias (alias de provider): Una configuración adicional con nombre de un provider, creada con el meta-argumento alias y referenciada como PROVIDER.ALIAS.
providers argument (argumento providers): Un mapa en un bloque module que asigna las configuraciones de provider de quien llama a los nombres de provider que usa el módulo hijo.
Implicit provider inheritance (herencia implícita de providers): El comportamiento predeterminado en el que los módulos hijos usan automáticamente las configuraciones de provider predeterminadas, sin alias, del padre.
configuration_aliases: Un ajuste de required_providers en un módulo hijo que declara nombres adicionales de configuración de provider que quien llama debe pasar.
version argument (argumento version): Un argumento del bloque module que establece una restricción de versión; válido solo para orígenes de módulos de registro.
ref parameter (parámetro ref): Un parámetro de consulta en una dirección de origen Git que selecciona la etiqueta, rama o commit que se obtendrá.
Pessimistic constraint (~>) (restricción pesimista): Un operador de versión que permite que solo aumente el componente especificado más a la derecha, como ~> 1.4, que permite 1.x a partir de 1.4.
Dependency lock file (archivo de bloqueo de dependencias): .terraform.lock.hcl, que registra las versiones y los hashes de los providers, pero no las versiones de los módulos.
.terraform/modules: El directorio oculto dentro del directorio de trabajo donde Terraform guarda el código de los módulos descargados y el manifiesto modules.json.
terraform get: Un comando que solo descarga y actualiza módulos, sin inicializar backends ni providers.
terraform init -upgrade: Vuelve a evaluar las restricciones de versión e instala las versiones más recientes permitidas de módulos y providers.
modules.json: Un manifiesto en .terraform/modules que registra el source, la versión y el directorio de instalación de cada llamada a módulo.
count on a module (count en un módulo): Crea un número de instancias del módulo direccionadas por índice, como module.web[0].
for_each on a module (for_each en un módulo): Crea una instancia del módulo por cada clave de mapa o elemento de set, direccionada por clave, como module.web["blue"].
each.key / each.value: Valores disponibles dentro de un bloque con for_each que identifican el elemento actual.
Legacy module (módulo legacy): Un módulo que contiene sus propios bloques provider; no puede usarse con count, for_each ni depends_on.
main.tf: El archivo principal convencional de un módulo, que contiene sus recursos principales y sus llamadas a módulos.
variables.tf: El archivo convencional que contiene las declaraciones de variables de entrada de un módulo, que forman su interfaz de entrada.
outputs.tf: El archivo convencional que contiene las declaraciones de outputs de un módulo, que forman su interfaz de salida.
terraform-PROVIDER-NAME: La convención de nombres de repositorio requerida para los módulos publicados en el Terraform Registry público.

Dominio 6: Terraform state management (11%)

Consejos para el examen

Sin bloque backend significa el backend local, que escribe terraform.tfstate más un terraform.tfstate.backup de un solo paso en el directorio de trabajo.
El bloqueo es automático en los backends que lo admiten. force-unlock necesita el ID de bloqueo y es un último recurso; -lock-timeout espera un bloqueo en lugar de fallar de inmediato.
El bloque backend va dentro de terraform {}, solo en el módulo raíz, y cualquier cambio en él requiere ejecutar terraform init de nuevo.
Si una pregunta muestra var. dentro de un bloque backend, la respuesta es que no está permitido; usa en su lugar archivos -backend-config o pares clave/valor en init.
Para que tus recursos sigan rastreados al cambiar de backend, usa -migrate-state; -reconfigure empieza de cero con el nuevo backend y no copia nada.
El bloque cloud y un bloque backend son mutuamente excluyentes; el bloque cloud selecciona workspaces por nombre (uno) o por etiquetas (varios) y puede anularse con TF_CLOUD_ORGANIZATION y TF_WORKSPACE.
sensitive = true no es cifrado. Protege el estado con un backend remoto cifrado y con control de acceso, y mantenlo fuera del control de versiones.
apply -refresh-only solo actualiza el estado y nunca cambia la infraestructura; para conservar un cambio manual de forma permanente también debes actualizar la configuración.
Los workspaces de la CLI separan solo el estado, no las credenciales ni los backends; no se recomiendan como frontera de aislamiento para entornos de producción.

Términos clave

State (estado): El registro de Terraform que asocia los recursos de la configuración con objetos reales, con sus atributos y metadatos.
Local backend (backend local): El backend predeterminado, que guarda el estado en un archivo en el disco local.
terraform.tfstate: El archivo de estado JSON que el backend local escribe en el directorio de trabajo.
terraform.tfstate.backup: Una copia del estado anterior que el backend local escribe antes de reemplazar terraform.tfstate.
State locking (bloqueo del estado): Una función del backend que permite solo una operación de Terraform que escriba el estado a la vez, para evitar la corrupción.
-lock-timeout: Un indicador que hace que Terraform reintente adquirir un bloqueo ocupado durante un tiempo dado antes de fallar.
terraform force-unlock: Elimina manualmente un bloqueo abandonado usando su ID de bloqueo; solo debe usarse cuando no hay ninguna operación en ejecución.
Lock ID (ID de bloqueo): El identificador que se muestra en un error de bloqueo y que force-unlock necesita para liberar ese bloqueo específico.
Backend: El componente que determina dónde se guarda el estado de Terraform y si puede bloquearse.
backend block (bloque backend): Un bloque dentro de terraform {} que selecciona un tipo de backend y establece sus argumentos; solo uno por módulo raíz.
Remote backend (backend remoto): Un backend que guarda el estado en un servicio compartido como S3, Azure Storage, GCS, Consul o PostgreSQL.
key (s3/azurerm): La ruta o el nombre del blob bajo el cual se guarda el archivo de estado en el bucket o contenedor.
Partial configuration (configuración parcial): Dejar algunos argumentos del backend fuera del bloque backend y proporcionarlos en el momento de terraform init.
-backend-config: Un indicador de init que proporciona ajustes del backend, ya sea como pares KEY=VALUE o como la ruta a un archivo de configuración.
Backend configuration file (archivo de configuración del backend): Un archivo HCL con argumentos del backend que se pasa con -backend-config, a menudo con el sufijo .tfbackend.
Early evaluation (evaluación temprana): La razón por la que los backends no pueden usar variables: los backends se inicializan antes de que se evalúen las variables y los locals.
terraform init -migrate-state: Reinicializa con un backend cambiado y copia el estado existente del backend anterior al nuevo.
terraform init -reconfigure: Reinicializa con un backend cambiado ignorando los ajustes del backend anterior y sin migrar el estado.
-force-copy: Un indicador de init que responde automáticamente que sí a los avisos de migración del estado.
terraform state pull: Muestra el estado actual desde el backend configurado; útil para hacer un respaldo antes de una migración.
cloud block (bloque cloud): Un bloque dentro de terraform {} que conecta una configuración a HCP Terraform o Terraform Enterprise para el estado y las ejecuciones.
organization: El argumento del bloque cloud que nombra la organización de HCP Terraform dueña de los workspaces.
workspaces { name / tags }: El bloque anidado que asocia la configuración a un workspace por nombre o a varios por etiquetas.
Execution mode (modo de ejecución): Un ajuste del workspace que decide si las ejecuciones se hacen de forma remota en HCP Terraform, localmente o en agentes.
Secrets in state (secretos en el estado): El hecho de que Terraform guarda en el estado los atributos de los recursos, incluidas contraseñas y claves, en texto plano.
Encryption at rest (cifrado en reposo): La protección del estado almacenado por parte del servicio de almacenamiento del backend, como el cifrado del lado del servidor de S3.
Access control (control de acceso): Permisos de IAM o de la plataforma que restringen quién puede leer o escribir el almacenamiento del estado.
terraform_remote_state: Un data source que lee los outputs raíz del estado de otra configuración, lo que requiere acceso a ese estado.
Drift (deriva): Una diferencia entre la infraestructura real y el estado que Terraform registró por última vez, normalmente por cambios hechos fuera de Terraform.
Refresh (actualización): El paso en el que Terraform lee de los providers el estado actual de los objetos gestionados antes de planificar.
-refresh-only: Un modo de plan o apply que solo actualiza el estado para que coincida con la infraestructura real, sin cambiar ningún recurso.
ignore_changes: Un ajuste de lifecycle que le indica a Terraform que ignore los cambios en atributos específicos al planificar.
CLI workspace (workspace de la CLI): Un estado separado y con nombre para la misma configuración y el mismo backend, gestionado con los comandos terraform workspace.
default workspace (workspace default): El workspace en el que empieza toda configuración; no se puede eliminar.
terraform.workspace: Una expresión que devuelve el nombre del workspace actual para usarlo en la configuración.
terraform.tfstate.d: El directorio donde el backend local guarda el estado de los workspaces que no son default.

Dominio 7: Maintain infrastructure with Terraform (8%)

Consejos para el examen

Los bloques import se revisan en el plan y se aplican como otros cambios; -generate-config-out escribe HCL inicial en un archivo que no debe existir previamente.
terraform import necesita que el bloque resource exista primero, importa un objeto a la vez y no genera configuración; los bloques import eliminan esos límites.
state list da direcciones, state show da los atributos de un recurso, show da todo (o un archivo de plan) y output da solo los outputs raíz.
Renombrar un recurso sin moved ni state mv hace que Terraform planee una destrucción y una creación; moved es la opción declarativa y revisable.
Eliminar solo un bloque resource significa destruir. Para dejar de gestionar sin eliminar, usa un bloque removed con destroy = false o terraform state rm.
TRACE es el nivel más detallado, JSON produce logs de nivel TRACE en formato JSON, y TF_LOG_PATH no hace nada a menos que se establezca un nivel de log.
Usa los logs para errores de providers y fallos; incluye en los reportes de bugs la salida de terraform version, una configuración mínima y un log TRACE sin datos sensibles.
terraform output -json muestra los valores sensibles en texto plano; terraform graph produce DOT, que renderizas con Graphviz.

Términos clave

import block (bloque import): Un bloque declarativo con to e id que le indica a Terraform que ponga un objeto existente bajo una dirección de recurso durante plan y apply.
Import ID (ID de importación): El identificador específico del provider de un objeto existente, como un ID de instancia o el nombre de un bucket.
-generate-config-out: Un indicador de terraform plan que escribe en un archivo nuevo el HCL generado para los destinos de importación que no tienen bloques resource.
Adopting infrastructure (adoptar infraestructura): Poner recursos creados manualmente bajo la gestión de Terraform sin recrearlos.
terraform import: Un comando de la CLI que escribe de inmediato un objeto existente en el estado en una dirección de recurso dada.
ADDRESS: La dirección del recurso en la configuración a la que se vinculará el objeto importado.
Prerequisite resource block (bloque resource previo): El bloque resource que ya debe existir en la configuración para que terraform import tenga éxito.
Post-import plan (plan posterior a la importación): Ejecutar terraform plan después de importar y ajustar la configuración hasta que no se muestren cambios.
terraform state list: Lista las direcciones de todos los recursos del estado, opcionalmente filtradas por un prefijo de dirección.
terraform state show: Muestra todos los atributos registrados de una instancia de recurso en el estado.
terraform show: Muestra todo el estado, o un archivo de plan guardado, en forma legible o en JSON.
terraform output: Muestra los valores de output del módulo raíz desde el estado, con las opciones -json y -raw para scripts.
moved block (bloque moved): Un bloque de configuración con from y to que registra un cambio de dirección para que Terraform actualice el estado en lugar de reemplazar el objeto.
terraform state mv: Un comando de la CLI que cambia de inmediato la dirección de un objeto en el estado.
Refactoring (refactorización): Reestructurar la configuración (renombrar, mover a módulos) sin cambiar la infraestructura real.
Resource address (dirección de recurso): El identificador que usa Terraform para rastrear un objeto, como module.app.aws_instance.web[0].
removed block (bloque removed): Un bloque de configuración que le dice a Terraform que deje de gestionar una dirección, destruyéndola o no según el destroy de lifecycle.
destroy = false: El ajuste de lifecycle del bloque removed que elimina el objeto del estado dejando la infraestructura real en su lugar.
terraform state rm: Un comando de la CLI que elimina de inmediato la entrada de un recurso del estado sin afectar al objeto real.
Unmanaged resource (recurso no gestionado): Un objeto real que existe pero no está rastreado en ningún estado de Terraform.
TF_LOG: Variable de entorno que habilita el registro de Terraform en el nivel TRACE, DEBUG, INFO, WARN, ERROR o JSON.
TF_LOG_PATH: Variable de entorno que escribe (agregando al final) la salida de los logs en un archivo en lugar de en la salida de error estándar.
TF_LOG_CORE: Variable de entorno que establece el nivel de log solo para Terraform core.
TF_LOG_PROVIDER: Variable de entorno que establece el nivel de log solo para los plugins de los providers.
Provider error (error de provider): Un fallo en un plugin de provider o en la API remota a la que llama, que a menudo se diagnostica con los logs del provider.
Crash (panic, fallo): Una terminación inesperada de Terraform o de un plugin que imprime un stack trace y que debe reportarse con logs.
terraform version: Comando que muestra la versión de Terraform y las versiones de los providers instalados, necesarias para los reportes de bugs.
Minimal reproduction (reproducción mínima): La configuración más pequeña que todavía muestra el problema, incluida en un reporte de bug.
terraform output -json: Muestra los outputs raíz como JSON con los campos value, type y sensitive, revelando los valores sensibles.
terraform graph: Muestra el grafo de dependencias de la configuración o del plan en formato DOT.
DOT / Graphviz: Un lenguaje de descripción de grafos y el conjunto de herramientas (incluido el comando dot) que lo convierte en una imagen.
Implicit dependency (dependencia implícita): Una dependencia que Terraform deduce de una expresión que referencia los atributos de otro recurso.

Dominio 8: HCP Terraform (10%)

Consejos para el examen

Terraform Cloud se renombró como HCP Terraform; Terraform Enterprise es la versión autoalojada. Evita memorizar precios; debes saber qué funciones son centrales y cuáles son de gobernanza.
terraform login guarda un token en credentials.tfrc.json; en CI usa TF_TOKEN_<host> en su lugar. En el bloque cloud, workspaces usa name (uno) o tags (varios), nunca ambos.
En el flujo de trabajo VCS, los pull requests disparan ejecuciones especulativas (solo de plan); los merges a la rama rastreada disparan ejecuciones reales. Los workspaces conectados a VCS no aceptan applies desde la CLI.
Los workspaces de HCP Terraform son entornos completos con permisos separados (estado, variables, ejecuciones, acceso); los workspaces de la CLI solo separan el estado.
Jerarquía: la organización contiene proyectos, los proyectos contienen workspaces; cada workspace está exactamente en un proyecto, y el acceso a nivel de proyecto cubre todos sus workspaces.
Las credenciales de los providers van en variables de entorno, no en variables de Terraform. Las variables sensibles son de solo escritura; los variable sets prioritarios anulan los valores del workspace.
Las verificaciones de políticas se ejecutan después del plan y antes del apply. Conoce los tres niveles de Sentinel: advisory advierte, soft-mandatory puede anularse, hard-mandatory no.
Las evaluaciones de estado solo detectan e informan; nunca cambian la infraestructura ni el estado. La detección de drift equivale a un plan refresh-only programado.
Asocia la función: los run triggers encadenan workspaces, los run tasks llaman a verificaciones externas, las notificaciones envían alertas y las credenciales dinámicas de providers reemplazan las claves estáticas de la nube por credenciales OIDC por ejecución.

Términos clave

HCP Terraform: El servicio alojado de HashiCorp (antes Terraform Cloud) para estado remoto, ejecuciones remotas y colaboración en equipo con Terraform.
Terraform Enterprise: La distribución autoalojada de HCP Terraform para organizaciones que lo ejecutan en su propia infraestructura.
Remote run (ejecución remota): Un plan o apply de Terraform que se ejecuta en los workers de HCP Terraform, con la salida visible en la interfaz y en la CLI.
State version history (historial de versiones del estado): El registro de cada estado guardado en un workspace, que puede consultarse y usarse para la recuperación.
terraform login: Un comando que obtiene un token de API de HCP Terraform mediante el navegador y lo guarda localmente para la CLI.
credentials.tfrc.json: El archivo local donde terraform login guarda los tokens de API en texto plano.
TF_TOKEN_hostname: Una variable de entorno que proporciona un token de API para un host dado, como TF_TOKEN_app_terraform_io.
Workspace tags mapping (asociación de workspaces por etiquetas): Usar tags en el bloque cloud para que una configuración se asocie a varios workspaces de HCP Terraform.
VCS-driven workflow (flujo de trabajo basado en VCS): Un workspace conectado a una rama de un repositorio, donde los commits disparan ejecuciones y los pull requests disparan planes especulativos.
CLI-driven workflow (flujo de trabajo basado en la CLI): Ejecuciones iniciadas desde la CLI local de terraform que suben la configuración y se ejecutan de forma remota en HCP Terraform.
API-driven workflow (flujo de trabajo basado en la API): Ejecuciones iniciadas por herramientas externas que suben versiones de configuración y crean ejecuciones mediante la API de HCP Terraform.
Speculative plan (plan especulativo): Una ejecución solo de plan que muestra los cambios propuestos pero nunca puede aplicarse, usada para las verificaciones de pull requests.
HCP Terraform workspace (workspace de HCP Terraform): Un contenedor para una colección de infraestructura con su propio estado, variables, historial de ejecuciones, ajustes y permisos.
Run history (historial de ejecuciones): La lista registrada de los planes y applies de un workspace con logs, disparadores y versiones del estado resultantes.
Auto-apply: Un ajuste del workspace que aplica automáticamente los planes exitosos en lugar de esperar una confirmación manual.
Remote state sharing (compartición del estado remoto): Un ajuste del workspace que controla qué otros workspaces pueden leer sus outputs.
Project (proyecto): Un contenedor de HCP Terraform que agrupa workspaces relacionados para su organización y control de acceso.
Default project (proyecto predeterminado): El proyecto en el que se colocan los workspaces nuevos cuando no se especifica otro.
Project-level team access (acceso de equipos a nivel de proyecto): Permisos otorgados a un equipo en un proyecto que se aplican a todos sus workspaces actuales y futuros.
Organization (organización): El contenedor de nivel superior de HCP Terraform que contiene proyectos, workspaces, equipos y ajustes.
Terraform variable (category) (variable de Terraform, categoría): Una variable del workspace que establece una variable de entrada de Terraform declarada en la configuración.
Environment variable (category) (variable de entorno, categoría): Una variable del workspace exportada a la shell de la ejecución, usada para credenciales de providers y ajustes de Terraform.
Sensitive variable (variable sensible): Una variable de solo escritura cuyo valor no puede verse después de guardarse, pero está disponible para las ejecuciones.
Variable set: Un grupo reutilizable de variables que se aplica a workspaces seleccionados, a proyectos o a toda la organización.
Owners team (equipo owners): El equipo integrado con control administrativo total de una organización de HCP Terraform.
Sentinel: El framework de políticas como código de HashiCorp, con los niveles de aplicación advisory, soft-mandatory y hard-mandatory.
OPA (Open Policy Agent): Un motor de políticas de código abierto que usa el lenguaje Rego, compatible con HCP Terraform con los niveles advisory y mandatory.
Private registry (registro privado): Un registro exclusivo de la organización para compartir módulos y providers aprobados con versionado.
Health assessment (evaluación de estado): Una comprobación automática y programada de HCP Terraform sobre un workspace para detectar drift y condiciones fallidas.
Drift detection (detección de drift): La parte de las evaluaciones de estado que usa planes refresh-only para encontrar cambios hechos fuera de Terraform.
Continuous validation (validación continua): La parte de las evaluaciones de estado que vuelve a evaluar los bloques check y las pre/postcondiciones entre ejecuciones.
Drifted workspace (workspace con drift): Un workspace cuya infraestructura real ya no coincide con su estado guardado.
Run trigger: Un enlace que pone automáticamente en cola una ejecución en un workspace después de que un workspace de origen aplica con éxito.
Run task: Una integración que envía datos de la ejecución a un servicio externo en una etapa determinada y puede bloquear la ejecución si falla.
Notification configuration (configuración de notificaciones): Un ajuste del workspace que envía eventos de ejecuciones y de salud a correo electrónico, herramientas de chat o webhooks.
Dynamic provider credentials (credenciales dinámicas de providers): Credenciales de nube de corta duración obtenidas en cada ejecución intercambiando un token de identidad de carga de trabajo OIDC de HCP Terraform.

Estudia Terraform Associate gratis
Plan semana a semana con lecciones, cuestionarios, simulaciones de examen y práctica, en español.

Abrir el plan de estudio