Domande sui colloqui Terraform: Guida completa all'Infrastructure as Code 2026

Le domande sui colloqui Terraform verificano la capacità di un candidato di gestire l'infrastruttura cloud in modo dichiarativo, mantenere lo state in sicurezza e progettare moduli riutilizzabili. Con Terraform 1.14 che ora supporta le variabili nei module sources e HCP Terraform che amplia la propria piattaforma di esecuzione gestita, nel 2026 gli intervistatori si aspettano che i candidati dimostrino sia conoscenze fondamentali di HCL sia consapevolezza del panorama IaC in evoluzione.

Concetti fondamentali di Terraform per ogni candidato

Cos'è Terraform e come si differenzia dagli altri strumenti IaC?

Terraform è uno strumento dichiarativo di Infrastructure as Code che gestisce le risorse cloud attraverso file di configurazione scritti in HCL (HashiCorp Configuration Language). A differenza di strumenti imperativi come Ansible o script shell, Terraform mantiene un file di state che traccia l'infrastruttura attuale e calcola un diff (il "plan") prima di applicare le modifiche.

I principali elementi distintivi: Terraform è cloud-agnostico (con supporto per AWS, Azure, GCP e centinaia di altri provider), utilizza un workflow plan-before-apply che previene sorprese e gestisce le dipendenze delle risorse attraverso un grafo aciclico diretto (DAG) interno.

Una risposta completa considera anche il cambiamento nell'ecosistema: da quando HashiCorp ha adottato la licenza BSL nel 2023, OpenTofu è emerso come fork open-source sotto la Linux Foundation. Entrambi gli strumenti condividono la stessa sintassi HCL ma stanno divergendo nelle funzionalità. Terraform 1.14 si concentra sull'integrazione con la piattaforma HCP, mentre OpenTofu 1.9 dà priorità alla crittografia dello state e ai backend dinamici.

Il workflow Terraform: init, plan, apply, destroy

I quattro comandi fondamentali formano il ciclo di vita di ogni operazione Terraform:

# 1. Inizializzazione - scarica provider e moduli
terraform init

# 2. Pianificazione - mostra cosa cambierà senza modificare nulla
terraform plan -out=tfplan

# 3. Applicazione - esegue le modifiche pianificate
terraform apply tfplan

# 4. Distruzione - elimina tutte le risorse gestite
terraform destroy

terraform init scarica i plugin dei provider e inizializza il backend. terraform plan confronta lo stato desiderato (file di configurazione) con lo stato attuale (file di state) e produce un changeset. terraform apply esegue tale changeset. Salvare il plan in un file con -out garantisce che venga applicato esattamente il plan revisionato, aspetto essenziale nelle pipeline CI/CD.

Gestione dello State: L'argomento più comune nei colloqui

Cos'è lo state di Terraform e perché è importante?

Lo state di Terraform è un file JSON (terraform.tfstate) che mappa le risorse di configurazione agli oggetti infrastrutturali reali. Senza lo state, Terraform non può determinare cosa esiste, cosa è cambiato o cosa deve essere eliminato.

Lo state contiene ID delle risorse, valori degli attributi e metadati sulle dipendenze. La perdita dello state significa che Terraform perde traccia di tutte le risorse gestite, richiedendo l'importazione manuale di ogni singolo oggetto o, peggio ancora, lasciando risorse cloud orfane che continuano a generare costi.

Come dovrebbero i team gestire lo state in produzione?

I file di state locali sono inaccettabili per ambienti di team. La configurazione standard per la produzione utilizza un backend remoto con locking:

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

Questa configurazione memorizza lo state in S3 con crittografia lato server e utilizza DynamoDB per il locking dello state. Il lock impedisce a due sviluppatori (o due pipeline CI) di eseguire apply contemporaneamente, il che corromperebbe lo state.

HCP Terraform (precedentemente Terraform Cloud) offre un'alternativa gestita che fornisce archiviazione dello state, locking, cronologia delle esecuzioni e RBAC senza infrastruttura aggiuntiva. Per le organizzazioni già investite nell'ecosistema HashiCorp, elimina l'overhead di gestione di bucket S3 e tabelle DynamoDB.

Best practice per il file di state

