# Ansible vs Terraform 2026: Infrastructure as Code en DevOps Sollicitatievragen

> Uitgebreide vergelijking van Ansible en Terraform voor DevOps sollicitatiegesprekken. State management, declaratieve vs procedurele benaderingen en best practices voor 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 is een van de meest voorkomende vergelijkingsvragen in DevOps sollicitatiegesprekken, maar de vraagstelling zelf onthult een misverstand: deze tools lossen verschillende problemen op. Ansible 2.20 verzorgt configuration management en application deployment, terwijl Terraform 1.15 infrastructuurresources provisioneert. Begrijpen wanneer elke tool uitblinkt, waar ze overlappen en hoe ze elkaar aanvullen, onderscheidt Senior DevOps Engineers van beginners.

> **Het Kernonderscheid**
>
> Terraform beheert infrastructure state declaratief (VM's, netwerken, databases). Ansible configureert procedureel wat er op die infrastructuur draait (packages, services, bestanden). De meeste productieomgevingen gebruiken beide.

## Declaratief vs Procedureel: Het Fundamentele Verschil

Terraform gebruikt een declaratieve benadering. Een configuratiebestand beschrijft de gewenste eindtoestand, en Terraform berekent de noodzakelijke wijzigingen om die te bereiken. Dit werkt goed voor infrastructuur die als eenheid moet worden gecreëerd, gewijzigd of vernietigd.

```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"]
  }
}
```

Het uitvoeren van `terraform apply` creëert beide resources als ze niet bestaan, of werkt ze bij om overeen te komen met de configuratie. Het opnieuw uitvoeren zonder wijzigingen produceert geen operaties: Terraform vergelijkt de configuratie met het state bestand en vindt niets te doen.

Ansible gebruikt een procedurele benadering met tasks die in volgorde worden uitgevoerd. Hoewel Ansible modules vaak idempotent zijn (twee keer uitvoeren produceert hetzelfde resultaat), beschrijft het playbook zelf een reeks acties in plaats van een eindtoestand.

```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
```

Elke task wordt sequentieel uitgevoerd. Het notify/handler patroon biedt enig declaratief gedrag: de handler draait slechts één keer aan het einde, ongeacht hoeveel tasks hem triggeren.

## State Management: Een Kritisch Sollicitatieonderwerp

Terraform onderhoudt een [state bestand](https://developer.hashicorp.com/terraform/language/state) dat configuratie mapt naar echte resources. Deze state houdt resource ID's, afhankelijkheden en metadata bij. Zonder dit kan Terraform niet bepalen wat bestaat of wat moet worden gewijzigd.

| Aspect | Terraform | Ansible |
|--------|-----------|----------|
| State opslag | Vereist (lokaal bestand of remote backend) | Geen standaard |
| Drift detectie | Ingebouwd via `terraform plan` | Vereist expliciete controles |
| Resource tracking | Automatisch via state | Inventory-gebaseerd |
| Rollback | Vernietigen en opnieuw creëren vanuit state | Geen native rollback |

Ansible heeft geen equivalent state bestand. Het verbindt met doelsystemen en voert tasks uit, vertrouwend op de huidige systeemtoestand en module idempotentie. Dit maakt Ansible eenvoudiger om mee te beginnen maar moeilijker om wijzigingen over tijd te volgen.

Een veelgestelde sollicitatievraag gaat over state bestand beveiliging. Terraform state kan gevoelige data bevatten: databasewachtwoorden, API keys, resource identifiers. Productie deployments slaan state op in remote storage (S3, Azure Blob, Terraform Cloud) met encryptie en toegangscontroles.

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

De DynamoDB tabel voorziet in locking, waardoor wordt voorkomen dat twee engineers tegelijkertijd de state wijzigen.

## Wanneer Welke Tool Gebruiken

Terraform blinkt uit in het provisioneren van cloud infrastructuur: virtuele machines, managed databases, load balancers, IAM rollen, VPC's. Het handelt automatisch afhankelijkheden tussen resources af en ondersteunt alle grote cloud providers via een consistente HCL syntax.

Ansible blinkt uit in het configureren van bestaande systemen: installeren van packages, beheren van gebruikers, deployen van applicatiecode, orchestreren van multi-stap deployments. Het verbindt via SSH (of WinRM voor Windows) zonder agents op de doelsystemen te vereisen.

De overlap zone veroorzaakt verwarring. Beide kunnen software op een VM installeren. Terraform kan [provisioners](https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax) gebruiken om scripts uit te voeren na resource creatie. Ansible kan cloud resources creëren via modules zoals `amazon.aws.ec2_instance`. Maar het gebruik van elke tool buiten zijn sterkte leidt tot onderhoudsproblemen.

> **Vermijd Dit Anti-Pattern**
>
> Extensief gebruik van Terraform provisioners voor configuration management creëert fragiele infrastructuur. Provisioners draaien alleen bij creatie, niet bij volgende applies. Gebruik Terraform voor infrastructuur, draag dan over aan Ansible voor configuratie.

## De Gecombineerde Workflow in Productie

De meeste organisaties gebruiken beide tools samen. Terraform provisioneert de infrastructuur en output verbindingsdetails. Ansible consumeert deze outputs om de systemen te configureren.

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

Een CI/CD pipeline draait eerst Terraform, vangt outputs op, genereert dynamisch een Ansible inventory, en draait dan playbooks tegen de nieuwe infrastructuur.

```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"
```

Deze dynamische inventory bevraagt AWS direct, groepeert instances op hun tags. Geen handmatig IP beheer vereist.

## OpenTofu: De Fork Die Het Landschap Veranderde

HashiCorp heeft Terraform in augustus 2023 onder de Business Source License (BSL) geplaatst. De community reageerde door Terraform 1.5 te forken naar [OpenTofu](https://opentofu.org/), nu gehost onder de Linux Foundation.

Per augustus 2026 blijft OpenTofu 1.11.6 een drop-in vervanging voor de meeste Terraform workflows. Dezelfde HCL syntax, hetzelfde provider ecosysteem, hetzelfde state formaat. OpenTofu heeft features toegevoegd die niet aanwezig zijn in Terraform's open-source binary: state encryptie, provider `for_each`, en early variable evaluation.

Voor sollicitatievoorbereiding is het belangrijk het licentieonderscheid te begrijpen. BSL staat intern gebruik toe maar beperkt het bouwen van concurrerende producten. Organisaties bezorgd over vendor lock-in of met specifieke compliance vereisten kunnen de voorkeur geven aan OpenTofu's MPL 2.0 licentie. IBM's overname van HashiCorp in december 2024 voegde nog een variabele toe aan discussies over leveranciersrelaties.

## Veelgestelde DevOps Sollicitatievragen

**Vraag: Kan Ansible Terraform vervangen?**

Niet effectief. Ansible kan cloud resources creëren, maar mist state management. Het twee keer draaien van hetzelfde playbook kan dubbele resources creëren. Terraform's state bestand houdt bij wat bestaat en berekent minimale wijzigingen. Gebruik Ansible voor waar het het beste in is: configuration management.

**Vraag: Hoe worden secrets afgehandeld in Terraform?**

Commit nooit secrets naar version control. Gebruik omgevingsvariabelen, Vault integratie, of cloud provider secret managers. Markeer variabelen als sensitive om te voorkomen dat ze in logs verschijnen:

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

**Vraag: Wat is Ansible idempotentie?**

Een idempotente operatie produceert hetzelfde resultaat of deze nu één keer of meerdere keren wordt uitgevoerd. De `apt` module met `state: present` installeert een package als het ontbreekt en doet niets als het al geïnstalleerd is. Het schrijven van idempotente playbooks voorkomt onbedoelde wijzigingen bij volgende runs.

**Vraag: Hoe wordt Infrastructure code getest?**

Terraform: `terraform validate` controleert syntax, `terraform plan` toont wijzigingen in preview, en tools zoals [Terratest](https://terratest.gruntwork.io/) draaien integratietests. Ansible: `ansible-lint` vangt problemen, `--check` modus voert dry runs uit, en [Molecule](https://ansible.readthedocs.io/projects/molecule/) test roles tegen containers.

Voor diepere Terraform sollicitatievoorbereiding, zie [Terraform Interview Questions: Infrastructure as Code Complete Guide](/blog/devops/terraform-interview-questions-infrastructure-as-code). Praktische oefeningen met [Terraform Basics](/technologies/devops/interview-questions/terraform-basics) en [Ansible Configuration Management](/technologies/devops/interview-questions/ansible-configuration) modules.

## Versie Compatibiliteit en Ecosysteem

Huidige stabiele versies per augustus 2026:

| Tool | Versie | Releasedatum | Hoofdfeature |
|------|--------|--------------|---------------|
| Ansible | 2.20.5 | April 2026 | Verbeterd collection management |
| Terraform | 1.15.8 | Juli 2026 | Windows ARM64 support, convert function |
| OpenTofu | 1.11.6 | April 2026 | State encryptie, provider for_each |

Ansible's collection architectuur scheidt kernfunctionaliteit van provider-specifieke modules. De `amazon.aws` collection ontvangt updates onafhankelijk van Ansible core. Dit is relevant voor version pinning in CI/CD pipelines.

Terraform's provider versioning volgt vergelijkbare principes. Lock bestanden (`terraform.lock.hcl`) zorgen voor consistente provider versies tussen teamleden en CI systemen.

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

## Kiezen Tussen Beide: Een Beslissingsframework

De vraag is zelden Ansible of Terraform. De vraag is welke tool welke verantwoordelijkheid draagt.

| Use Case | Aanbevolen Tool |
|----------|----------------|
| Provisioneren VM's, databases, netwerken | Terraform |
| OS configureren, packages installeren | Ansible |
| Kubernetes resources beheren | Terraform of kubectl/Helm |
| Applicatiecode deployen | Ansible of CI/CD native |
| IAM rollen en policies creëren | Terraform |
| Gebruikersaccounts op servers beheren | Ansible |
| Monitoring infrastructuur opzetten | Terraform (resources creëren) + Ansible (agents configureren) |

Voor een compleet beeld van hoe deze tools passen in moderne deployment workflows, zie [CI/CD Pipeline Interview Questions](/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins).

## Wat Senior Engineers Moeten Weten Over Ansible en Terraform

- Terraform beheert infrastructure state declaratief; Ansible configureert systemen procedureel. Beide samen gebruiken produceert onderhoudbare infrastructuur.
- State bestand beveiliging is belangrijk. Sla Terraform state remote op met encryptie en locking ingeschakeld.
- OpenTofu biedt een MPL-gelicenseerd alternatief voor Terraform met extra features. Migratie is eenvoudig voor de meeste workflows.
- Idempotentie is niet automatisch. Schrijf playbooks die consistente resultaten produceren bij herhaalde runs.
- Dynamische inventory elimineert handmatig host beheer. Bevraag cloud providers direct voor huidige infrastructuur.
- Version pinning voorkomt verrassingen. Lock provider versies in Terraform; pin collection versies in Ansible.
- Het testen van Infrastructure code vereist verschillende benaderingen: `terraform plan` voor het bekijken van wijzigingen, `--check` modus voor Ansible dry runs, integratie test frameworks voor beide.

---

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