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.

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.
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.
# 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.
# 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: restartedElke 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 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.
# 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 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.
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.
# 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.
# 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.
Klaar om je DevOps gesprekken te halen?
Oefen met onze interactieve simulatoren, flashcards en technische tests.
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, 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:
# 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 draaien integratietests. Ansible: ansible-lint vangt problemen, --check modus voert dry runs uit, en Molecule test roles tegen containers.
Voor diepere Terraform sollicitatievoorbereiding, zie Terraform Interview Questions: Infrastructure as Code Complete Guide. Praktische oefeningen met Terraform Basics en Ansible Configuration Management 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.
# 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.
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 planvoor het bekijken van wijzigingen,--checkmodus voor Ansible dry runs, integratie test frameworks voor beide.
Begin met oefenen!
Test je kennis met onze gespreksimulatoren en technische tests.
Zie jij de bug in DevOps?
Een echt codefragment, een verborgen bug, één poging per dag. Zonder account uit te proberen.

Geschreven door
Anthony Fillion-MailletOprichter van SharpSkill
Al meer dan 10 jaar fullstack-ontwikkelaar. Hij leidt SharpSkill en staat in voor alles wat hier verschijnt.
Bijgewerkt op 22 augustus 2026
Tags
Delen
Gerelateerde artikelen

Terraform-sollicitatievragen: De complete gids voor Infrastructure as Code 2026
Uitgebreide gids over Terraform-sollicitatievragen met state management, moduleontwerp, CI/CD-pipelines en geavanceerde IaC-concepten voor 2026.

Kubernetes Sollicitatiegesprek: Pods, Services en Deployments Uitgelegd
De drie fundamentele Kubernetes-bouwstenen — Pods, Services en Deployments — met productie-YAML, netwerk-internals en veelgestelde interviewvragen.

Essentiële DevOps Interviewvragen: Complete Gids 2026
Bereid je voor op DevOps-interviews met onmisbare vragen over CI/CD, Kubernetes, Docker, Terraform en SRE-praktijken. Gedetailleerde antwoorden inbegrepen.