• Non committare mai terraform.tfstate nel controllo di versione. Potrebbe contenere secrets (password di database, chiavi API) in chiaro.
• Abilitare la crittografia a riposo sul backend (S3 SSE, crittografia GCS o crittografia Azure Storage).
• Utilizzare file di state separati per ogni ambiente. Un singolo file di state per dev, staging e produzione è una ricetta per distruzioni accidentali.
• Implementare il locking dello state. Ogni backend remoto che lo supporta dovrebbe avere il locking abilitato.
• Usare terraform state list e terraform state show per ispezionare lo state senza modificarlo.

Moduli: Componenti infrastrutturali riutilizzabili

Come funzionano i moduli Terraform?

Un modulo è una directory contenente file .tf che incapsulano un insieme di risorse. Ogni configurazione Terraform è tecnicamente un modulo (il modulo root). I moduli child vengono richiamati dal modulo root per promuovere il riutilizzo e applicare standard.

# main.tf - richiamo di un modulo
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
}

Terraform 1.14 ha introdotto un miglioramento significativo: variabili e locals possono ora essere utilizzati negli attributi source e version dei moduli. Questa era precedentemente una limitazione rigida che forzava workaround come Terragrunt per il sourcing dinamico dei moduli.

Cosa rende un modulo ben progettato?

Un modulo production-grade segue questi principi:

• Input e output chiari: Ogni variabile ha una descrizione, un vincolo di tipo e un valore predefinito sensato dove appropriato. Gli output espongono i valori necessari ai moduli a valle.
• Scope minimo: Un modulo gestisce un componente logico (un VPC, un cluster di database, un namespace Kubernetes), non un intero ambiente.
• Nessun valore hardcoded: Configurazione del provider, regione, ID account e valori specifici dell'ambiente provengono da variabili, mai da letterali all'interno del modulo.
• Release versionati: I moduli pubblicati utilizzano il versionamento semantico. Il pinning su version = "5.16.0" previene breaking changes inattese.

Workspace, ambienti e struttura del progetto

Come dovrebbero essere gestiti più ambienti?

Esistono tre pattern comuni, ciascuno con compromessi distinti:

| Pattern | Meccanismo | Indicato per | Rischio | |---------|-----------|-------------|--------| | Workspace | terraform workspace select prod | Progetti semplici, stessa configurazione per ambiente | Backend state condiviso, facile applicare al workspace sbagliato | | Directory per ambiente | Directory separate dev/, staging/, prod/ | Isolamento completo tra ambienti | Duplicazione del codice tra directory | | Terragrunt | Wrapper DRY che genera configurazioni backend | Setup multi-account di grandi dimensioni | Dipendenza da tool aggiuntivo |

L'approccio con directory per ambiente e moduli condivisi è il più comune in produzione. Ogni directory di ambiente contiene un main.tf che richiama gli stessi moduli con valori di variabili diversi, e ciascuno ha il proprio file di state isolato.

Qual è la differenza tra terraform workspace e l'isolamento tramite directory?

I workspace creano file di state nominati all'interno dello stesso backend. Il passaggio tra workspace con terraform workspace select staging cambia quale file di state Terraform legge e scrive, ma la configurazione rimane identica.

La limitazione: i workspace condividono la stessa configurazione del backend e del provider. L'isolamento tramite directory fornisce confini più solidi — ogni ambiente può utilizzare un account AWS diverso, un backend state diverso o persino versioni diverse dei provider. Per ambienti regolamentati che richiedono un controllo rigoroso del blast radius, l'isolamento tramite directory è la scelta più sicura.

Provider, data source e ciclo di vita delle risorse

Cosa sono i provider e come vengono configurati?

I provider sono plugin che traducono la configurazione HCL in chiamate API verso piattaforme specifiche. Il provider AWS chiama l'API AWS, il provider Kubernetes comunica con il server API Kubernetes, e così via.

# 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
    }
  }
}

Il vincolo di versione ~> 5.80 consente aggiornamenti patch (5.80.x) ma blocca i bump di versione minor, bilanciando stabilità e patch di sicurezza. Il blocco default_tags applica un tagging coerente a ogni risorsa creata dal provider — un punto di discussione frequente nei colloqui per governance e allocazione dei costi.

Data source versus risorse

Le risorse (blocchi resource) creano, aggiornano ed eliminano l'infrastruttura. I data source (blocchi data) leggono l'infrastruttura esistente senza gestirla.

# Data source - legge un AMI esistente, non crea nulla
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-*"]
  }
}

# Risorsa - crea un'istanza EC2 utilizzando il data source
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

