Terraform Interview-Fragen

Lernziele

Nach dieser Lektion kannst du Terraform in 60–90 Sekunden überzeugend erklären und typische Interview-Fragen aus dem gesamten Lernpfad strukturiert beantworten. Du kennst Antwortmuster für Grundlagen, State, Module, CI/CD und Troubleshooting — und kannst in Deep-Dives technische Tiefe zeigen, ohne in Schlagwort-Listen zu verfallen.

Das Problem: viel gelernt, kein roter Faden

Du hast vierzehn Lektionen durchgearbeitet — IaC, HCL, Workflow, Provider, State, Remote Backend, Module, Workspaces, Kubernetes, CI/CD, Testing, Policy, Import, Best Practices. In einem Interview kommt aber selten „Erkläre Lektion 7”. Es kommt: „Wie nutzt ihr Terraform?” — und du hast drei Minuten, um Problem, Architektur und Grenzen in eine kohärente Erzählung zu packen.

Diese Lektion ist kein neues Tool — sie ist die Synthese des Lernpfads mit konkreten Antworten, die du üben solltest.

Die 60-Sekunden-Erklärung

Struktur, die funktioniert:

„Wir beschreiben Infrastruktur deklarativ in HCL — der Zielzustand steht im Code, nicht die Klickfolge. Terraform berechnet per Plan den Diff zwischen Code, State und Cloud, und Apply setzt ihn um. State mappt Code-Blöcke auf echte IDs — deshalb Remote Backend mit Locking im Team. Wir splitten in Stacks — Netzwerk, Cluster, Apps — teilen Module über die Plattform, und Plan läuft in CI, Apply nur aus der Pipeline mit approved Plan-Artefakt. Terraform ist imperativ ausgeführt — kein dauerhaftes Reconcile — deshalb kombinieren wir für Apps oft GitOps.”

Das trifft Lektionen 1–10 in einem Absatz. Passe Cloud-Namen und Tools an deine Erfahrung an — die Struktur bleibt.

Top-Fragen und Kernantworten

Grundlagen

„Deklarativ vs. imperativ?” Deklarativ: Zielzustand beschreiben („eine Instanz t3.micro”). Imperativ: Schritte (run-instances, terminate). Terraform ist deklarativ in der Config, wird aber imperativ ausgeführt — es läuft nur bei init/plan/apply, nicht kontinuierlich.

„Warum braucht Terraform State?” Um Code-Adressen (aws_s3_bucket.x) an Cloud-IDs zu binden und Diffs zu berechnen. Ohne State kein Plan. State ist sensitiv — Remote, verschlüsselt, nicht in Git.

„Was passiert bei terraform plan?” Config + State laden, Cloud-APIs refreshen (Ist-Zustand), Execution Plan berechnen: create/update/destroy. Read-only — ändert nichts.

State und Skalierung

„Wie arbeiten Teams mit State?” Remote Backend (S3+DynamoDB, GCS, TFC), Locking gegen parallele Applies, ein State pro Stack. Outputs + terraform_remote_state für Stack-übergreifende Werte.

„Workspaces oder separate Verzeichnisse?” Workspaces: mehrere States, gleicher Code — gut für Ephemeral/Previews. dev/staging/prod mit unterschiedlichen Policies: separate Verzeichnisse/Stacks mit eigenen Pipelines — weniger Verwechslungsgefahr.

„Größter State-Fehler den du gesehen hast?” (Eigene Geschichte oder Hypothetisch:) Monolith-State, lokaler tfstate auf Laptop, paralleler Apply ohne Lock, State in Git — eines konkret mit Impact und Fix erzählen.

Module und Provider

„Wofür Module?” Wiederverwendbare Infra-Patterns mit klarer API (Variables/Outputs). Plattform-Team pflegt VPC/EKS-Module; Teams konsumieren mit versioniertem Source.

„Kubernetes per Terraform — sinnvoll?” Für Bootstrap und Shared Services (Ingress, Monitoring, CSI). Apps oft GitOps — Terraform reconciled nicht dauerhaft; kubectl edit erzeugt Drift bis zum nächsten Plan.

CI/CD, Testing, Policy

„Terraform in CI/CD?” Plan bei PR, gespeichertes Plan-Artefakt, Apply auf main mit Environment-Gate. OIDC statt Long-Lived Keys. fmt, validate, lint, optional conftest auf Plan-JSON.

„Wie testest du IaC?” Pyramide: fmt/validate (immer), tflint/checkov (statisch), terraform test (Plan-Assertions), Terratest (Integration, teuer — nightly).

„Policy as Code?” Regeln gegen Plan-JSON — Sentinel in TFC, Conftest/OPA in CI. Blockiert öffentliche SGs, unverschlüsselte DBs — automatisch, nicht per Review-Hoffnung.

Migration und Grenzen

„Bestehende Infra importieren?” HCL schreiben, import (CLI oder import-Block), plan iterieren bis No changes. Nie Stateful Resources löschen und neu anlegen ohne Plan.

