Terraform-Interviews drehen sich um den State, denn die meisten echten Probleme entstehen daraus: wer ihn hält, wer ihn gleichzeitig ändern kann und was passiert, wenn die Realität davon abweicht. Danach kommen Module, Umgebungen, sichere Änderungen und die Frage, wie du Terraform im Team betreibst.
Unten findest du 25 Fragen mit Antworten. HashiCorp hat 2023 die Lizenz von Terraform geändert, und es gibt den Community-Fork OpenTofu – erwähne also, welche Variante das Team nutzt, falls das zur Sprache kommt. Die Kernkonzepte und Befehle sind bei beiden gleich.
Grundlagen
1. Was ist Terraform, und was bedeutet Infrastructure as Code?
Terraform ist ein Tool, mit dem du Infrastruktur in Konfigurationsdateien definierst und über Provider-APIs ausrollst. Infrastructure as Code heißt, dass das Setup schriftlich festgehalten, versioniert, reviewt und wiederholbar ist – statt im Konsolen-Interface zusammengeklickt zu werden.
2. Was ist der Unterschied zwischen deklarativ und imperativ?
Terraform ist deklarativ: Du beschreibst den gewünschten Endzustand, und Terraform ermittelt die Schritte dorthin. Bei einem imperativen Skript schreibst du die Schritte selbst, und ein zweiter Durchlauf kann Dinge kaputt machen.
3. Was sind die wichtigsten Terraform-Befehle?
| Befehl | Was er macht |
|---|---|
| terraform init | Lädt Provider und Module herunter, richtet das Backend ein |
| terraform validate | Prüft, ob die Konfiguration gültig ist |
| terraform fmt | Formatiert die Dateien |
| terraform plan | Zeigt, was sich ändern wird |
| terraform apply | Führt die Änderungen aus |
| terraform destroy | Entfernt die verwalteten Ressourcen |
| terraform import | Bringt eine bestehende Ressource unter Verwaltung |
| terraform state | Inspiziert und bearbeitet den State |
4. Was sind Provider, Ressourcen und Data Sources?
Ein Provider ist ein Plugin, das mit einer API wie AWS, Azure oder Kubernetes spricht. Eine Ressource ist etwas, das Terraform erstellt und verwaltet. Eine Data Source liest Informationen über etwas, das bereits existiert, etwa ein vorhandenes VPC oder das neueste AMI.
5. Was sind Variablen, Outputs und Locals?
Input-Variablen parametrisieren eine Konfiguration. Outputs geben Werte nach außen, zur Nutzung auf der Kommandozeile oder durch andere Module. Locals sind benannte Ausdrücke innerhalb eines Moduls, mit denen du Wiederholungen vermeidest.
State
6. Was ist die Terraform-State-Datei, und warum ist sie so wichtig?
Der State verknüpft deine Konfiguration mit den echten Ressourcen und speichert deren Attribute. Terraform vergleicht Konfiguration, State und die reale Welt, um Änderungen zu planen. Verlierst du den State, versucht Terraform möglicherweise, Dinge neu zu erstellen, die bereits existieren. Außerdem kann er Secrets enthalten – behandle ihn also als sensibel.
7. Wo sollte der State gespeichert werden?
In einem Remote-Backend, nicht auf dem Laptop einer einzelnen Person – zum Beispiel S3 mit einer DynamoDB-Tabelle oder dem neueren nativen S3-Lock, Azure Storage, Google Cloud Storage oder Terraform Cloud. Aktiviere Versionierung auf dem Bucket, Verschlüsselung und eingeschränkten Zugriff.
8. Was ist State-Locking?
Es verhindert, dass zwei Personen oder Pipelines gleichzeitig applien und den State beschädigen. Die meisten Remote-Backends unterstützen es. Wenn ein Run abstürzt, musst du möglicherweise ein veraltetes Lock mit terraform force-unlock freigeben – nachdem du geprüft hast, dass niemand mehr applien lässt.
9. Was ist Drift, und wie gehst du damit um?
Drift bedeutet, dass die reale Infrastruktur vom State abweicht, meist weil jemand sie manuell geändert hat. terraform plan (oder plan -refresh-only) zeigt das an. Entscheide, ob du die Änderung durch ein Apply rückgängig machst oder den Code anpasst, damit er zum Ist-Zustand passt.
10. Wie bringst du eine bestehende Ressource unter Terraform?
Schreibe den Ressourcen-Block und führe dann terraform import <address> <id> aus, oder nutze in neueren Versionen einen import-Block. Führe danach plan aus und passe den Code an, bis keine Änderungen mehr angezeigt werden.
11. Wie teilst du den State über Umgebungen oder Teams auf?
Nutze einen separaten State pro Umgebung und Komponente, zum Beispiel einen fürs Networking, einen pro App und einen pro Umgebung. Das begrenzt den Blast Radius und beschleunigt Pläne. Teile Werte über Outputs und Data Sources oder Remote State.
Module und Struktur
12. Was ist ein Modul, und wann schreibt man eines?
Ein Modul ist eine wiederverwendbare Gruppe von Ressourcen mit Eingaben und Ausgaben. Man schreibt eines, wenn sich dasselbe Muster wiederholt, etwa ein VPC oder ein Service, und man eine einzige geprüfte Version davon möchte. Module sollten klein und fokussiert bleiben, sinnvolle Standardwerte haben und versioniert werden.
13. Wie verwaltet man Dev, Staging und Produktion?
Übliche Optionen sind getrennte Verzeichnisse oder Repos mit eigenem State und eigenen Variablendateien oder Workspaces. Viele Teams bevorzugen getrennten State pro Umgebung, da Workspaces denselben Code teilen und es leicht machen, versehentlich auf die falsche Umgebung anzuwenden. Verwende dieselben Module mit unterschiedlichen Variablenwerten.
14. Was sind Workspaces?
Benannte States innerhalb eines Backends und einer Konfiguration. Sie sind nützlich für temporäre Kopien desselben Setups, etwa Testumgebungen pro Branch, aber keine starke Trennung für die Produktion.
15. Was ist der Unterschied zwischen count und for_each?
count erstellt eine Anzahl von Kopien, die nach Position indiziert sind. for_each erstellt eine pro Eintrag in einer Map oder einem Set, benannt nach dem Schlüssel. Bevorzuge for_each, denn das Entfernen eines Eintrags aus der Mitte einer count-Liste verschiebt die Indizes und kann Ressourcen zerstören und neu erstellen.
16. Was macht depends_on?
Es fügt eine explizite Abhängigkeit hinzu, wenn Terraform sie nicht aus Referenzen erkennen kann. Verwende es sparsam, da die meisten Abhängigkeiten daraus entstehen, dass auf die Attribute einer anderen Ressource verwiesen wird.
Sichere Änderungen und Operationen
17. Was sind Lifecycle-Regeln?
create_before_destroy erstellt zuerst einen Ersatz, prevent_destroy blockiert die Löschung, ignore_changes überspringt Attribute, die außerhalb von Terraform geändert wurden, und replace_triggered_by erzwingt einen Ersatz, wenn sich eine andere Ressource ändert.
18. Wie geht man mit Secrets in Terraform um?
Sie dürfen nicht fest im Code stehen. Verwende einen Secrets Manager oder Umgebungsvariablen, markiere Variablen und Ausgaben als sensitive, und bedenke, dass Werte trotzdem im State landen können, also schütze den State. Vermeide es, Secrets über einfache Variablendateien in der Versionskontrolle weiterzugeben.
19. Wie prüft und wendet man Änderungen sicher an?
Führe plan in einem Pull Request aus, prüfe die Plan-Ausgabe, verlange eine Freigabe und wende aus einer Pipeline mit dem gespeicherten Plan an, damit genau das ausgeführt wird, was geprüft wurde. Achte auf Destroy- oder Replace-Zeilen im Plan.
20. Ein Plan zeigt, dass er eine Datenbank zerstören und neu erstellen wird. Was tust du?
Anhalten und herausfinden, warum. Häufige Ursachen sind ein geändertes unveränderliches Attribut, eine umbenannte Ressource oder ein verschobenes Modul. Verwende moved-Blöcke oder terraform state mv, um Adressänderungen zu beheben, nutze ignore_changes oder prevent_destroy, falls angebracht, und erstelle ein Backup vor jedem riskanten Apply.
21. Wie benennt man eine Ressource um oder verschiebt sie, ohne sie zu zerstören?
Verwende einen moved-Block im Code oder terraform state mv, um ihre Adresse im State zu ändern. Führe dann plan aus und bestätige, dass kein Destroy enthalten ist.
22. Wie pinnt man Versionen?
Verwende required_version für Terraform und required_providers mit Versionsbeschränkungen, und committe die Datei .terraform.lock.hcl, damit alle dieselben Provider-Builds verwenden. Aktualisiere bewusst und lies das Changelog.
Praktische und Szenario-Fragen
23. Was sind Provisioner, und sollte man sie verwenden?
Provisioner führen Skripte auf einer Ressource nach der Erstellung aus. Sie sind ein letztes Mittel, weil sie nicht im State verfolgt werden und Fehler schwer zu behandeln sind. Bevorzuge cloud-init, mit einem Tool wie Packer gebaute Images oder Configuration Management.
24. Wie würdest du Terraform für ein Team mit mehreren Umgebungen strukturieren?
„Ein Repo für gemeinsame Module mit versionierten Releases und ein Live-Repo mit einem Verzeichnis pro Umgebung und Komponente. Jedes hat seinen eigenen Remote-State mit Locking. Eine Pipeline führt fmt, validate und plan bei Pull Requests aus, verlangt eine Freigabe und wendet beim Merge an. Der Zugriff erfolgt über kurzlebige Credentials, und Policy-Prüfungen fangen riskante Änderungen ab."
25. Jemand hat eine Ressource in der Konsole geändert, und jetzt will Terraform sie zurücksetzen. Was tust du?
Finde heraus, warum die Person sie geändert hat. War es ein dringender Fix, aktualisiere den Code entsprechend und wende an, damit die Änderung erhalten bleibt. War es ein Fehler, wende an, um sie rückgängig zu machen. Füge dann Kontrollen hinzu, etwa eingeschränkten Schreibzugriff auf die Konsole, damit es nicht wieder passiert.
Wie man sich vorbereitet
Erstelle ein kleines Projekt mit einem Remote-Backend, einem Modul und zwei Umgebungen. Übe ein Umbenennen mit einem moved-Block, einen Import und eine Drift-Behebung. Sei bereit zu erklären, wann ein Plan dich überrascht hat und was du getan hast. Für verwandte Cloud-Themen siehe unseren AWS-Interview-Leitfaden und Kubernetes-Leitfaden.
Sag deine Antworten laut auf, besonders die State-Fragen, bei denen Erklärungen leicht durcheinandergeraten. Ein Mock-Interview-Transkript zeigt, wo du gezögert hast. Befolge die Regeln des Arbeitgebers zu KI-Tools in jedem Live-Interview.
Üben Sie Terraform Interview-Antworten mit YesToTheOffer
Führen Sie ein Mock-Technisches Interview durch, erklären Sie State und Module laut und überprüfen Sie anschließend Ihr Transkript. 30 kostenlose Minuten, kein Abonnement.
