Terraform-Interviewfragen: Der vollständige Leitfaden für Infrastructure as Code 2026

Terraform-Interviewfragen prüfen die Fähigkeit eines Kandidaten, Cloud-Infrastruktur deklarativ zu verwalten, State sicher zu handhaben und wiederverwendbare Module zu entwerfen. Mit Terraform 1.14, das nun Variablen in Module Sources unterstützt, und der Erweiterung von HCP Terraform als verwaltete Ausführungsplattform erwarten Interviewer im Jahr 2026, dass Kandidaten sowohl grundlegende HCL-Kenntnisse als auch ein Verständnis der sich entwickelnden IaC-Landschaft mitbringen.

Grundlegende Terraform-Konzepte für jeden Kandidaten

Was ist Terraform und wie unterscheidet es sich von anderen IaC-Tools?

Terraform ist ein deklaratives Infrastructure-as-Code-Tool, das Cloud-Ressourcen über Konfigurationsdateien verwaltet, die in HCL (HashiCorp Configuration Language) geschrieben sind. Im Gegensatz zu imperativen Tools wie Ansible oder Shell-Skripten pflegt Terraform eine State-Datei, die die aktuelle Infrastruktur verfolgt und einen Diff (den "Plan") berechnet, bevor Änderungen angewendet werden.

Die wesentlichen Unterscheidungsmerkmale: Terraform ist Cloud-agnostisch (mit Unterstützung für AWS, Azure, GCP und Hunderte weiterer Provider), nutzt einen Plan-vor-Apply-Workflow, der Überraschungen verhindert, und verwaltet Ressourcenabhängigkeiten über einen internen gerichteten azyklischen Graphen (DAG).

Eine fundierte Antwort berücksichtigt auch die Veränderung im Ökosystem: Seit HashiCorp 2023 die BSL-Lizenz eingeführt hat, ist OpenTofu als Open-Source-Fork unter der Linux Foundation entstanden. Beide Tools teilen die gleiche HCL-Syntax, entwickeln sich aber in unterschiedliche Richtungen. Terraform 1.14 setzt auf Plattformintegration mit HCP, während OpenTofu 1.9 den Schwerpunkt auf State-Verschlüsselung und dynamische Backends legt.

Der Terraform-Workflow: init, plan, apply, destroy

Die vier Kernbefehle bilden den Lebenszyklus jeder Terraform-Operation:

# 1. Initialisieren - Provider und Module herunterladen
terraform init

# 2. Planen - zeigt Änderungen ohne Modifikation
terraform plan -out=tfplan

# 3. Anwenden - führt die geplanten Änderungen aus
terraform apply tfplan

# 4. Zerstören - baut alle verwalteten Ressourcen ab
terraform destroy

terraform init lädt Provider-Plugins herunter und initialisiert das Backend. terraform plan vergleicht den gewünschten Zustand (Konfigurationsdateien) mit dem tatsächlichen Zustand (State-Datei) und gibt einen Änderungssatz aus. terraform apply führt diesen Änderungssatz aus. Das Speichern des Plans in einer Datei mit -out stellt sicher, dass genau der überprüfte Plan angewendet wird, was in CI/CD-Pipelines unverzichtbar ist.

State-Management: Das häufigste Interviewthema

Was ist der Terraform-State und warum ist er wichtig?

Der Terraform-State ist eine JSON-Datei (terraform.tfstate), die Konfigurationsressourcen realen Infrastrukturobjekten zuordnet. Ohne State kann Terraform nicht feststellen, was existiert, was sich geändert hat oder was gelöscht werden muss.

Der State enthält Ressourcen-IDs, Attributwerte und Abhängigkeitsmetadaten. Geht der State verloren, verliert Terraform die Übersicht über alle verwalteten Ressourcen, was einen manuellen Import jedes einzelnen Objekts erfordert oder — schlimmer noch — verwaiste Cloud-Ressourcen hinterlässt, die weiterhin Kosten verursachen.