„Terraform vs. Crossplane/Pulumi?” Terraform: HCL, riesiges Ökosystem, imperativ ausgeführt. Pulumi: echte Sprachen. Crossplane: K8s-native, kontinuierliches Reconcile. Kriterien: Team-Skills, Multi-Cloud, Reconciliation-Bedarf.

Troubleshooting-Szenarien — zeig Prozess, nicht Magie

„Plan will Resource zerstören und neu anlegen — warum?” Lifecycle-Regel create_before_destroy vs. Force-Replace; geändertes name-Attribut das nicht in-place geht; Provider-Upgrade mit Resource-Split. Vorgehen: terraform plan Diff lesen, state show, Changelog — nicht blind applyen.

„Error acquiring state lock” Anderer Apply läuft oder abgebrochen. Prüfen wer lockt; wenn niemand: force-unlock mit Vorsicht. Danach State-Integrität prüfen.

„Drift — Console-Änderung” Nächster Plan zeigt Diff. Entweder ins HCL übernehmen oder manuelle Änderung revertieren. Dauerhaft: Drift-Detection + kein ClickOps.

„Apply schlägt mitten fehl” Partial Apply — manche Ressourcen existieren, State evtl. inkonsistent. Nicht sofort erneut applyen: Fehlermeldung, betroffene Resource in State und Cloud prüfen, ggf. state rm + Import oder gezielter Fix. State-Backup vorher.

Schwache vs. starke Antworten

Schwach	Stark
„Terraform ist IaC”	Problem (ClickOps) → Lösung (deklarativ + State) → Grenze (kein Reconcile)
Begriffe aufzählen	Ein konkretes Szenario durchgehend erklären
„Wir nutzen Best Practices”	Eine Practice benennen und warum (Remote State wegen Locking)
Keine Trade-offs	„Workspaces wäre einfacher, aber separate Stacks wegen IAM-Trennung”

Senior-Level heißt: Zusammenhänge sehen — State erklärt, warum CI Plan-Artefakte braucht; Module erklärt, warum Import schwieriger ist als Greenfield.

Praxis: Mock-Interview in 30 Minuten

1. Elevator Pitch (2 Min): Terraform ohne Folien erklären — aufnehmen, auf Füllwörter prüfen.
2. Deep Dive (10 Min): „Wie trennt ihr Umgebungen?” — Workspaces vs. Verzeichnisse mit Trade-off.
3. Troubleshooting (10 Min): „Plan will Prod-DB ersetzen” — Prozess beschreiben, nicht raten.
4. Whiteboard (8 Min): Drei Stacks zeichnen — network → eks → apps, State-Pfeile, remote_state.

Wiederhole mit Variationen, bis Antworten flüssig sind — nicht auswendig, aber strukturiert.

Typische Stolperfallen

Nur Happy Path üben: Interviewende fragen „Was wenn …?” — Lock, Partial Apply, Import-Mismatch vorbereiten.

Zu viel Tool-Religion: „Terraform ist immer besser” schwächt dich. Kriterien und Hybrid-Realität (TF + GitOps) sind überzeugender.

Erfundene War Stories: Ehrlichkeit schlägt Fiktion. „Im Lab habe ich …” ist legitim.

Alle 14 Lektionen aufzählen: Antworten sollen Probleme lösen, nicht den Curriculum-Index recitieren.

Interview-Vorbereitung

Meta-Frage: „Was erwartest du in dieser Rolle von Terraform?”

Antwortstrategie: Nachfragen, welche Cloud, Teamgröße, Greenfield vs. Brownfield — dann deine Erfahrung gezielt einordnen. Generic Answers wirken generisch.

Fragen, die du stellen solltest:

• Wie ist State organisiert — ein Backend, viele Stacks?
• Apply lokal oder nur CI?
• GitOps für Apps oder alles in Terraform?
• Brownfield-Anteil / Import-Backlog?

Das zeigt Platform-Denken — du evaluierst die Reife der Organisation.

Zusammenfassung — Abschluss des Lernpfads

Du hast den Terraform-Lernpfad durchlaufen: von IaC-Grundlagen und HCL über Workflow, Provider und State zu Remote Backends, Modulen und Umgebungstrennung. Kubernetes-Integration, CI/CD, Testing, Policy as Code, Import und Best Practices bilden den produktionsreifen Rahmen.

Terraform ist kein Selbstzweck — es ist das Werkzeug, mit dem Platform Teams reproduzierbare, reviewbare Infrastruktur liefern. State und Plan sind die Kernmechanismen; Disziplin in CI, Secrets und Stack-Grenzen entscheidet, ob es in Produktion trägt. Die Grenze — keine kontinuierliche Reconciliation — kennst du und kannst GitOps, Crossplane oder manuelle Prozesse als Ergänzung einordnen.

Wenn du Problem → Mechanismus → Grenze in deinen Antworten durchhältst und zwei Troubleshooting-Szenarien sicher durchspielst, bist du für typische Platform-Engineering-Interviews rund um Terraform gerüstet. Der nächste Schritt ist Übung — Mock-Interviews, ein Lab-Stack mit Remote State und CI, oder ein Brownfield-Import in einer Test-Umgebung. Viel Erfolg.