# Ansible vs Terraform 2026: Infrastructure as Code e Domande per Colloqui DevOps

> Confronto completo tra Ansible e Terraform per colloqui DevOps. Gestione dello state, approcci dichiarativi vs procedurali e best practice per Infrastructure as Code.

- Published: 2026-08-22
- Updated: 2026-08-22
- Author: Anthony Fillion-Maillet
- Tags: ansible, terraform, infrastructure-as-code, devops, interview
- Reading time: 12 min

---

Ansible vs Terraform rappresenta una delle domande di confronto più frequenti nei colloqui DevOps, ma la formulazione stessa rivela un fraintendimento: questi strumenti risolvono problemi differenti. Ansible 2.20 gestisce il configuration management e il deployment delle applicazioni, mentre Terraform 1.15 effettua il provisioning delle risorse infrastrutturali. Comprendere quando ciascuno eccelle, dove si sovrappongono e come si completano a vicenda distingue i Senior DevOps Engineer da chi sta ancora imparando i fondamentali.

> **La Distinzione Fondamentale**
>
> Terraform gestisce lo state dell'infrastruttura in modo dichiarativo (VM, reti, database). Ansible configura proceduralmente ciò che gira su quell'infrastruttura (pacchetti, servizi, file). La maggior parte degli ambienti di produzione utilizza entrambi.

## Dichiarativo vs Procedurale: La Differenza Fondamentale

Terraform utilizza un approccio dichiarativo. Un file di configurazione descrive lo stato finale desiderato, e Terraform calcola le modifiche necessarie per raggiungerlo. Questo funziona bene per l'infrastruttura che deve essere creata, modificata o distrutta come unità.

```hcl
# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
```

L'esecuzione di `terraform apply` crea entrambe le risorse se non esistono, oppure le aggiorna per corrispondere alla configurazione. Eseguirlo nuovamente senza modifiche non produce operazioni: Terraform confronta la configurazione con il suo file di state e non trova nulla da fare.

Ansible utilizza un approccio procedurale con task eseguiti in ordine. Mentre i moduli Ansible sono spesso idempotenti (eseguirli due volte produce lo stesso risultato), il playbook stesso descrive una sequenza di azioni piuttosto che uno stato finale.

```yaml
# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted
```

Ogni task viene eseguito in sequenza. Il pattern notify/handler fornisce un comportamento parzialmente dichiarativo: l'handler viene eseguito solo una volta alla fine, indipendentemente da quanti task lo attivano.

## Gestione dello State: Un Argomento Critico per i Colloqui