Wie sollten Teams den State in der Produktion verwalten?

Lokale State-Dateien sind für Teamumgebungen inakzeptabel. Die Standard-Produktionseinrichtung verwendet ein Remote-Backend mit 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
  }
}

Diese Konfiguration speichert den State in S3 mit serverseitiger Verschlüsselung und verwendet DynamoDB für das State-Locking. Das Lock verhindert, dass zwei Entwickler (oder zwei CI-Pipelines) gleichzeitig apply ausführen, was den State korrumpieren würde.

HCP Terraform (ehemals Terraform Cloud) bietet eine verwaltete Alternative, die State-Speicherung, Locking, Run-History und RBAC ohne zusätzliche Infrastruktur bereitstellt. Für Organisationen, die bereits in das HashiCorp-Ökosystem investiert haben, entfällt der Aufwand für die Wartung von S3-Buckets und DynamoDB-Tabellen.

Best Practices für die State-Datei

• Die terraform.tfstate niemals in die Versionskontrolle committen. Sie kann Secrets (Datenbankpasswörter, API-Keys) im Klartext enthalten.
• Verschlüsselung im Ruhezustand auf dem Backend aktivieren (S3 SSE, GCS-Verschlüsselung oder Azure Storage-Verschlüsselung).
• Separate State-Dateien pro Umgebung verwenden. Eine einzelne State-Datei für Dev, Staging und Produktion führt unweigerlich zu versehentlicher Zerstörung.
• State-Locking implementieren. Jedes Remote-Backend, das es unterstützt, sollte Locking aktiviert haben.
• terraform state list und terraform state show verwenden, um den State zu inspizieren, ohne ihn zu verändern.

Module: Wiederverwendbare Infrastrukturkomponenten

Wie funktionieren Terraform-Module?

Ein Modul ist ein Verzeichnis mit .tf-Dateien, das eine Reihe von Ressourcen kapselt. Jede Terraform-Konfiguration ist technisch gesehen ein Modul (das Root-Modul). Child-Module werden vom Root-Modul aufgerufen, um Wiederverwendung zu fördern und Standards durchzusetzen.

# main.tf - Aufruf eines Moduls
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 führte eine bedeutende Verbesserung ein: Variablen und Locals können jetzt in den Attributen source und version von Modulen verwendet werden. Dies war zuvor eine harte Einschränkung, die Workarounds wie Terragrunt für dynamisches Module-Sourcing erzwang.

Was zeichnet ein gut gestaltetes Modul aus?

Ein produktionsreifes Modul folgt diesen Prinzipien:

• Klare Inputs und Outputs: Jede Variable hat eine Beschreibung, Typeinschränkung und sinnvollen Standardwert, wo angemessen. Outputs stellen die Werte bereit, die nachgelagerte Module benötigen.
• Minimaler Scope: Ein Modul verwaltet eine logische Komponente (ein VPC, einen Datenbank-Cluster, einen Kubernetes-Namespace), nicht eine gesamte Umgebung.
• Keine hartcodierten Werte: Provider-Konfiguration, Region, Account-IDs und umgebungsspezifische Werte kommen aus Variablen, niemals aus Literalen innerhalb des Moduls.
• Versionierte Releases: Veröffentlichte Module verwenden semantische Versionierung. Das Pinning auf version = "5.16.0" verhindert unerwartete Breaking Changes.

Workspaces, Umgebungen und Projektstruktur

Wie sollten mehrere Umgebungen verwaltet werden?

Drei gängige Muster existieren, jeweils mit unterschiedlichen Kompromissen:

| Muster | Mechanismus | Geeignet für | Risiko | |--------|-------------|-------------|--------| | Workspaces | terraform workspace select prod | Einfache Projekte, gleiche Konfig pro Umgebung | Gemeinsames State-Backend, leicht die falsche Workspace zu verwenden | | Verzeichnis-pro-Umgebung | Separate dev/, staging/, prod/ Verzeichnisse | Vollständige Isolation zwischen Umgebungen | Code-Duplizierung über Verzeichnisse | | Terragrunt | DRY-Wrapper, der Backend-Konfigurationen generiert | Große Multi-Account-Setups | Zusätzliche Tool-Abhängigkeit |

