Terraform-sollicitatievragen: De complete gids voor Infrastructure as Code 2026

Terraform-sollicitatievragen testen het vermogen van een kandidaat om cloudinfrastructuur declaratief te beheren, state veilig te hanteren en herbruikbare modules te ontwerpen. Met Terraform 1.14 dat nu variabelen in module sources ondersteunt en HCP Terraform dat zijn beheerde uitvoeringsplatform uitbreidt, verwachten interviewers in 2026 dat kandidaten zowel fundamentele HCL-kennis als bewustzijn van het veranderende IaC-landschap demonstreren.

Fundamentele Terraform-concepten die elke kandidaat moet kennen

Wat is Terraform en hoe verschilt het van andere IaC-tools?

Terraform is een declaratieve Infrastructure as Code-tool die cloudresources beheert via configuratiebestanden geschreven in HCL (HashiCorp Configuration Language). In tegenstelling tot imperatieve tools zoals Ansible of shellscripts onderhoudt Terraform een state-bestand dat de huidige infrastructuur bijhoudt en een diff (het "plan") berekent voordat wijzigingen worden toegepast.

De belangrijkste onderscheidende kenmerken: Terraform is cloud-agnostisch (met ondersteuning voor AWS, Azure, GCP en honderden andere providers), gebruikt een plan-before-apply-workflow die verrassingen voorkomt en beheert resource-afhankelijkheden via een interne directed acyclic graph (DAG).

Een sterk antwoord houdt ook rekening met de verschuiving in het ecosysteem: sinds HashiCorp in 2023 de BSL-licentie adopteerde, is OpenTofu ontstaan als open-source fork onder de Linux Foundation. Beide tools delen dezelfde HCL-syntax maar divergeren in functionaliteit. Terraform 1.14 richt zich op platformintegratie met HCP, terwijl OpenTofu 1.9 prioriteit geeft aan state-encryptie en dynamische backends.

De Terraform-workflow: init, plan, apply, destroy

De vier kerncommando's vormen de levenscyclus van elke Terraform-operatie:

# 1. Initialiseren - providers en modules downloaden
terraform init

# 2. Plannen - toont wat er verandert zonder iets te wijzigen
terraform plan -out=tfplan

# 3. Toepassen - voert de geplande wijzigingen uit
terraform apply tfplan

# 4. Vernietigen - breekt alle beheerde resources af
terraform destroy

terraform init downloadt provider-plugins en initialiseert de backend. terraform plan vergelijkt de gewenste state (configuratiebestanden) met de werkelijke state (state-bestand) en geeft een changeset uit. terraform apply voert die changeset uit. Het opslaan van het plan in een bestand met -out zorgt ervoor dat exact het beoordeelde plan wordt toegepast, wat essentieel is in CI/CD-pipelines.

State Management: Het meest voorkomende sollicitatieonderwerp

Wat is Terraform state en waarom is het belangrijk?

Terraform state is een JSON-bestand (terraform.tfstate) dat configuratieresources koppelt aan echte infrastructuurobjecten. Zonder state kan Terraform niet bepalen wat er bestaat, wat er is veranderd of wat moet worden verwijderd.

State bevat resource-ID's, attribuutwaarden en afhankelijkheidsmetadata. Het verlies van state betekent dat Terraform het overzicht verliest over alle beheerde resources, wat een handmatige import van elk object vereist of — erger nog — verweesde cloudresources achterlaat die kosten blijven genereren.

Hoe moeten teams state beheren in productie?

Lokale state-bestanden zijn onacceptabel voor teamomgevingen. De standaard productieconfiguratie gebruikt een remote backend met 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
  }
}

Deze configuratie slaat state op in S3 met server-side encryptie en gebruikt DynamoDB voor state locking. Het lock voorkomt dat twee ontwikkelaars (of twee CI-pipelines) tegelijkertijd apply uitvoeren, wat de state zou corrumperen.

HCP Terraform (voorheen Terraform Cloud) biedt een beheerd alternatief dat state-opslag, locking, uitvoeringsgeschiedenis en RBAC biedt zonder aanvullende infrastructuur. Voor organisaties die al geïnvesteerd hebben in het HashiCorp-ecosysteem elimineert het de overhead van het onderhouden van S3-buckets en DynamoDB-tabellen.

Best practices voor het state-bestand

