Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der 004-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Ein Team klickt sich manuell durch Cloud-Konsolen; niemand weiß, wie die Produktion aussehen sollte.
IaC einführen. Konfigurationen leben in versionskontrollierten Dateien - die Dateien sind die maßgebliche Quelle der Wahrheit, nicht die Cloud-Konsole.
Warum: Audit-Trail, Peer Review, Rollback und Replikation ergeben sich alle aus der Versionskontrolle. Manuelle Bereitstellung bietet nichts davon.
Wählen Sie zwischen der Beschreibung des gewünschten Endzustands und dem Scripting der Schritte, um ihn zu erreichen.
Terraform ist deklarativ. Sie beschreiben das Ziel; Terraform ermittelt die API-Aufrufe. Ansible, Bash-Skripte, benutzerdefinierte SDKs sind imperativ.
Warum: Deklarative Konfigurationen sind idempotent und konvergieren unabhängig vom Startzustand. Imperative Skripte müssen jede Transition berücksichtigen.
Ein Ingenieur möchte, dass derselbe `terraform apply` sicher wiederholt werden kann, ohne Ressourcen zu verdoppeln.
Von Design aus idempotent. Das wiederholte Anwenden derselben Konfiguration konvergiert auf denselben Zustand - keine Duplikate, keine Abweichung.
Erkennen, wenn die Realität von der Konfiguration abweicht (jemand hat in der Konsole geklickt).
`terraform plan -refresh-only` liest den aktuellen Cloud-Zustand und meldet Unterschiede zum State, ohne Änderungen vorzuschlagen.
Unterscheiden Sie zwischen initialer Bereitstellung und laufendem Betrieb.
Tag 0 = Design und Planung. Tag 1 = initiale Bereitstellung (erster apply). Tag 2 = laufender Betrieb: Patches, Skalierung, Zertifikatsrotation, Behebung von Abweichungen.
Warum: Die meiste Produktionsarbeit ist Tag 2. IaC-Tools müssen Iterationen unterstützen, nicht nur die Erstbereitstellung.
Reduzieren Sie das Risiko von Konsolen-Drift; verlangen Sie, dass alle Infrastrukturänderungen eine Überprüfung durchlaufen.
GitOps mit IaC: Git ist die Quelle der Wahrheit, PRs lösen Pläne aus, Merges lösen Applies aus. Direkten Konsolenzugriff über SCP/IAM blockieren.
Workload erstreckt sich über AWS und GCP; das Team möchte ein Tool, einen Workflow.
Terraform mit mehreren Providern in einer Konfiguration: `hashicorp/aws` + `hashicorp/google`. Ausgaben eines Providers speisen die Eingaben eines anderen.
Warum: Provider-agnostischer Kern; Cloud-spezifische SDKs leben in steckbaren Providern. CloudFormation/ARM sind Single-Cloud-Lösungen.
Standard-Terraform-Lebenszyklusschritte.
`init` (Provider + Backend herunterladen) → `plan` (Vorschau) → `apply` (ausführen) → `destroy` (abbauen). `plan` ist schreibgeschützt und sicher.
Warum benötigt Terraform eine State-Datei, anstatt bei jedem Lauf die Cloud abzufragen?
State ordnet Konfigurationsadressen (`aws_instance.web`) realen Ressourcen-IDs zu, verfolgt Abhängigkeiten und cached Metadaten. Ohne sie kann Terraform nicht wissen, welche Cloud-Ressourcen es verwaltet, und welche woanders erstellt wurden.
Wählen Sie zwischen Open-Source-CLI und HCP Terraform.
Solo / kleines Team / keine Richtliniendurchsetzung → OSS CLI mit Remote-Backend. Mehrere Teams / Sentinel/OPA-Richtlinien / VCS-gesteuerte Ausführungen / dynamische Anmeldeinformationen → HCP Terraform.
Warum: Beide führen dieselbe Terraform-Binärdatei aus; HCP fügt Kollaboration, Governance und Remote-Runner-Infrastruktur hinzu.
VMs bereitstellen vs. Software darin konfigurieren.
Terraform provisioniert Cloud-Ressourcen (VMs, Netzwerke, IAM). Ansible/Chef/Puppet konfigurieren Software innerhalb der VMs. Sie sind komplementär, keine Konkurrenten.
Nur-AWS-Unternehmen diskutiert CloudFormation vs. Terraform.
CloudFormation hat eine engere AWS-Integration, native Rollbacks und keine State-Datei-Verwaltung. Terraform gewinnt bei Multi-Cloud, größerem Modul-Ökosystem und HCL-Ergonomie. Wählen Sie CFN, wenn nur AWS und Rollback am wichtigsten ist; sonst Terraform.
Provider-Quelle und -Version für reproduzierbare Installationen festlegen.
Deklarieren Sie in `terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } } }`.
Warum: Ohne explizite `required_providers` nimmt Terraform veraltete Registry-Namespaces an und wählt möglicherweise inkompatible Versionen.
Konfiguration hat `required_providers` für AWS, aber keinen `provider "aws"`-Block.
Terraform erstellt eine leere Standard-Provider-Konfiguration. Der AWS-Provider liest dann `AWS_ACCESS_KEY_ID`/`AWS_PROFILE`/IMDS in seiner Standardpriorität.
Warum: Ein expliziter `provider`-Block ist optional; er wird nur benötigt, um Standardwerte zu überschreiben oder mehrere Instanzen zu aliasen.
Entscheiden Sie, welchen Versions-Constraint-Operator Sie verwenden möchten.
`~> 5.0` erlaubt `>= 5.0, < 6.0` (jede 5.x). `~> 5.0.1` erlaubt `>= 5.0.1, < 5.1.0` (nur Patch-Updates). `>= 5.0` keine Obergrenze. `= 5.2.0` exakt. `!= 5.3.0` Ausschluss.
Warum: Der pessimistische Operator `~>` erlaubt nur, dass die rechteste Versionskomponente wächst.
Was macht `terraform init` eigentlich?
Lädt Provider gemäß `required_providers` herunter, initialisiert das Backend, lädt Modulquellen herunter und schreibt `.terraform/` sowie `.terraform.lock.hcl`. Erforderlich vor `plan` oder `apply`.
Eine `.terraform.lock.hcl`-Datei erschien nach `init`. Committen oder gitignore?
Committen Sie es. Die Lock-Datei speichert exakte Provider-Versionen + kryptografische Prüfsummen. Stellt sicher, dass jeder Kollaborator und CI-Runner identische Provider installiert.
Warum: Ohne sie kann `terraform init` auf einer anderen Maschine eine neuere kompatible Version wählen, was zu überraschenden Diffs führen kann.
Standardisieren Sie Leerzeichen, Ausrichtung und Einrückung über `.tf`-Dateien hinweg.
`terraform fmt` schreibt `.tf`-Dateien an Ort und Stelle in den kanonischen Stil um. In Pre-Commit-Hooks und CI ausführen.
Syntaxfehler und Typenkonflikte abfangen, ohne Cloud-APIs aufzurufen.
`terraform validate` prüft HCL-Syntax, Typkonsistenz, erforderliche Argumente und interne Referenzen. Nur lokal, keine Provider-Authentifizierung erforderlich.
Warum: Fängt keine Provider-seitigen Probleme (Auth, fehlende Ressourcen) ab - diese treten erst bei `plan` auf.
CI führt `terraform init` wiederholt über viele Projekte hinweg aus, wobei jedes Mal dieselben Provider von Grund auf neu heruntergeladen werden.
Setzen Sie `TF_PLUGIN_CACHE_DIR` (oder `plugin_cache_dir` in der CLI-Konfiguration). Provider werden einmal heruntergeladen und in projektbezogene `.terraform/`-Verzeichnisse symlinked.
Provider-Quelladressen folgen welchem Format?
`<hostname>/<namespace>/<type>` - z.B. `registry.terraform.io/hashicorp/aws`. Hostname weggelassen bedeutet Standardwert öffentliche Terraform Registry. Namespace = Anbieter. Type = Providername.
Verhindern Sie, dass Kollaboratoren eine inkompatible Terraform CLI-Version ausführen.
`terraform { required_version = ">= 1.5, < 2.0" }`. CLI verweigert den Betrieb, wenn die laufende Version nicht übereinstimmt.
Wählen Sie die Provider-Authentifizierung für einen CI/CD-Runner.
Am besten: kurzlebige dynamische Anmeldeinformationen (OIDC-Vertrauen zu AWS/Azure/GCP, HCP Terraform dynamische Provider-Anmeldeinformationen). Akzeptabel: Umgebungsvariablen (`AWS_ACCESS_KEY_ID`). Vermeiden: fest codierte `provider`-Block-Anmeldeinformationen.
Warum: Statische, langlebige Geheimnisse in der Konfiguration sind die Hauptursache für Vorfälle mit geleakten Anmeldeinformationen.
Wo sind die Top-Level-Einstellungen abgelegt?
Ein `terraform { ... }`-Block enthält `required_version`, `required_providers`, `backend`, `cloud` und Experimente. Mehrere `terraform`-Blöcke über Dateien hinweg werden zusammengeführt.
Ressource existiert im State, sollte aber nicht mehr von Terraform verwaltet werden; die Cloud-Ressource muss weiterlaufen.
`terraform state rm <addr>`. Entfernt aus dem State, ohne die Cloud-Ressource zu zerstören.
Den Namen einer Ressource umstrukturiert oder in ein Modul verschoben; möchte Zerstörung/Neuerstellung vermeiden.
`terraform state mv <old> <new>`. Aktualisiert die State-Zuordnung, ohne Cloud-Ressourcen zu berühren.
Warum: In Terraform 1.1+ den `moved`-Block in HCL bevorzugen - er ist überprüfbar, versionskontrolliert und funktioniert in PR-Plänen.
Die URL der internen Provider Registry hat sich geändert; der bestehende State verweist immer noch auf die alte Quelladresse.
`terraform state replace-provider <old-source> <new-source>`. Schreibt Provider-Referenzen im State um.
Apply stürzte während der Ausführung ab; DynamoDB-Lock ist blockiert und andere Ingenieure sind blockiert.
`terraform force-unlock <LOCK_ID>` (Lock ID ist in der Fehlermeldung). Überprüfen Sie, ob niemand anderes läuft, bevor Sie entsperren.
Warum: Locks werden bei einem Absturz nicht automatisch freigegeben, da die Bereinigungsphase nie ausgeführt wurde.
Ein bestehender, manuell erstellter S3-Bucket muss ohne Neuerstellung unter Terraform-Verwaltung gebracht werden.
Schreiben Sie den Ressourcenblock, dann `terraform import aws_s3_bucket.legacy legacy-bucket-name`. Der State speichert nun den bestehenden Bucket; nachfolgende Pläne zeigen nur noch Drift.
Müssen viele Ressourcen reproduzierbar über CI importiert werden, anstatt Ad-hoc-CLI-Befehle zu verwenden.
Verwenden Sie den `import`-Block (Terraform 1.5+): `import { to = aws_s3_bucket.legacy, id = "legacy-bucket-name" }`. Importe erfolgen während `apply`, sind versionskontrolliert und funktionieren in der Plan-Ausgabe.
Einen kryptischen Provider-Fehler debuggen; volle HTTP-Traces benötigt.
`TF_LOG=TRACE` (am ausführlichsten). `TF_LOG_PATH=./tf.log` schreibt in eine Datei. Andere Ebenen: DEBUG, INFO, WARN, ERROR.
Einen Ausdruck wie `merge()` oder `cidrsubnet()` gegen den aktuellen State testen, ohne anzuwenden.
`terraform console` öffnet einen interaktiven REPL mit der aktuellen Konfiguration + State im Scope. Nützlich für das Prototyping von Locals und Outputs.
Den Abhängigkeits-DAG einer komplexen Konfiguration visualisieren.
`terraform graph | dot -Tsvg > graph.svg` erzeugt eine Graphviz-Visualisierung der Ressourcenabhängigkeiten.
Eine Terraform-Ausgabe aus einem CI-Skript lesen.
`terraform output -json <name>` gibt JSON aus, das sicher für `jq`-Parsing ist. Das einfache `terraform output` ist menschenlesbar formatiert und nicht Skript-sicher.
Eine einzelne Ressource beim nächsten Apply zur Neuerstellung zwingen.
`terraform apply -replace=aws_instance.web` (Terraform 1.x). Das veraltete `terraform taint` ist veraltet.
Warum: `-replace` ist in der Plan-Ausgabe überprüfbar; `taint` mutierte den State stillschweigend vor dem nächsten Plan.
Inspektion, was derzeit im State verfolgt wird.
`terraform state list` zeigt alle Ressourcenadressen an. `terraform state show <addr>` zeigt Attribute für eine Ressource. Für indizierte Ressourcen Anführungszeichen verwenden: `terraform state show 'aws_instance.web[0]'`.
Wählen Sie eine Modulquelle aus.
Lokaler Pfad → `./modules/vpc`. Öffentliche Registry → `terraform-aws-modules/vpc/aws`. Git → `git::https://github.com/org/repo.git//path?ref=v1.0`. S3/HTTP/Mercurial werden ebenfalls unterstützt.
Ein Registry-Modul so festlegen, dass nur Patch-Updates erlaubt sind.
`version = "~> 3.5.2"` erlaubt `>= 3.5.2, < 3.6.0`. Für Toleranz bei Minor-Updates verwenden Sie `~> 3.0` (jede 3.x). Module mit lokalem Pfad unterstützen `version` nicht.
Nur-interne Module mit organisationsweiter Sichtbarkeit.
HCP Terraform Private Module Registry. Adresse: `app.terraform.io/<org>/<name>/<provider>`. Versionen werden aus Git-Tags gemäß Semver (`v1.2.0`) erkannt.
Sowohl die öffentliche Registry als auch die private HCP Terraform Registry erkennen Modulversionen über welchen Mechanismus?
Git-Tags, die der semantischen Versionierung (`v1.2.0` oder `1.2.0`) folgen. Ein neuer Tag pushen → neue Version verfügbar.
Den ARN eines erstellten Buckets der aufrufenden Konfiguration zur Verfügung stellen.
Innerhalb des Moduls: `output "bucket_arn" { value = aws_s3_bucket.this.arn }`. Aufrufender liest es als `module.<name>.bucket_arn`.
Ein Modul parametrisieren, damit Aufrufer CIDR, Namen, Tags bereitstellen können.
`variable`-Blöcke im Modul-Root definieren Eingaben. Aufrufer übergeben sie inline: `module "vpc" { source = "...", cidr = "10.0.0.0/16" }`.
Das Modul erhält ein Datenbankpasswort als Eingabe; der Wert sollte niemals in der CLI-Ausgabe erscheinen.
Variable als `sensitive = true` markieren. Apply/Plan-Ausgabe zeigt `(sensitive value)`. Hinweis: immer noch im State im Klartext gespeichert.
Ein "Plattform"-Modul erstellen, das intern VPC + EKS + RDS-Module aufruft.
Ein Modul kann andere Module aufrufen. Verdrahten Sie Ausgaben von einem als Eingaben für das nächste: `eks_subnet_ids = module.vpc.private_subnet_ids`.
Dasselbe Modul N-mal mit unterschiedlichen Eingaben instanziieren (z.B. einmal pro Region).
`module "regional" { for_each = toset(["us-east-1", "eu-west-1"]), source = "...", region = each.key }`. Referenzierung über `module.regional["us-east-1"].output_name`.
Modul benötigt einen aliased Provider (z.B. für eine nicht standardmäßige Region).
Aufrufer übergibt `providers = { aws = aws.us_west }`-Block im `module`-Aufruf. Modul deklariert `configuration_aliases = [aws.us_west]` in `required_providers`.
Ein öffentliches Registry-Modul adressieren.
`<NAMESPACE>/<NAME>/<PROVIDER>` - z.B. `terraform-aws-modules/vpc/aws`. Git-Tags steuern die Versionen.
Dasselbe Modul über Dev/Staging/Prod hinweg wiederverwenden.
Zwei Muster: (1) Workspaces mit einer Root-Konfiguration + `*.tfvars` pro Workspace. (2) Root-Konfigurationen pro Umgebung (`envs/dev/main.tf`, `envs/prod/main.tf`), die jeweils gemeinsame Module aufrufen. Muster 2 ist häufiger für die Isolation mehrerer Teams.
Sicherstellen, dass CI genau das anwendet, was im Plan überprüft wurde, ohne Drift zwischen den Schritten.
`terraform plan -out=tfplan` speichert den Plan. Dann wendet `terraform apply tfplan` genau diesen Plan an. Das Verweigern einer Neuplanung eliminiert das Time-of-Check/Time-of-Use-Risiko.
Plan-Ausgabe-Symbole dekodieren: `+`, `-`, `~`, `-/+`, `<=`.
`+` erstellen. `-` zerstören. `~` an Ort und Stelle aktualisieren. `-/+` zerstören, dann erstellen (ersetzen). `<=` lesen (data source). Das Ersetzungssymbol bedeutet, dass sich ein `forces replacement`-Attribut geändert hat.
Eine einzelne defekte Ressource schnell reparieren, ohne den Rest der Konfiguration zu berühren.
`terraform apply -target=aws_instance.web`. Sparsam verwenden - umgeht die Abhängigkeitsverfolgung und kann den Zustand inkonsistent hinterlassen. Dokumentieren Sie, warum jeder `-target` verwendet wurde.
Warum: HashiCorp sagt explizit, dass `-target` für außergewöhnliche Fehlerbehebung gedacht ist, nicht für den normalen Workflow.
Eine bestimmte Ressource zur Neuerstellung zwingen.
`terraform apply -replace=aws_instance.web`. Ersetzt den veralteten `terraform taint`-Workflow.
Alles in der aktuellen Konfiguration abbauen.
`terraform destroy` (oder `terraform apply -destroy`). Plant die Umkehrung der Konfiguration. Erfordert Bestätigung, es sei denn `-auto-approve`.
Eine Ressource zerstören, ohne andere zu beeinträchtigen.
`terraform destroy -target=aws_instance.web`. Dieselben `-target`-Einschränkungen wie bei apply - sparsam verwenden.
Drift erkennen, ohne Änderungen vorzuschlagen.
`terraform plan -refresh-only`. Aktualisiert den State von realen Ressourcen und meldet Unterschiede, erzeugt aber keinen ressourcenmodifizierenden Plan.
Warum: Ersetzt den veralteten eigenständigen `terraform refresh`-Befehl.
Ressource A muss existieren, bevor Ressource B existiert, aber B referenziert keine Attribute von A.
Fügen Sie `depends_on = [resource_a.name]` zu B hinzu. Nur verwenden, wenn implizite Attributreferenzen die Abhängigkeit nicht ausdrücken können (z.B. IAM-Richtlinie muss propagieren, bevor EC2 sie verwendet).
Eine Ressource ohne Ausfallzeit ersetzen.
`lifecycle { create_before_destroy = true }`. Terraform erstellt zuerst die neue Ressource, leitet Referenzen um, und zerstört dann die alte.
Warum: Standard ist Destroy-Then-Create, was zu Ausfallzeiten führt. Hinweis: Abhängige Ressourcen müssen die Änderung ebenfalls unterstützen.
Versehentliches `terraform destroy` der Produktionsdatenbank verhindern.
`lifecycle { prevent_destroy = true }`. Führt dazu, dass `terraform plan` fehlschlägt, wenn eine Zerstörung für diese Ressource vorgeschlagen wird.
Warum: Letzte Schutzmaßnahme - schützt nicht vor `terraform state rm` gefolgt von destroy.
Anwendung setzt zur Laufzeit einen Tag, den Terraform ständig rückgängig macht.
`lifecycle { ignore_changes = [tags["LastDeployed"]] }`. Terraform ignoriert Drift bei diesen Attributen.
Eine EC2-Instanz ersetzen, wenn sich ein zugehöriges Launch Template ändert (ohne die EC2 direkt zu modifizieren).
`lifecycle { replace_triggered_by = [aws_launch_template.web.latest_version] }` (Terraform 1.2+). Die Instanz wird ersetzt, wenn sich einer der gelisteten Werte ändert.
CI/CD-Pipeline wendet nach erfolgreicher Planungsaufgabe an; kein Mensch an der Tastatur.
`terraform apply -auto-approve` überspringt die interaktive Bestätigung. Kombinieren Sie dies mit einer gespeicherten Plan-Datei (`terraform apply tfplan`), um CI deterministisch zu machen.
Cloud-Provider begrenzt die Terraform-Rate; viele Ressourcenerstellungen schlagen intermittierend fehl.
`terraform apply -parallelism=5` (Standard 10) begrenzt die gleichzeitigen Ressourcenoperationen.
Zwei Ressourcen haben keine gegenseitigen Abhängigkeiten.
Terraform erstellt sie parallel. Der DAG erzwingt die Reihenfolge nur entlang von Referenzkanten.
Warum: Ressourcen auf derselben DAG-Tiefe werden bis zu `-parallelism` gleichzeitig ausgeführt.
Variable definiert in `terraform.tfvars`, `TF_VAR_region` Env und `-var=region=...` CLI-Flag.
Höchste gewinnt: CLI `-var` / `-var-file` > `*.auto.tfvars` (lexikalische Reihenfolge) > `terraform.tfvars` > `TF_VAR_*` Env > variabler Standardwert.
Umgebungsspezifische Variablenwerte übergeben, ohne Geheimnisse in Git einzuchecken.
`terraform apply -var-file=prod.tfvars`. `*.auto.tfvars`-Dateien werden automatisch geladen. `terraform.tfvars` wird ebenfalls automatisch geladen.
Den Namen/Pfad einer Ressource in HCL umstrukturieren, ohne Destroy/Recreate.
`moved { from = aws_instance.old_web; to = aws_instance.new_web }` (Terraform 1.1+). Im PR-Plan überprüfbar; ersetzt Ad-hoc `terraform state mv`.
Warum: Lebt in HCL, versionskontrolliert, idempotent über Kollaboratoren hinweg. `state mv` ist ein einmaliger CLI-Nebeneffekt.
Eine Ressource aus der Konfiguration entfernen, ohne sie zu zerstören.
`removed { from = aws_instance.legacy; lifecycle { destroy = false } }` (Terraform 1.7+). Ersetzt Ad-hoc `terraform state rm`. `destroy = true` setzen, um auch zu zerstören.
CI muss wissen, ob ein Plan Änderungen enthält, ohne Text zu parsen.
`terraform plan -detailed-exitcode`. 0 = keine Änderungen, 1 = Fehler, 2 = Änderungen vorhanden. Steuert "plan-only" PR-Jobs.
Was enthält der State eigentlich?
Zuordnung von Ressourcenadresse zu Cloud-Ressourcen-ID, Attribut-Snapshots, Metadaten des Abhängigkeitsgraphen und Modul-/Provider-Referenzen. Wird verwendet, um Diffs zu planen und Drift zu erkennen.
Einzelner Ingenieur prototypisiert lokal - ist lokaler State in Ordnung?
Ja für Solo-Wegwerfarbeiten. Terraform schreibt `terraform.tfstate` neben die Konfiguration. Wechseln Sie zu einem Remote-Backend, sobald eine zweite Person, ein CI-Runner oder eine Produktionsumgebung beteiligt ist.
Team benötigt geteilten State über Ingenieure hinweg, mit Locking + Versionierung, AWS-gehostet.
S3-Backend. Konfigurieren Sie `bucket`, `key`, `region`. Fügen Sie `dynamodb_table` für State-Locking hinzu. Aktivieren Sie Bucket-Versionierung + SSE-KMS Server-Side-Encryption.
Warum: S3 + DynamoDB ist das kanonische AWS-gehostete Remote-Backend. Versionierung stellt den State nach beschädigten oder versehentlich überschriebenen Daten wieder her.
Azure-gehosteter Shared State ohne statische Anmeldeinformationen in CI.
Backend-Typ `azurerm`. Setzen Sie `use_msi = true` (Managed Identity) oder `use_oidc = true`, damit der Runner sich über seine Identität authentifiziert. Native Blob-Lease handhabt Locking.
GCP-gehosteter Shared State mit Objektversionierung.
Backend-Typ `gcs`. Konfigurieren Sie `bucket` + `prefix`. GCS verfügt über integrierte Objektgenerationen (Versionierung); Locking über GCS-Objekt-Lock.
Zwei Ingenieure führen gleichzeitig apply auf denselben S3-basierten State aus.
DynamoDB-Lock-Tabelle verhindert gleichzeitige Schreibvorgänge. Der erste erwirbt das Lock, der zweite sieht einen `state lock failed`-Fehler und muss warten oder `force-unlock` verwenden, falls veraltet.
Warum: Ohne DynamoDB können gleichzeitige Applies die S3-State-Datei beschädigen.
HCP Terraform - muss ich DynamoDB konfigurieren?
Nein. HCP Terraform handhabt State, Locking und Verschlüsselung nativ. Sie deklarieren einfach `cloud { ... }` anstelle eines Backends.
Von lokalem State zu S3-Backend migrieren.
Fügen Sie den `backend "s3"`-Block hinzu. Führen Sie `terraform init -migrate-state` aus. Terraform kopiert den lokalen State nach S3 und fordert eine Bestätigung.
Die Backend-Konfiguration wurde geändert (z.B. neuer Bucket), aber Sie möchten den vorhandenen State nicht migrieren.
`terraform init -reconfigure`. Initialisiert das Backend neu und ignoriert den vorhandenen lokalen Cache. Verwenden Sie dies, wenn Sie absichtlich neu beginnen.
Dev / Staging / Prod mit einer Root-Konfiguration verwalten.
Workspaces - `terraform workspace new staging`, `terraform workspace select prod`. Jeder hat seine eigene State-Datei. Referenzieren über `terraform.workspace` in HCL.
Warum: Leichte Option. Für echte Isolation (unterschiedliches IAM, separate Konten) bevorzugen Sie Root-Konfigurationen pro Umgebung.
Wo speichert das lokale Backend den Workspace-State?
`default`-Workspace → `terraform.tfstate` im Projekt-Root. Andere Workspaces → `terraform.tfstate.d/<NAME>/terraform.tfstate`.
Führen Sie `terraform workspace select prod` aus, während Staging-Ressourcen existieren.
Staging-Ressourcen bleiben unberührt. Das Wechseln von Workspaces ändert nur, welche State-Datei Terraform als Nächstes liest - es ist eine lokale Zeigeränderung.
Verfügbare Workspaces und den aktiven anzeigen.
`terraform workspace list` (Sternchen markiert den aktuellen). `terraform workspace show` gibt nur den aktuellen Namen aus.
Sicherheitsteam fragt, wie Terraform RDS-Passwörter im State handhabt.
Sensible Werte werden **im Klartext** im State gespeichert. Abhilfen: Das Backend im Ruhezustand verschlüsseln (S3 SSE-KMS, HCP nativ), IAM-Zugriff auf den State-Bucket einschränken und nach Möglichkeit keine Geheimnisse in Terraform ablegen.
Warum: Das Flag `sensitive = true` verbirgt Werte nur vor der CLI-Ausgabe, nicht vor dem State.
Compliance erfordert Verschlüsselung im Ruhezustand für den State.
S3: SSE-KMS für den Bucket aktivieren. Azure: Speicherkontoverschlüsselung (Standard EIN). GCS: vom Kunden verwaltete Verschlüsselungsschlüssel. HCP Terraform: nativ im Ruhezustand verschlüsselt.
Ein Ingenieur hat versehentlich `terraform destroy` für die Produktion ausgeführt. Der State ist jetzt leer.
Stellen Sie die vorherige Version der State-Datei aus der S3-Versionierung wieder her, führen Sie dann `terraform plan` aus, um zu sehen, was Terraform nun zu erstellen/importieren glaubt. Kombinieren Sie dies mit Cloud-seitiger Wiederherstellung (Snapshots, `aws backup`) für die zerstörten Ressourcen.
Die State-Datei sieht falsch aus; versucht, sie direkt zu bearbeiten.
Nicht tun. Verwenden Sie `terraform state`-Unterbefehle (`mv`, `rm`, `replace-provider`, `pull`, `push`). Manuelle JSON-Bearbeitungen umgehen Integritätsprüfungen und beschädigen die Historie.
Rohen Remote State JSON inspizieren oder eine wiederhergestellte State-Datei pushen.
`terraform state pull` schreibt den aktuellen Remote State auf stdout. `terraform state push <file>` überschreibt den Remote State mit der angegebenen Datei. Push ist destruktiv - zuerst sichern.
Ein temporäres API-Token über Terraform übergeben, ohne dass es im State landet.
Variable als `ephemeral = true` markieren (Terraform 1.10+). Ephemere Werte werden niemals im State oder in Plan-Dateien gespeichert. Um sie über eine Modul-Ausgabe zu exportieren, muss auch die Ausgabe als `ephemeral = true` markiert werden.
Warum: `sensitive` ist in der CLI verborgen, aber im State im Klartext gespeichert. `ephemeral` wird wirklich niemals gespeichert.
Unterschied zwischen einem `sensitive`-Argument und einem Nur-Schreib-Argument (z.B. `password_wo`).
`sensitive` wird im State im Klartext gespeichert, nur in der CLI redigiert. Write-only wird **niemals** im State gespeichert. Um Änderungen an Write-only-Attributen zu erkennen, verwendet Terraform ein begleitendes Versionsfeld (z.B. `password_wo_version`).
Ein Element einer `count`-Ressource im State anzeigen.
Adressen in Anführungszeichen setzen: `terraform state show 'aws_instance.web[0]'`. Ohne Anführungszeichen könnte die Shell die Klammern interpretieren.
Verschiedene Teams müssen unabhängig voneinander arbeiten können, ohne sich gegenseitig in die Quere zu kommen.
Eine State-Datei pro Team (oder pro Umgebung pro Team). Separate Backends/Buckets. Verwenden Sie die Datenquelle `terraform_remote_state`, um einen anderen State schreibgeschützt zu lesen.
Netzwerkteam verwaltet VPC; App-Team benötigt die VPC ID.
`data "terraform_remote_state" "network" { backend = "s3"; config = { bucket = "...", key = "network/terraform.tfstate" } }`. Outputs referenzieren als `data.terraform_remote_state.network.outputs.vpc_id`.
Warum: Schreibgeschützt - der State des Netzwerk-Teams wird nicht gesperrt oder geändert.
Konfiguration, die mit Terraform 0.13 geschrieben wurde; möchte 1.x verwenden.
State-Dateien sind vorwärtskompatibel: 1.x liest 0.13 State. HashiCorp empfiehlt inkrementelle Upgrades (0.13 → 0.14 → … → 1.x), wobei jede Version gegen den State ausgeführt wird.
Jemand hat eine Sicherheitsgruppe über die Konsole geändert; Terraform soll entweder den Zustand wiederherstellen oder den neuen Zustand akzeptieren.
Wiederherstellen: `terraform apply` - Terraform kehrt zur Konfiguration zurück. Akzeptieren: HCL an die Realität anpassen, dann anwenden (kein Diff). Zuerst über `terraform plan -refresh-only` erkennen.
Eine Variable stark typisieren.
Primitive: `string`, `number`, `bool`. Sammlungen: `list(<type>)`, `set(<type>)`, `map(<type>)`. Strukturell: `object({...})`, `tuple([...])`. Verwenden Sie `any` nur, wenn es wirklich polymorph ist.
Den `environment` auf dev/staging/prod beschränken.
`variable "environment" { validation { condition = contains(["dev","staging","prod"], var.environment); error_message = "..." } }`. Mehrere `validation`-Blöcke erlaubt; alle müssen bestehen.
Ein Datenbankpasswort ausgeben, ohne dass es in `terraform output` erscheint.
`output "db_password" { value = ...; sensitive = true }`. CLI zeigt `(sensitive value)`. Immer noch über `terraform output db_password` oder `-json` lesbar (absichtlich - für Skripte).
Einen Wert einmal berechnen und über viele Ressourcen hinweg wiederverwenden.
`locals { common_tags = merge(var.tags, { Project = var.project }) }`. Referenzieren als `local.common_tags`. Nicht von außerhalb des Moduls überschreibbar.
Ein bestehendes AMI nachschlagen, ohne es zu verwalten.
`data "aws_ami" "ubuntu" { most_recent = true; filter { ... } }`. Schreibgeschützt. Attribute referenzieren als `data.aws_ami.ubuntu.id`.
N ähnliche Ressourcen erstellen - `count` oder `for_each` wählen.
`for_each` (mit Map oder Set), wenn Elemente eine stabile Identität haben (Regionsnamen, Umgebungsschlüssel). `count` für "Ich brauche N Kopien, Reihenfolge ist egal, Identität ist nur ein Index". Hinzufügen/Entfernen in der Mitte von `count` führt zu Destroy/Recreate; `for_each` bewahrt die Identität.
Eine Ressource pro Element in einer Liste von Strings erstellen.
`for_each = toset(["a", "b", "c"])`. `each.key` und `each.value` ergeben beide den String. Für Maps: `for_each = var.users` - `each.key` = Map-Schlüssel, `each.value` = Map-Wert.
Eine variable Anzahl verschachtelter Blöcke generieren (z.B. Ingress-Regeln).
`dynamic "ingress" { for_each = var.rules; content { from_port = ingress.value.from; ... } }`. Das `iterator`-Argument kann den Iterator bei Bedarf umbenennen.
Eine Liste von Attributen über alle Instanzen einer `count`-Ressource abrufen.
`aws_instance.web[*].id` gibt eine Liste von IDs zurück. Funktioniert mit `count` und `for_each` (aber `for_each` erzeugt eine ungeordnete Map, also `values(aws_instance.web)[*].id`).
Einen Wert basierend auf einer Bedingung setzen.
Ternär: `var.is_prod ? 5 : 1`. Beide Zweige müssen denselben Typ erzeugen.
Zwei Maps kombinieren; Werte der zweiten Map gewinnen bei Schlüsselkollision.
`merge(local.defaults, local.overrides)`. Rechteste Map gewinnt. Nützlich für die Tag-Komposition.
Einen Map-Wert mit einem Standardwert lesen, wenn der Schlüssel fehlt.
`lookup(var.config, "region", "us-east-1")`. Gibt den Standardwert zurück, wenn der Schlüssel nicht vorhanden ist. Für tief optionale Strukturen bevorzugen Sie das optionale `try()`.
Verschachtelte Listen in eine flache Liste umwandeln.
`flatten([["a","b"], ["c"], [["d","e"]]])` → `["a","b","c","d","e"]`. Rekursives Abflachen von Listen; Reihenfolge wird beibehalten.
Eine Terraform-Map in ein IAM-Policy-Dokument einbetten.
`jsonencode({Version = "2012-10-17", Statement = [...]})`. Erzeugt einen JSON-String. Inverse: `jsondecode()`.
Ein templated User-Data-Skript mit Werten aus Variablen rendern.
`templatefile("init.sh.tpl", { region = var.region, env = var.env })`. Template verwendet `${region}`-Syntax. Neuere Alternative für statisches Rendern: `file()` + `format()`.
Subnetz-CIDRs aus einem VPC-Bereich ausschneiden.
`cidrsubnet("10.0.0.0/16", 8, 0)` → `10.0.0.0/24`. Erstes Argument = Parent, zweites = Bits zum Erweitern, drittes = Subnetznummer.
Einen Wert lesen, der möglicherweise nicht existiert; auf einen Standardwert zurückgreifen.
`try(yamldecode(file("config.yaml")), { defaults = true })`. Wertet von links nach rechts aus; gibt den ersten nicht fehlerhaften Ausdruck zurück.
Über Dateien iterieren, die einem Glob-Muster entsprechen.
`fileset(path.module, "configs/*.json")` gibt ein Set von Pfaden zurück. Kombinieren Sie dies mit `for_each`, um eine Ressource pro Datei zu verwalten.
Derselbe Provider in zwei Regionen (z.B. AWS us-east-1 + us-west-2).
Zwei `provider "aws" { alias = "..." }`-Blöcke. Ressourcen wählen sich über `provider = aws.us_west` ein. Module akzeptieren Aliase über `configuration_aliases`.
Einen Shell-Befehl auf einer neu erstellten VM ausführen.
`remote-exec` Provisioner innerhalb einer Ressource. Letztes Mittel - bevorzugen Sie Cloud-init, Benutzerdaten oder Konfigurationsmanagement. Provisioner werden nicht im State verfolgt und werden bei Drift nicht erneut ausgeführt.
Einen Befehl ausführen, der keiner Cloud-Ressource entspricht (z.B. CLI-Aufruf).
`resource "null_resource" "trigger" { triggers = { sha = sha1(file(".")) }; provisioner "local-exec" { command = "..." } }`. Wird erneut ausgeführt, wenn sich `triggers` ändern.
Eine Laufzeitinvariante (z.B. Health-Endpunkt gibt 200 zurück) kontinuierlich überprüfen, ohne den Apply zu blockieren.
`check "endpoint" { data "http" "h" { url = "..." }; assert { condition = data.http.h.status_code == 200; error_message = "..." } }`. Läuft bei Plan/Apply; Fehler ist eine Warnung, kein harter Fehler.
Warum: `check` erlaubt das Scoping von Datenquellen, die nur innerhalb des Checks verwendbar sind. `precondition`/`postcondition` sind harte Fehler bei Plan/Apply.
Den Plan fehlschlagen lassen, wenn ein AMI zu alt ist.
`lifecycle { precondition { condition = data.aws_ami.x.creation_date > "2024-01-01"; error_message = "..." } }`. Harter Fehler, wird je nach Bedarf vor/nachher ausgewertet.
Variable mit einem positionalen Wert fester Form.
`type = tuple([string, number, bool])` erfordert genau drei Elemente in dieser Reihenfolge. Anders als eine Liste (homogen, variable Länge).
Einen strukturierten Input stark typisieren (z.B. `database = { instance_class = string, allocated_storage = number }`).
`type = object({ instance_class = string, allocated_storage = number, multi_az = optional(bool, false) })`. `optional(<type>, <default>)` macht Attribute optional.
Wie werden `*.tfvars`-Dateien geladen?
`terraform.tfvars` und `*.auto.tfvars` laden automatisch (lexikalische Reihenfolge für `auto`). Andere Namen erfordern `-var-file=path.tfvars`.
Automatisierte Tests für ein Terraform-Modul schreiben.
`.tftest.hcl`-Dateien mit `run "name" { command = plan|apply, assert { condition = ..., error_message = ... } }`. `command = plan` ist ohne Nebenwirkungen; `command = apply` erstellt tatsächlich Ressourcen.
Variablen in Testläufe übergeben.
Dateiebene `variables { ... }`-Block gilt für alle Läufe. Pro-Lauf `variables { ... }` überschreibt nur für diesen Lauf.
Wählen Sie einen Workspace-Ausführungsmodus in HCP Terraform.
VCS-gesteuert (Auto-Plan bei Git-Push, am häufigsten). CLI-gesteuert (Entwickler führt `terraform plan/apply` lokal aus, HCP hält den State). API-gesteuert (Terraform-Läufe durch API ausgelöst, von Automatisierungs-/CD-Systemen verwendet).
Reihenfolge der Stufen in einem HCP Terraform-Lauf.
Plan → Kostenkalkulation (falls aktiviert) → Policy-Prüfung (Sentinel/OPA) → manueller oder Auto-Apply. Zwingende Policy-Fehler oder Run-Task-Fehler stoppen die Pipeline.
Erzwingen, dass alle S3-Buckets verschlüsselt sind, und Apply blockieren, falls verletzt.
Sentinel-Policy mit zwingender Durchsetzung. Prüft den Plan; Fehler blockiert Apply. Soft-mandatory erlaubt Admin-Überschreibung. Advisory protokolliert nur, blockiert aber nie.
Einen Drittanbieter-Sicherheitsscanner in die HCP Terraform Run-Pipeline integrieren.
Run Task in der Post-Plan-Phase. HCP POSTet den Plan an Ihren Endpunkt; der Endpunkt antwortet mit Pass/Fail. Zwingende Durchsetzung blockiert Apply bei Fehlschlag; Advisory warnt nur.
Den Einfluss eines Pull Requests vor dem Mergen anzeigen.
Spekulative Pläne werden auf PRs (oder Branches) ausgeführt, kommentieren die Ergebnisse zurück zum PR und werden niemals angewendet. Automatisch ausgelöst, wenn die VCS-Integration aktiviert ist.
Vermeiden Sie das Speichern von AWS-Zugriffsschlüsseln als statische Geheimnisse in HCP Terraform-Variablen.
Dynamische Provider-Anmeldeinformationen. HCP Terraform fordert kurzlebige Anmeldeinformationen über OIDC-Vertrauen zu AWS/Azure/GCP an. Keine statischen Schlüssel; Identitäten pro Lauf; audit-freundlich.
Warum: Statische Schlüssel leaken. OIDC-Vertrauen bindet Anmeldeinformationen an den Workspace + Lauf, läuft innerhalb einer Stunde ab.
Dieselben Provider-Anmeldeinformationen über viele Workspaces hinweg teilen.
Variablen-Sets. Einmal auf Organisations-/Projektebene definieren, an viele Workspaces anhängen. Updates verbreiten sich ohne Bearbeitungen pro Workspace.
Was ist das Standardprojekt in HCP Terraform?
Ein integriertes Projekt, das in jeder Organisation existiert und nicht gelöscht werden kann (Umbenennung ist erlaubt). Alle Workspaces gehören dazu, es sei denn, sie sind explizit einem anderen Projekt zugewiesen.
Downstream-Workspace anwenden, sobald ein Upstream-Workspace einen erfolgreichen Apply abgeschlossen hat.
Run-Trigger. Konfigurieren Sie die Quell-Workspaces im abhängigen Workspace; HCP reiht einen Lauf im abhängigen nach jedem erfolgreichen Upstream-Apply ein.