Preguntas de entrevista sobre Terraform: guia completa de Infrastructure as Code 2026

Las preguntas de entrevista sobre Terraform representan uno de los filtros mas exigentes en procesos de seleccion para roles de infraestructura y DevOps en 2026. Con el lanzamiento de Terraform 1.14 y la consolidacion de HCP Terraform como plataforma gestionada, los equipos de contratacion esperan que los candidatos dominen no solo la sintaxis de HCL, sino tambien la gestion del state, el diseno de modulos y la integracion con pipelines CI/CD. Este articulo reune las preguntas mas relevantes, organizadas por nivel de complejidad, con ejemplos de codigo listos para replicar.

Conceptos fundamentales de Terraform

Que es Terraform y en que se diferencia de otras herramientas IaC?

Terraform es una herramienta de infraestructura como codigo (IaC) que utiliza un enfoque declarativo: el usuario describe el estado deseado de la infraestructura en archivos de configuracion escritos en HCL (HashiCorp Configuration Language), y Terraform se encarga de calcular las diferencias entre el estado actual y el deseado para ejecutar los cambios necesarios. A diferencia de herramientas imperativas como scripts de Bash o Ansible en modo ad-hoc, Terraform mantiene un archivo de estado (state file) que funciona como fuente de verdad para toda la infraestructura gestionada.

Una de las ventajas principales es su naturaleza agnostica respecto a proveedores de nube. El mismo flujo de trabajo aplica para AWS, Azure, GCP, Kubernetes o cualquier servicio que ofrezca un provider compatible. Terraform genera un plan de ejecucion (plan diff) que permite revisar exactamente que recursos se crearan, modificaran o eliminaran antes de aplicar cualquier cambio.

Es importante mencionar el cambio de licencia de 2023: HashiCorp migro Terraform de Mozilla Public License a Business Source License (BSL). Esto origino el fork OpenTofu, mantenido por la Linux Foundation bajo licencia abierta. En 2026, Terraform 1.14 y OpenTofu 1.9 han divergido significativamente en funcionalidades: Terraform 1.14 incorpora variables en bloques de modulo source y mejoras en el provider framework, mientras que OpenTofu 1.9 implemento state encryption nativa y un enfoque distinto para funciones personalizadas. Los entrevistadores esperan que el candidato conozca ambas opciones y pueda articular las diferencias.

El flujo de trabajo de Terraform: init, plan, apply, destroy

El ciclo de vida de Terraform se apoya en cuatro comandos principales que todo candidato debe poder explicar con precision.

# 1. Initialize - downloads providers and modules
terraform init

# 2. Plan - shows what will change without modifying anything
terraform plan -out=tfplan

# 3. Apply - executes the planned changes
terraform apply tfplan

# 4. Destroy - tears down all managed resources
terraform destroy

terraform init descarga los providers requeridos y los modulos referenciados, creando el directorio .terraform/. Este comando es idempotente y debe ejecutarse cada vez que se agrega un nuevo provider o modulo. terraform plan compara la configuracion actual con el state existente y genera un plan de ejecucion detallado. El flag -out=tfplan guarda el plan en un archivo binario, lo cual es fundamental en pipelines CI/CD: garantiza que el apply ejecute exactamente los cambios que fueron revisados y aprobados, sin recalcular el diff.

terraform apply tfplan ejecuta las operaciones planificadas. Si se ejecuta sin un archivo de plan, Terraform genera un plan nuevo y solicita confirmacion interactiva. En entornos productivos, la practica recomendada es siempre separar plan y apply en etapas distintas del pipeline, con una aprobacion manual entre ambas. terraform destroy elimina todos los recursos gestionados por la configuracion actual. En la practica, este comando se usa principalmente en entornos efimeros (desarrollo, testing) y casi nunca en produccion.

Gestion del state: el tema mas frecuente en entrevistas

Que es el state de Terraform y por que es fundamental?

El state de Terraform es un archivo JSON (terraform.tfstate) que mapea cada recurso definido en la configuracion con su correspondiente recurso real en el proveedor de nube. Sin este archivo, Terraform no puede determinar que recursos ya existen, cuales deben crearse y cuales requieren modificacion. Es la pieza central de toda operacion de Terraform.