• Commit terraform.tfstate nooit naar versiebeheer. Het kan secrets (databasewachtwoorden, API-keys) in plaintext bevatten.
• Schakel encryptie in rust in op de backend (S3 SSE, GCS-encryptie of Azure Storage-encryptie).
• Gebruik aparte state-bestanden per omgeving. Eén enkel state-bestand voor dev, staging en productie is een recept voor per ongeluk vernietiging.
• Implementeer state locking. Elke remote backend die het ondersteunt moet locking ingeschakeld hebben.
• Gebruik terraform state list en terraform state show om state te inspecteren zonder het te wijzigen.

Modules: Herbruikbare infrastructuurcomponenten

Hoe werken Terraform-modules?

Een module is een directory met .tf-bestanden die een set resources encapsuleren. Elke Terraform-configuratie is technisch gezien een module (de root module). Child modules worden aangeroepen vanuit de root module om hergebruik te bevorderen en standaarden af te dwingen.

# main.tf - aanroepen van een 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
}

Terraform 1.14 introduceerde een significante verbetering: variabelen en locals kunnen nu worden gebruikt in de source en version attributen van modules. Dit was voorheen een harde beperking die workarounds zoals Terragrunt afdwong voor dynamisch module sourcing.

Wat maakt een goed ontworpen module?

Een productie-waardige module volgt deze principes:

• Duidelijke inputs en outputs: Elke variabele heeft een beschrijving, typebeperking en een verstandige standaardwaarde waar van toepassing. Outputs stellen de waarden beschikbaar die downstream modules nodig hebben.
• Minimale scope: Een module beheert één logische component (een VPC, een database-cluster, een Kubernetes namespace), niet een hele omgeving.
• Geen hardcoded waarden: Provider-configuratie, regio, account-ID's en omgevingsspecifieke waarden komen uit variabelen, nooit uit literals binnen de module.
• Geversioneerde releases: Gepubliceerde modules gebruiken semantische versioning. Het pinnen op version = "5.16.0" voorkomt onverwachte breaking changes.

Workspaces, omgevingen en projectstructuur

Hoe moeten meerdere omgevingen worden beheerd?

Er bestaan drie veelvoorkomende patronen, elk met verschillende afwegingen:

| Patroon | Mechanisme | Geschikt voor | Risico | |---------|-----------|--------------|--------| | Workspaces | terraform workspace select prod | Eenvoudige projecten, dezelfde configuratie per omgeving | Gedeelde state-backend, makkelijk de verkeerde workspace te gebruiken | | Directory per omgeving | Aparte dev/, staging/, prod/ directories | Volledige isolatie tussen omgevingen | Code-duplicatie over directories | | Terragrunt | DRY wrapper die backend-configuraties genereert | Grote multi-account setups | Extra tooling-afhankelijkheid |

De directory-per-omgeving-aanpak met gedeelde modules is het meest gangbaar in productie. Elke omgevingsdirectory bevat een main.tf die dezelfde modules aanroept met verschillende variabelewaarden, en elk heeft een eigen geïsoleerd state-bestand.

Wat is het verschil tussen terraform workspace en directory-isolatie?

Workspaces creëren benoemde state-bestanden binnen dezelfde backend. Schakelen tussen workspaces met terraform workspace select staging verandert welk state-bestand Terraform leest en schrijft, maar de configuratie blijft identiek.

De beperking: workspaces delen dezelfde backend-configuratie en provider-setup. Directory-isolatie biedt sterkere grenzen — elke omgeving kan een ander AWS-account, een andere state-backend of zelfs andere provider-versies gebruiken. Voor gereguleerde omgevingen die strikte blast radius-controle vereisen, is directory-isolatie de veiligere keuze.

Providers, data sources en resource-levenscyclus

Wat zijn providers en hoe worden ze geconfigureerd?

Providers zijn plugins die HCL-configuratie vertalen naar API-calls tegen specifieke platformen. De AWS-provider roept de AWS API aan, de Kubernetes-provider communiceert met de Kubernetes API-server, enzovoort.

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

De versiebeperking ~> 5.80 staat patch-updates toe (5.80.x) maar blokkeert minor version bumps, waarmee stabiliteit en beveiligingspatches in balans worden gebracht. Het default_tags-blok past consistente tagging toe op elke resource die de provider aanmaakt — een veelbesproken punt in sollicitatiegesprekken voor governance en kostentoewijzing.

Data sources versus resources

Resources (resource-blokken) creëren, updaten en verwijderen infrastructuur. Data sources (data-blokken) lezen bestaande infrastructuur zonder deze te beheren.

# Data source - leest een bestaand AMI, creëert niets
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 - creëert een EC2-instantie met behulp van de data source
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