I data source vengono valutati durante il plan, rendendoli utili per referenziare infrastruttura condivisa (VPC creati da un altro team), cercare valori dinamici (ID AMI più recenti) o leggere configurazioni esterne (parametri SSM, secrets di Vault).

Argomenti avanzati: Import, blocchi Moved e Testing

Come funziona terraform import e quando è necessario?

terraform import associa una risorsa cloud esistente a un blocco resource di Terraform. Lo scenario tipico: l'infrastruttura è stata creata manualmente (ClickOps) o da un altro strumento, e il team vuole ora gestirla con Terraform.

Terraform 1.5+ ha introdotto i blocchi import direttamente nella configurazione, sostituendo il workflow basato solo su CLI:

# 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"
}

L'esecuzione di terraform plan con questo blocco genera un piano che adotta il bucket esistente nello state. Questo approccio di importazione dichiarativa è revisionabile nelle pull request, ripetibile e non richiede accesso CLI diretto allo state.

Cosa sono i blocchi moved?

Il refactoring del codice Terraform (rinominare risorse, spostarle in moduli) storicamente richiedeva comandi terraform state mv. Il blocco moved gestisce questo in modo dichiarativo:

# Risorsa rinominata da "web" a "app"
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Terraform riconosce lo spostamento durante il plan e aggiorna lo state automaticamente, evitando un ciclo di destroy-e-recreate. Questo è inestimabile nella ristrutturazione di configurazioni di grandi dimensioni in moduli.

Come funziona il testing di Terraform?

Terraform 1.6+ include un framework di testing nativo che utilizza file .tftest.hcl:

# 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"
  }
}

Terraform 1.14 ha ampliato questa funzionalità con blocchi mock che accettano funzioni, skip_cleanup per il debug di test falliti e blocchi backend all'interno dei blocchi run per state di test isolati. Il testing nativo elimina la necessità di strumenti esterni come Terratest per la validazione di base.

Terraform nelle pipeline CI/CD

Come appare una pipeline Terraform di produzione?

Una pipeline CI/CD robusta per Terraform impone sicurezza in ogni fase:

1. Lint e validazione: terraform fmt -check e terraform validate catturano problemi di sintassi.
2. Plan su PR: Ogni pull request esegue terraform plan e pubblica l'output come commento alla PR. Nessun apply senza un plan revisionato.
3. Controlli delle policy: Strumenti come OPA (Open Policy Agent), Sentinel (HCP Terraform) o Checkov validano il plan rispetto alle policy organizzative (nessun bucket S3 pubblico, crittografia obbligatoria, tag richiesti).
4. Apply al merge: Dopo l'approvazione della PR e il superamento dei controlli delle policy, terraform apply viene eseguito automaticamente dal file di plan salvato.
5. Backup dello state: Dopo l'apply, la pipeline verifica l'integrità dello state e il versioning del backend registra la nuova versione dello state.

La regola d'oro: nessun essere umano dovrebbe mai eseguire terraform apply contro la produzione da una macchina locale. Tutti gli apply in produzione passano attraverso la pipeline.

Conclusione

I punti chiave per la preparazione ai colloqui su Terraform:

• La gestione dello state è l'argomento più importante in assoluto. Backend remoti, locking, crittografia e strategie di disaster recovery devono essere compresi prima di presentarsi a un colloquio.
• La progettazione dei moduli separa i candidati junior da quelli senior. La capacità di costruire moduli riutilizzabili, versionati, con interfacce chiare e scope minimo deve essere dimostrata.
• Comprendere a fondo il workflow plan/apply. Saper spiegare perché salvare i plan in file è importante, come il DAG determina l'ordine di esecuzione e cosa fa -target (e perché dovrebbe essere usato con parsimonia).
• Terraform 1.14 porta variabili nei module sources, testing espanso e integrazione più stretta con HCP. Menzionare le funzionalità attuali dimostra un coinvolgimento attivo con l'ecosistema.
• Affrontare onestamente il panorama Terraform vs OpenTofu. Comprendere la scissione delle licenze, la divergenza delle funzionalità e quando ogni strumento è appropriato dimostra maturità architetturale oltre la conoscenza della sintassi.
• Studiare le basi dei colloqui DevOps parallelamente alle specificità di Terraform, poiché gli intervistatori spesso mescolano domande IaC con argomenti infrastrutturali più ampi.
• Ripassare i concetti di deployment Kubernetes dato che Terraform frequentemente provisiona i cluster su cui girano i workload Kubernetes.