Der Ansatz mit einem Verzeichnis pro Umgebung und gemeinsam genutzten Modulen ist der häufigste in der Produktion. Jedes Umgebungsverzeichnis enthält eine main.tf, die dieselben Module mit unterschiedlichen Variablenwerten aufruft, und jedes hat seine eigene isolierte State-Datei.

Was ist der Unterschied zwischen terraform workspace und Verzeichnisisolation?

Workspaces erstellen benannte State-Dateien innerhalb desselben Backends. Das Wechseln von Workspaces mit terraform workspace select staging ändert, welche State-Datei Terraform liest und schreibt, aber die Konfiguration bleibt identisch.

Die Einschränkung: Workspaces teilen sich die gleiche Backend-Konfiguration und Provider-Einrichtung. Verzeichnisisolation bietet stärkere Grenzen — jede Umgebung kann ein anderes AWS-Konto, ein anderes State-Backend oder sogar andere Provider-Versionen verwenden. Für regulierte Umgebungen, die eine strikte Blast-Radius-Kontrolle erfordern, ist die Verzeichnisisolation die sicherere Wahl.

Provider, Datenquellen und Ressourcen-Lebenszyklus

Was sind Provider und wie werden sie konfiguriert?

Provider sind Plugins, die HCL-Konfiguration in API-Aufrufe gegen bestimmte Plattformen übersetzen. Der AWS-Provider ruft die AWS-API auf, der Kubernetes-Provider kommuniziert mit dem Kubernetes-API-Server usw.

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

Die Versionsbeschränkung ~> 5.80 erlaubt Patch-Updates (5.80.x), blockiert aber Minor-Version-Sprünge und balanciert so Stabilität mit Sicherheitspatches. Der default_tags-Block wendet konsistentes Tagging auf jede vom Provider erstellte Ressource an — ein häufiger Interviewdiskussionspunkt für Governance und Kostenallokation.

Datenquellen vs. Ressourcen

Ressourcen (resource-Blöcke) erstellen, aktualisieren und löschen Infrastruktur. Datenquellen (data-Blöcke) lesen existierende Infrastruktur, ohne sie zu verwalten.

# Datenquelle - liest ein vorhandenes AMI, erstellt nichts
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-*"]
  }
}

# Ressource - erstellt eine EC2-Instanz unter Verwendung der Datenquelle
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

Datenquellen werden während des plan ausgewertet und sind daher nützlich, um gemeinsam genutzte Infrastruktur zu referenzieren (VPCs, die von einem anderen Team erstellt wurden), dynamische Werte nachzuschlagen (neueste AMI-IDs) oder externe Konfigurationen zu lesen (SSM-Parameter, Vault-Secrets).

Fortgeschrittene Themen: Import, Moved-Blöcke und Testing

Wie funktioniert terraform import und wann wird es benötigt?

terraform import verknüpft eine existierende Cloud-Ressource mit einem Terraform-Ressourcenblock. Das typische Szenario: Infrastruktur wurde manuell (ClickOps) oder durch ein anderes Tool erstellt, und das Team möchte sie nun mit Terraform verwalten.

Terraform 1.5+ führte import-Blöcke direkt in der Konfiguration ein und ersetzte den rein CLI-basierten 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"
}

Das Ausführen von terraform plan mit diesem Block generiert einen Plan, der den existierenden Bucket in den State übernimmt. Dieser deklarative Import-Ansatz ist in Pull Requests überprüfbar, wiederholbar und erfordert keinen direkten CLI-Zugriff auf den State.

Was sind moved-Blöcke?