Data sources worden geëvalueerd tijdens het plan, waardoor ze nuttig zijn voor het refereren naar gedeelde infrastructuur (VPC's aangemaakt door een ander team), het opzoeken van dynamische waarden (nieuwste AMI-ID's) of het lezen van externe configuratie (SSM-parameters, Vault-secrets).

Geavanceerde onderwerpen: Import, Moved-blokken en Testing

Hoe werkt terraform import en wanneer is het nodig?

terraform import koppelt een bestaande cloudresource aan een Terraform resource-blok. Het typische scenario: infrastructuur is handmatig aangemaakt (ClickOps) of door een andere tool, en het team wil deze nu met Terraform beheren.

Terraform 1.5+ introduceerde import-blokken direct in de configuratie, ter vervanging van de CLI-only workflow:

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

Het uitvoeren van terraform plan met dit blok genereert een plan dat de bestaande bucket in de state opneemt. Deze declaratieve import-aanpak is reviewbaar in pull requests, herhaalbaar en vereist geen directe CLI-toegang tot de state.

Wat zijn moved-blokken?

Het refactoren van Terraform-code (hernoemen van resources, verplaatsen naar modules) vereiste historisch terraform state mv-commando's. Het moved-blok handelt dit declaratief af:

# Resource hernoemd van "web" naar "app"
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Terraform herkent de verplaatsing tijdens het plan en werkt de state automatisch bij, waardoor een destroy-and-recreate cyclus wordt vermeden. Dit is van onschatbare waarde bij het herstructureren van grote configuraties naar modules.

Hoe werkt Terraform-testing?

Terraform 1.6+ bevat een native testframework dat .tftest.hcl-bestanden gebruikt:

# 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 breidde dit uit met mock-blokken die functies accepteren, skip_cleanup voor het debuggen van gefaalde tests en backend-blokken binnen run-blokken voor geïsoleerde test-state. Native testing elimineert de behoefte aan externe tools zoals Terratest voor basisvalidatie.

Terraform in CI/CD-pipelines

Hoe ziet een productie Terraform-pipeline eruit?

Een robuuste CI/CD-pipeline voor Terraform handhaaft veiligheid in elke fase:

1. Lint en validatie: terraform fmt -check en terraform validate vangen syntaxproblemen op.
2. Plan bij PR: Elke pull request voert terraform plan uit en plaatst de output als PR-commentaar. Geen apply zonder een beoordeeld plan.
3. Policy-checks: Tools zoals OPA (Open Policy Agent), Sentinel (HCP Terraform) of Checkov valideren het plan tegen organisatiebeleid (geen publieke S3-buckets, verplichte encryptie, vereiste tags).
4. Apply bij merge: Na PR-goedkeuring en geslaagde policy-checks wordt terraform apply automatisch uitgevoerd vanuit het opgeslagen planbestand.
5. State-backup: Na de apply verifieert de pipeline de state-integriteit en legt de versioning van de backend de nieuwe state-versie vast.

De gouden regel: geen mens zou ooit terraform apply tegen productie moeten uitvoeren vanaf een lokale machine. Alle productie-applies gaan via de pipeline.

Conclusie

De belangrijkste inzichten voor de voorbereiding op Terraform-sollicitatiegesprekken:

• State management is veruit het belangrijkste onderwerp. Remote backends, locking, encryptie en disaster recovery-strategieën moeten begrepen worden voordat een sollicitatiegesprek wordt ingegaan.
• Moduleontwerp scheidt junior van senior kandidaten. Het vermogen om herbruikbare, geversioneerde modules te bouwen met duidelijke interfaces en minimale scope moet gedemonstreerd worden.
• De plan/apply-workflow diepgaand begrijpen. Uitleggen waarom het opslaan van plans in bestanden belangrijk is, hoe de DAG de uitvoeringsvolgorde bepaalt en wat -target doet (en waarom het spaarzaam gebruikt moet worden).
• Terraform 1.14 brengt variabelen in module sources, uitgebreide testing en nauwere HCP-integratie. Het noemen van actuele features toont actieve betrokkenheid bij het ecosysteem.
• Het Terraform-versus-OpenTofu-landschap eerlijk bespreken. Het begrijpen van de licentiesplitsing, feature-divergentie en wanneer elk tool past, demonstreert architecturale volwassenheid voorbij syntaxkennis.
• De basis van DevOps-sollicitatievragen bestuderen naast Terraform-specifieke kennis, aangezien interviewers vaak IaC-vragen combineren met bredere infrastructuuronderwerpen.
• Kubernetes-deploymentconcepten herhalen, aangezien Terraform vaak de clusters provisioneert waarop Kubernetes-workloads draaien.