Perder el state tiene consecuencias graves: Terraform considerara que ningun recurso existe y tratara de recrear toda la infraestructura, generando conflictos con los recursos ya desplegados. En el mejor caso, el apply falla por nombres duplicados. En el peor, se crean recursos duplicados que generan costos inesperados y configuraciones inconsistentes. Por esta razon, la gestion del state es consistentemente el tema numero uno en entrevistas tecnicas de Terraform.

Como gestionar el state en produccion?

El state nunca debe almacenarse localmente en entornos productivos. La configuracion estandar utiliza un backend remoto con soporte de bloqueo para prevenir escrituras concurrentes.

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/networking/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Este ejemplo configura un bucket S3 como backend con encriptacion habilitada y una tabla DynamoDB para el mecanismo de locking. Cuando un operador ejecuta terraform plan o terraform apply, Terraform adquiere un lock en DynamoDB antes de leer o escribir el state. Si otro proceso intenta ejecutar simultaneamente, recibira un error de lock hasta que el primero termine. Este mecanismo previene corrupciones del state por escrituras concurrentes.

HCP Terraform (antes Terraform Cloud) ofrece una alternativa gestionada que resuelve backend, locking, historial de ejecuciones y control de acceso en una sola plataforma. Para equipos que prefieren no administrar la infraestructura del state manualmente, HCP Terraform simplifica considerablemente la operacion.

Buenas practicas para el archivo state

• Nunca almacenar el state en un repositorio de control de versiones (Git). Contiene datos sensibles como IDs de recursos, IPs y potencialmente valores de outputs marcados como sensitive.
• Habilitar encriptacion en reposo en el backend (SSE-S3, KMS o equivalente segun el proveedor).
• Separar el state por entorno y por dominio de infraestructura. Un state monolitico que gestione toda la infraestructura de produccion introduce riesgo excesivo y tiempos de plan prolongados.
• Configurar siempre un mecanismo de locking. Sin locking, dos ejecuciones simultaneas pueden corromper el state de forma irrecuperable.
• Utilizar terraform state list y terraform state show para inspeccionar el contenido del state sin modificarlo. El comando terraform state mv permite reorganizar recursos entre modulos sin destruir y recrear.

Modulos: componentes de infraestructura reutilizables

Como funcionan los modulos en Terraform?

Un modulo en Terraform es simplemente un directorio que contiene archivos .tf. Todo proyecto de Terraform tiene al menos un modulo: el modulo raiz (root module), que es el directorio desde donde se ejecutan los comandos. Los modulos hijos (child modules) son directorios adicionales que encapsulan configuraciones reutilizables y se invocan desde el modulo raiz o desde otros modulos.

# main.tf - calling a module
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.16.0"

  name = "production-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
}

Este ejemplo invoca un modulo publico del registro de Terraform para crear una VPC completa con subredes publicas y privadas. El atributo version fija una version especifica del modulo, lo cual es esencial para reproducibilidad. Terraform 1.14 introduce la posibilidad de usar variables dentro del atributo source de los modulos, lo que facilita patrones avanzados como la seleccion dinamica de modulos segun el entorno.

Que caracteriza a un modulo bien disenado?

• Interfaz clara: variables de entrada (variables.tf) documentadas con tipos, descripciones y valores por defecto cuando corresponda. Outputs (outputs.tf) que expongan solo la informacion necesaria para otros modulos.
• Alcance minimo y responsabilidad unica. Un modulo de VPC no deberia crear instancias EC2. Un modulo de base de datos no deberia configurar el DNS.
• Sin valores hardcodeados: regiones, nombres de cuenta, CIDR blocks y cualquier valor que varie entre entornos deben parametrizarse como variables.
• Versionado con releases semanticos. Los modulos internos deben publicarse con tags de version en Git, y los modulos publicos deben consumirse siempre con una version fija.
• Incluir validaciones con bloques validation en las variables para detectar configuraciones invalidas antes de ejecutar el plan.

Workspaces, entornos y estructura del proyecto

Como gestionar multiples entornos?

La gestion de multiples entornos (desarrollo, staging, produccion) es un tema recurrente en entrevistas. Existen tres patrones principales, cada uno con ventajas y limitaciones.