Das Refactoring von Terraform-Code (Umbenennen von Ressourcen, Verschieben in Module) erforderte historisch terraform state mv-Befehle. Der moved-Block handhabt dies deklarativ:

# Ressource von "web" zu "app" umbenannt
moved {
  from = aws_instance.web
  to   = aws_instance.app
}

Terraform erkennt die Verschiebung während des Plans und aktualisiert den State automatisch, wodurch ein Destroy-and-Recreate-Zyklus vermieden wird. Dies ist bei der Umstrukturierung großer Konfigurationen in Module unverzichtbar.

Wie funktioniert Terraform-Testing?

Terraform 1.6+ enthält ein natives Testing-Framework mit .tftest.hcl-Dateien:

# 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 erweiterte dies um Mock-Blöcke mit Funktionsunterstützung, skip_cleanup zum Debuggen fehlgeschlagener Tests und Backend-Blöcke innerhalb von Run-Blöcken für isolierten Test-State. Natives Testing eliminiert den Bedarf an externen Tools wie Terratest für grundlegende Validierung.

Terraform in CI/CD-Pipelines

Wie sieht eine Produktions-Terraform-Pipeline aus?

Eine robuste CI/CD-Pipeline für Terraform erzwingt Sicherheit in jeder Phase:

1. Lint und Validierung: terraform fmt -check und terraform validate fangen Syntaxfehler ab.
2. Plan bei PR: Jeder Pull Request führt terraform plan aus und postet die Ausgabe als PR-Kommentar. Kein Apply ohne überprüften Plan.
3. Policy-Checks: Tools wie OPA (Open Policy Agent), Sentinel (HCP Terraform) oder Checkov validieren den Plan gegen organisatorische Richtlinien (keine öffentlichen S3-Buckets, obligatorische Verschlüsselung, erforderliche Tags).
4. Apply bei Merge: Nach PR-Genehmigung und bestandenen Policy-Checks wird terraform apply automatisch aus der gespeicherten Plan-Datei ausgeführt.
5. State-Backup: Nach dem Apply überprüft die Pipeline die State-Integrität, und die Versionierung des Backends erfasst die neue State-Version.

Die goldene Regel: Kein Mensch sollte jemals terraform apply gegen die Produktion von einem lokalen Rechner aus ausführen. Alle Produktions-Applies laufen über die Pipeline.

Fazit

Die wichtigsten Erkenntnisse für die Vorbereitung auf Terraform-Interviews:

• State-Management ist das mit Abstand wichtigste Thema. Remote-Backends, Locking, Verschlüsselung und Disaster-Recovery-Strategien sollten vor jedem Interview verstanden werden.
• Moduldesign trennt Junior- von Senior-Kandidaten. Die Fähigkeit, wiederverwendbare, versionierte Module mit klaren Schnittstellen und minimalem Scope zu bauen, sollte demonstriert werden.
• Den Plan/Apply-Workflow tiefgehend verstehen. Erklären, warum das Speichern von Plans in Dateien wichtig ist, wie der DAG die Ausführungsreihenfolge bestimmt und was -target bewirkt (und warum es sparsam eingesetzt werden sollte).
• Terraform 1.14 bringt Variablen in Module Sources, erweiterte Tests und engere HCP-Integration. Das Erwähnen aktueller Features zeigt aktives Engagement mit dem Ökosystem.
• Die Terraform-vs-OpenTofu-Landschaft ehrlich ansprechen. Das Verständnis des Lizenz-Splits, der Feature-Divergenz und der jeweiligen Einsatzszenarien demonstriert architektonische Reife jenseits von Syntaxkenntnissen.
• Grundlagen zu DevOps-Interviewfragen parallel zu Terraform-Spezifika durcharbeiten, da Interviewer oft IaC-Fragen mit breiteren Infrastrukturthemen verbinden.
• Kubernetes-Deployment-Konzepte wiederholen, da Terraform häufig die Cluster bereitstellt, auf denen Kubernetes-Workloads laufen.