Terraform mantiene un [file di state](https://developer.hashicorp.com/terraform/language/state) che mappa la configurazione alle risorse reali. Questo state traccia gli ID delle risorse, le dipendenze e i metadati. Senza di esso, Terraform non può determinare cosa esiste o cosa deve essere modificato.

| Aspetto | Terraform | Ansible |
|---------|-----------|----------|
| Storage dello state | Richiesto (file locale o backend remoto) | Nessuno di default |
| Rilevamento del drift | Integrato via `terraform plan` | Richiede controlli espliciti |
| Tracciamento risorse | Automatico attraverso lo state | Basato su inventory |
| Rollback | Distruggere e ricreare dallo state | Nessun rollback nativo |

Ansible non ha un file di state equivalente. Si connette ai sistemi target ed esegue i task, affidandosi allo stato corrente del sistema e all'idempotenza dei moduli. Questo rende Ansible più semplice per iniziare ma più difficile per tracciare i cambiamenti nel tempo.

Una domanda frequente nei colloqui riguarda la sicurezza del file di state. Lo state di Terraform può contenere dati sensibili: password di database, chiavi API, identificatori di risorse. I deployment in produzione memorizzano lo state remotamente (S3, Azure Blob, Terraform Cloud) con crittografia e controlli di accesso.

```hcl
# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}
```

La tabella DynamoDB fornisce il locking, impedendo a due sviluppatori di modificare lo state simultaneamente.

## Quando Utilizzare Ciascuno Strumento

Terraform eccelle nel provisioning dell'infrastruttura cloud: macchine virtuali, database gestiti, load balancer, ruoli IAM, VPC. Gestisce automaticamente le dipendenze tra le risorse e supporta tutti i principali provider cloud attraverso una sintassi HCL coerente.

Ansible eccelle nella configurazione di sistemi esistenti: installazione di pacchetti, gestione degli utenti, deployment del codice applicativo, orchestrazione di deployment multi-step. Si connette via SSH (o WinRM per Windows) senza richiedere agent sui sistemi target.

La zona di sovrapposizione crea confusione. Entrambi possono installare software su una VM. Terraform può usare i [provisioner](https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax) per eseguire script dopo la creazione delle risorse. Ansible può creare risorse cloud attraverso moduli come `amazon.aws.ec2_instance`. Ma utilizzare ogni strumento al di fuori dei suoi punti di forza porta a problemi di manutenibilità.

> **Evitare Questo Anti-Pattern**
>
> L'utilizzo estensivo dei provisioner di Terraform per il configuration management crea infrastruttura fragile. I provisioner vengono eseguiti solo al momento della creazione, non nelle apply successive. Utilizzare Terraform per l'infrastruttura, poi passare ad Ansible per la configurazione.

## Il Workflow Combinato in Produzione

La maggior parte delle organizzazioni utilizza entrambi gli strumenti insieme. Terraform effettua il provisioning dell'infrastruttura ed emette i dettagli di connessione. Ansible consuma questi output per configurare i sistemi.

```hcl
# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}
```

Una pipeline CI/CD esegue prima Terraform, cattura gli output, genera dinamicamente un inventory Ansible, poi esegue i playbook contro la nuova infrastruttura.

```yaml
# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"
```

Questo inventory dinamico interroga AWS direttamente, raggruppando le istanze per i loro tag. Nessuna gestione manuale degli IP richiesta.

## OpenTofu: Il Fork che ha Cambiato il Panorama

HashiCorp ha rilicenziato Terraform sotto la Business Source License (BSL) nell'agosto 2023. La community ha risposto creando un fork di Terraform 1.5 in [OpenTofu](https://opentofu.org/), ora ospitato sotto la Linux Foundation.

Ad agosto 2026, OpenTofu 1.11.6 rimane un sostituto drop-in per la maggior parte dei workflow Terraform. Stessa sintassi HCL, stesso ecosistema di provider, stesso formato di state. OpenTofu ha aggiunto funzionalità non presenti nel binario open-source di Terraform: crittografia dello state, provider `for_each` e valutazione anticipata delle variabili.

Per la preparazione ai colloqui, è importante comprendere la distinzione delle licenze. La BSL permette l'uso interno ma limita la costruzione di prodotti concorrenti. Le organizzazioni preoccupate per il vendor lock-in o con requisiti di compliance specifici potrebbero preferire la licenza MPL 2.0 di OpenTofu. L'acquisizione di HashiCorp da parte di IBM nel dicembre 2024 ha aggiunto un'altra variabile alle discussioni sulle relazioni con i vendor.

## Domande Comuni nei Colloqui DevOps

**Domanda: Ansible può sostituire Terraform?**

Non efficacemente. Ansible può creare risorse cloud, ma manca la gestione dello state. Eseguire lo stesso playbook due volte potrebbe creare risorse duplicate. Il file di state di Terraform traccia cosa esiste e calcola le modifiche minime. Utilizzare Ansible per ciò che fa meglio: il configuration management.

**Domanda: Come si gestiscono i secret in Terraform?**

Mai committare secret nel version control. Utilizzare variabili d'ambiente, integrazione con Vault o secret manager dei cloud provider. Marcare le variabili come sensitive per impedire che appaiano nei log:

```hcl
# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}
```

**Domanda: Cos'è l'idempotenza in Ansible?**

Un'operazione idempotente produce lo stesso risultato sia che venga eseguita una volta o più volte. Il modulo `apt` con `state: present` installa un pacchetto se mancante e non fa nulla se già installato. Scrivere playbook idempotenti previene modifiche indesiderate nelle esecuzioni successive.

**Domanda: Come si testa il codice Infrastructure?**

Terraform: `terraform validate` verifica la sintassi, `terraform plan` mostra le modifiche in anteprima, e strumenti come [Terratest](https://terratest.gruntwork.io/) eseguono test di integrazione. Ansible: `ansible-lint` rileva problemi, la modalità `--check` esegue dry run, e [Molecule](https://ansible.readthedocs.io/projects/molecule/) testa i role contro container.

Per una preparazione più approfondita sui colloqui Terraform, consultare [Terraform Interview Questions: Infrastructure as Code Complete Guide](/blog/devops/terraform-interview-questions-infrastructure-as-code). Esercitazioni pratiche con i moduli [Terraform Basics](/technologies/devops/interview-questions/terraform-basics) e [Ansible Configuration Management](/technologies/devops/interview-questions/ansible-configuration).

## Compatibilità delle Versioni ed Ecosistema

Versioni stabili attuali ad agosto 2026:

| Strumento | Versione | Data di Rilascio | Funzionalità Principale |
|-----------|----------|------------------|--------------------------|
| Ansible | 2.20.5 | Aprile 2026 | Gestione migliorata delle collection |
| Terraform | 1.15.8 | Luglio 2026 | Supporto Windows ARM64, funzione convert |
| OpenTofu | 1.11.6 | Aprile 2026 | Crittografia state, provider for_each |

L'architettura delle collection di Ansible separa le funzionalità core dai moduli specifici per provider. La collection `amazon.aws` riceve aggiornamenti indipendentemente dal core di Ansible. Questo è rilevante per il version pinning nelle pipeline CI/CD.

Il versioning dei provider di Terraform segue principi simili. I file di lock (`terraform.lock.hcl`) assicurano versioni dei provider coerenti tra i membri del team e i sistemi CI.

```hcl
# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}
```

## Scegliere tra i Due: Un Framework Decisionale

La domanda raramente è Ansible o Terraform. La domanda è quale strumento gestisce quale responsabilità.

| Caso d'Uso | Strumento Consigliato |
|------------|----------------------|
| Provisioning VM, database, reti | Terraform |
| Configurazione OS, installazione pacchetti | Ansible |
| Gestione risorse Kubernetes | Terraform o kubectl/Helm |
| Deploy codice applicativo | Ansible o CI/CD nativo |
| Creazione ruoli e policy IAM | Terraform |
| Gestione account utente sui server | Ansible |
| Setup infrastruttura di monitoring | Terraform (creare risorse) + Ansible (configurare agent) |

Per un quadro completo di come questi strumenti si inseriscono nei moderni workflow di deployment, consultare [CI/CD Pipeline Interview Questions](/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins).

## Cosa Dovrebbero Sapere i Senior Engineer su Ansible e Terraform

- Terraform gestisce lo state dell'infrastruttura in modo dichiarativo; Ansible configura i sistemi in modo procedurale. Utilizzarli insieme produce infrastruttura manutenibile.
- La sicurezza del file di state è importante. Memorizzare lo state di Terraform remotamente con crittografia e locking abilitati.
- OpenTofu fornisce un'alternativa con licenza MPL a Terraform con funzionalità aggiuntive. La migrazione è semplice per la maggior parte dei workflow.
- L'idempotenza non è automatica. Scrivere playbook che producono risultati coerenti nelle esecuzioni ripetute.
- L'inventory dinamico elimina la gestione manuale degli host. Interrogare direttamente i cloud provider per l'infrastruttura attuale.
- Il version pinning previene sorprese. Bloccare le versioni dei provider in Terraform; pinnare le versioni delle collection in Ansible.
- Testare il codice Infrastructure richiede approcci diversi: `terraform plan` per l'anteprima delle modifiche, modalità `--check` per i dry run di Ansible, framework di test di integrazione per entrambi.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/it/blog/devops/ansible-vs-terraform-2026-infrastructure-as-code-devops-interview