| Patron | Mecanismo | Ideal para | Riesgo | |--------|-----------|------------|--------| | Workspaces | terraform workspace select prod | Proyectos simples, misma config por entorno | Backend compartido, riesgo de apply en workspace equivocado | | Directorio por entorno | Directorios separados dev/, staging/, prod/ | Aislamiento total entre entornos | Duplicacion de codigo | | Terragrunt | Wrapper DRY que genera configs de backend | Grandes despliegues multi-cuenta | Dependencia de herramienta adicional |

El patron de directorio por entorno es el mas comun en organizaciones medianas y grandes. Cada directorio contiene su propio backend.tf, sus valores de variables (terraform.tfvars) y puede referenciar modulos compartidos. Este enfoque garantiza que un error en el entorno de desarrollo jamas afecte produccion, ya que los states estan completamente aislados.

Cual es la diferencia entre workspaces y aislamiento por directorio?

Los workspaces de Terraform son una abstraccion liviana que permite mantener multiples states dentro del mismo directorio de configuracion. Al cambiar de workspace con terraform workspace select, Terraform utiliza un state diferente pero la misma configuracion. Esto funciona bien para proyectos simples donde las diferencias entre entornos se reducen a valores de variables.

Sin embargo, los workspaces comparten el mismo backend y la misma configuracion. En equipos grandes, esto presenta riesgos operacionales significativos: un operador puede olvidar cambiar de workspace y ejecutar un apply destructivo en produccion cuando pretendia modificar desarrollo. El aislamiento por directorio elimina esta clase de errores porque cada entorno es una ejecucion completamente independiente con su propio backend y su propio state. La contrapartida es la duplicacion de configuracion, que se mitiga mediante modulos compartidos y herramientas como Terragrunt.

Providers, data sources y ciclo de vida de los recursos

Que son los providers y como se configuran?

Los providers son plugins que permiten a Terraform interactuar con APIs de servicios externos: proveedores de nube, plataformas SaaS, sistemas DNS, entre otros. Cada provider debe declararse con su fuente y restriccion de version.

# providers.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.80"
    }
  }
}

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Environment = var.environment
      ManagedBy   = "terraform"
      Team        = var.team_name
    }
  }
}

La restriccion ~> 5.80 permite actualizaciones dentro de la version minor (5.80.x, 5.81.x, etc.) pero bloquea cambios de version major. Esta estrategia equilibra la recepcion de parches de seguridad con la estabilidad de la API. El bloque default_tags aplica etiquetas automaticamente a todos los recursos AWS creados por este provider, lo cual es fundamental para gobernanza, costos y auditoria.

Data sources versus recursos

# Data source - reads an existing AMI, does not create anything
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"]
  }
}

# Resource - creates an EC2 instance using the data source
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

La distincion entre data sources y recursos es una pregunta clasica. Los recursos (resource) representan componentes de infraestructura que Terraform crea, actualiza y destruye. Los data sources (data) consultan informacion de recursos existentes que no son gestionados por la configuracion actual. En el ejemplo, el data source lee la AMI mas reciente de Ubuntu sin crear ni modificar nada, y el recurso la utiliza para lanzar una instancia EC2.

Los data sources son particularmente utiles para integrar infraestructura legacy o recursos gestionados por otros equipos. Permiten referenciar IDs, ARNs y atributos de recursos existentes sin acoplar su ciclo de vida al de la configuracion actual.

Temas avanzados: import, moved blocks y testing

Como funciona terraform import?

La importacion de recursos existentes a la gestion de Terraform es un escenario frecuente en migraciones. Terraform 1.5 introdujo los bloques import declarativos, que reemplazan al comando imperativo terraform import y pueden incluirse directamente en la configuracion.

# import.tf
import {
  to = aws_s3_bucket.legacy_data
  id = "my-legacy-bucket-name"
}

resource "aws_s3_bucket" "legacy_data" {
  bucket = "my-legacy-bucket-name"
}

Al ejecutar terraform plan, Terraform detecta el bloque import, lee el estado actual del recurso desde AWS y genera un plan que muestra como sincronizar la configuracion local con el recurso real. Este enfoque es auditable (el bloque import queda en el codigo) y compatible con pipelines automatizados, a diferencia del comando imperativo que requeria ejecucion manual.

Que son los bloques moved?

Cuando se reorganiza la estructura de un proyecto (renombrar recursos, moverlos entre modulos), el riesgo es que Terraform interprete el cambio como una eliminacion seguida de una creacion. Los bloques moved permiten declarar refactorizaciones de forma segura.

# Renamed a resource from "web" to "app"
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Terraform actualizara el state para reflejar el nuevo nombre sin destruir ni recrear el recurso. Esto es especialmente valioso en infraestructura productiva donde recrear un recurso puede implicar downtime o perdida de datos.

Como funcionan los tests en Terraform?

Terraform 1.6 introdujo un framework de testing nativo con archivos .tftest.hcl. Los tests permiten validar la configuracion contra condiciones esperadas sin necesidad de herramientas externas.

# tests/vpc.tftest.hcl
run "creates_vpc_with_correct_cidr" {
  command = plan

  assert {
    condition     = aws_vpc.main.cidr_block == "10.0.0.0/16"
    error_message = "VPC CIDR block does not match expected value"
  }
}

run "creates_three_private_subnets" {
  command = plan

  assert {
    condition     = length(aws_subnet.private) == 3
    error_message = "Expected 3 private subnets"
  }
}

Los tests con command = plan validan la configuracion sin crear recursos reales, lo que los hace rapidos y economicos. Tambien es posible usar command = apply para tests de integracion que crean infraestructura efimera, validan condiciones y destruyen automaticamente al finalizar. Este framework nativo reemplaza en muchos casos a herramientas como Terratest, simplificando la configuracion del pipeline de testing.

Terraform en pipelines CI/CD

Como se ve un pipeline de Terraform en produccion?

La integracion de Terraform en pipelines CI/CD sigue un flujo predecible con etapas claramente definidas:

1. Checkout y validacion: el pipeline clona el repositorio, ejecuta terraform fmt -check para verificar formato y terraform validate para detectar errores de sintaxis.
2. Init: ejecuta terraform init con el backend configurado para el entorno objetivo.
3. Plan: genera el plan de ejecucion con terraform plan -out=tfplan. Los cambios planificados se publican como comentario en el pull request para revision del equipo.
4. Aprobacion manual: un revisor autorizado valida los cambios propuestos. Esta etapa es critica y no debe automatizarse en entornos productivos.
5. Apply: una vez aprobado, el pipeline ejecuta terraform apply tfplan utilizando exactamente el plan generado anteriormente.
6. Verificacion post-deploy: ejecuta smoke tests o health checks para confirmar que la infraestructura esta operativa.

La regla de oro en pipelines de Terraform: nunca ejecutar terraform apply sin un plan previamente guardado y revisado. La separacion entre plan y apply es el mecanismo fundamental de seguridad que previene cambios accidentales en produccion.

Conclusion

Preparar una entrevista de Terraform requiere profundidad en areas que van mucho mas alla de la sintaxis basica de HCL. Los temas que consistentemente determinan el resultado de una entrevista son:

• La gestion del state es el tema de mayor peso. Dominar backends remotos, locking, recovery y particionamiento del state demuestra experiencia operacional real.
• El diseno de modulos es lo que separa a un perfil junior de uno senior. Modulos con interfaces claras, alcance minimo y versionado semantico reflejan madurez en ingenieria de infraestructura.
• Comprender el ciclo plan/apply en profundidad, incluyendo la separacion de etapas en CI/CD y la revision obligatoria de planes, evidencia criterio para operar infraestructura critica.
• Las funcionalidades de Terraform 1.14, como variables en module source y mejoras en el framework de testing, son puntos que demuestran actualizacion tecnica.
• Conocer la diferencia entre Terraform y OpenTofu, sus licencias y sus divergencias funcionales, permite responder con criterio a preguntas sobre estrategia tecnologica.
• Para complementar la preparacion, explorar los fundamentos de entrevistas DevOps y los conceptos de despliegue en Kubernetes proporciona una vision integral del ecosistema de infraestructura moderna.