# Pulumi vs Terraform 2026: Infrastructure as Code mit TypeScript und Interviewfragen > Pulumi vs Terraform Vergleich für 2026. TypeScript-Unterstützung, State-Management, Provider-Ökosysteme, Migrationsstrategien und DevOps-Interviewfragen. - Published: 2026-09-21 - Updated: 2026-09-21 - Author: Anthony Fillion-Maillet - Reading time: 5 min --- Pulumi vs Terraform stellt die zentrale Infrastructure-as-Code-Entscheidung für DevOps-Teams im Jahr 2026 dar. Beide Tools provisionieren Cloud-Ressourcen deklarativ, unterscheiden sich jedoch in der Sprachunterstützung, dem State-Management und der Ökosystemreife. Dieser Vergleich behandelt die technischen Kompromisse, Codebeispiele in TypeScript und HCL sowie die Interviewfragen, die bei der Diskussion von IaC-Entscheidungen aufkommen. > **Versionskontext: September 2026** > > Dieser Vergleich verwendet Pulumi v3.263.0 (veröffentlicht am 15. September 2026) und Terraform 1.16.3 (veröffentlicht am 26. August 2026). CDKTF, HashiCorps TypeScript-Schicht für Terraform, wurde im Dezember 2025 eingestellt und ist archiviert. ## Kernarchitektur: Pulumis Engine vs Terraforms Plan-Apply-Zyklus Terraform verwendet eine domänenspezifische Sprache (HCL) und einen zweiphasigen Workflow: `terraform plan` generiert einen Ausführungsplan, `terraform apply` führt ihn aus. Die State-Datei verfolgt Ressourcen-Metadaten und wird lokal oder in Remote-Backends wie S3 oder Terraform Cloud gespeichert. Pulumi bettet seine Engine in allgemeine Laufzeitumgebungen ein. Programme in TypeScript, Python, Go oder C# werden direkt über Pulumis Provider gegen Cloud-APIs ausgeführt. Der State wird standardmäßig in Pulumi Cloud gespeichert, mit Optionen für selbstverwaltete Backends einschließlich S3, Azure Blob Storage und lokale Dateien. Der architektonische Unterschied zeigt sich sofort in der Handhabung von Schleifen, Bedingungen und Abstraktionen. Terraforms `for_each` und `count` arbeiten innerhalb der Beschränkungen von HCL. Pulumi-Programme verwenden native Sprachkonstrukte: `for...of` in TypeScript, List Comprehensions in Python, `range` in Go. ```typescript // infra/index.ts - Pulumi TypeScript example import * as aws from "@pulumi/aws"; import * as pulumi from "@pulumi/pulumi"; // Native TypeScript array methods work directly const environments = ["dev", "staging", "prod"]; const buckets = environments.map(env => new aws.s3.BucketV2(`data-${env}`, { bucket: `myapp-data-${env}-${pulumi.getStack()}`, tags: { Environment: env, ManagedBy: "pulumi", }, }) ); // Export bucket ARNs as stack outputs export const bucketArns = buckets.map(b => b.arn); ``` Die äquivalente Terraform-Konfiguration erfordert HCL-Syntax für die Iteration: ```hcl # main.tf - Terraform HCL example variable "environments" { type = list(string) default = ["dev", "staging", "prod"] } resource "aws_s3_bucket" "data" { for_each = toset(var.environments) bucket = "myapp-data-${each.key}-${terraform.workspace}" tags = { Environment = each.key ManagedBy = "terraform" } } output "bucket_arns" { value = [for b in aws_s3_bucket.data : b.arn] } ``` Beide Snippets erstellen drei S3-Buckets. Die Terraform-Version ist prägnant und lesbar für jeden, der mit HCL vertraut ist. Die Pulumi-Version verwendet Standard-TypeScript, was IDE-Autovervollständigung, Typprüfung und Integration mit bestehenden Codebasen ohne das Erlernen einer neuen Sprache bedeutet. ## TypeScript-Unterstützung: Native Sprache vs CDKTF (Eingestellt) Pulumi unterstützt TypeScript seit der ersten öffentlichen Veröffentlichung. Das SDK stellt typisierte Ressourcenklassen bereit, und `pulumi.Output` umhüllt asynchrone Werte, die während der Bereitstellung aufgelöst werden. Refactoring-Tools, Linter und Test-Frameworks aus dem TypeScript-Ökosystem sind direkt anwendbar. Terraforms Antwort auf die Unterstützung von Allzwecksprachen war [CDKTF (Cloud Development Kit for Terraform)](https://developer.hashicorp.com/terraform/cdktf). CDKTF ermöglichte Teams, TypeScript oder Python zu schreiben, das zu Terraform JSON kompiliert wurde. HashiCorp stellte CDKTF im Dezember 2025 ein und archivierte das Repository. Bestehende CDKTF-Projekte laufen weiterhin, aber es werden keine Updates für neue Terraform-Versionen oder Provider-Änderungen geliefert. Für Teams, die TypeScript-IaC im Jahr 2026 wollen, ist Pulumi die aktiv gewartete Option. Teams, die bereits in CDKTF investiert haben, können ihre Stacks weiter betreiben, aber die Migration zu HCL oder Pulumi ist der Weg nach vorne für neue Entwicklungen. ```typescript // infra/vpc.ts - Pulumi component for reusable VPC abstraction import * as aws from "@pulumi/aws"; import * as pulumi from "@pulumi/pulumi"; // Custom component encapsulating VPC, subnets, and routing export class StandardVpc extends pulumi.ComponentResource { public readonly vpcId: pulumi.Output; public readonly publicSubnetIds: pulumi.Output[]; constructor(name: string, args: { cidr: string; azCount: number }, opts?: pulumi.ComponentResourceOptions) { super("mycompany:network:StandardVpc", name, {}, opts); const vpc = new aws.ec2.Vpc(`${name}-vpc`, { cidrBlock: args.cidr, enableDnsHostnames: true, tags: { Name: name }, }, { parent: this }); this.vpcId = vpc.id; // Create public subnets across availability zones const azs = aws.getAvailabilityZones({ state: "available" }); this.publicSubnetIds = []; for (let i = 0; i < args.azCount; i++) { const subnet = new aws.ec2.Subnet(`${name}-public-${i}`, { vpcId: vpc.id, cidrBlock: `10.0.${i}.0/24`, availabilityZone: azs.then(az => az.names[i]), mapPublicIpOnLaunch: true, tags: { Name: `${name}-public-${i}` }, }, { parent: this }); this.publicSubnetIds.push(subnet.id); } this.registerOutputs({ vpcId: this.vpcId }); } } ``` Diese Pulumi-Komponente erstellt eine wiederverwendbare VPC-Abstraktion. Verbraucher instanziieren sie mit `new StandardVpc("prod", { cidr: "10.0.0.0/16", azCount: 3 })`. Das Äquivalent in Terraform ist ein Modulverzeichnis mit Variablen, Outputs und HCL-Dateien. Beide Ansätze ermöglichen Wiederverwendung; die Pulumi-Version erbt TypeScripts Tooling für Dokumentation, Tests und Versionierung. ## State-Management und Backend-Optionen State-Management ist der Bereich, in dem operationelle Unterschiede auftreten. Der Terraform-State enthält Ressourcen-IDs, Provider-Metadaten und sensible Werte. Teams müssen Remote-Backends konfigurieren, um Zusammenarbeit zu ermöglichen, und Locking implementieren, um gleichzeitige Änderungen zu verhindern. [Terraform Backend-Konfiguration](https://developer.hashicorp.com/terraform/language/settings/backends/configuration) unterstützt S3, Azure Blob, Google Cloud Storage, Terraform Cloud und andere. Jedes Backend erfordert seine eigene Authentifizierungseinrichtung. State-Locking verwendet DynamoDB für S3-Backends, Blob-Leases für Azure oder natives Locking in Terraform Cloud. Pulumi Cloud handhabt State-Speicherung, Locking und History standardmäßig. Teams erstellen ein kostenloses Konto, führen `pulumi login` aus, und das State-Management ist konfiguriert. Für Teams, die selbstverwalteten State benötigen, unterstützt Pulumi S3, Azure Blob, GCS und lokale Datei-Backends mit dem `pulumi login`-Befehl. ```bash # Pulumi: login to self-managed S3 backend pulumi login s3://my-pulumi-state-bucket # Terraform: configure S3 backend in HCL # backend.tf terraform { backend "s3" { bucket = "my-terraform-state" key = "prod/terraform.tfstate" region = "us-east-1" dynamodb_table = "terraform-locks" encrypt = true } } ``` Pulumi Cloud bietet eine Web-UI für Stack-History, Ressourcenvisualisierung und Team-Berechtigungen. Terraform Cloud bietet ähnliche Funktionen mit Policy-Enforcement durch Sentinel. Selbst gehostete Optionen existieren für beide: Pulumis selbst gehostetes Backend und Terraform Enterprise. ## Provider-Ökosystem und Multi-Cloud-Unterstützung Terraforms Provider-Ökosystem ist das größte in IaC. Die [Terraform Registry](https://registry.terraform.io/) listet über 4.000 Provider für AWS, Azure, GCP, Kubernetes und Hunderte von SaaS-Plattformen. Die Provider-Qualität variiert: Offizielle HashiCorp- und Cloud-Vendor-Provider erhalten regelmäßige Updates, während Community-Provider möglicherweise hinter API-Änderungen zurückbleiben. Pulumi-Provider umhüllen Terraform-Provider mittels einer Bridge, die typisierte SDKs generiert. Die [Pulumi Registry](https://www.pulumi.com/registry/) stellt Provider für große Clouds, Kubernetes, Datenbanken und Monitoring-Dienste bereit. Da Pulumi Terraform-Provider bridged, ist die Ökosystemabdeckung vergleichbar, obwohl neue Terraform-Provider-Versionen Bridge-Updates erfordern, bevor Pulumi-SDKs Änderungen reflektieren. Pulumi bietet auch native Provider, die direkt gegen Cloud-APIs geschrieben sind. Native Provider für AWS, Azure und Kubernetes liefern Same-Day-Support für neue API-Features. Der Kompromiss ist, dass native Provider nur für große Clouds existieren; weniger verbreitete Dienste verwenden gebridgte Provider. ```typescript // Using Pulumi's native AWS provider for Lambda import * as aws from "@pulumi/aws"; import * as pulumi from "@pulumi/pulumi"; const role = new aws.iam.Role("lambda-role", { assumeRolePolicy: aws.iam.assumeRolePolicyForPrincipal({ Service: "lambda.amazonaws.com", }), }); const lambdaFunction = new aws.lambda.Function("api-handler", { runtime: aws.lambda.Runtime.NodeJS20dX, handler: "index.handler", role: role.arn, code: new pulumi.asset.AssetArchive({ "index.js": new pulumi.asset.StringAsset( `exports.handler = async () => ({ statusCode: 200, body: "OK" });` ), }), }); export const functionArn = lambdaFunction.arn; ``` ## Infrastructure-Code testen Beim Testen zeigt sich der Unterschied der Sprachwahl deutlich. Pulumi-Programme sind Standardcode, sodass Unit-Tests bekannte Frameworks verwenden. Das `@pulumi/pulumi/runtime`-Modul stellt Mocking für Ressourcenerstellung bereit, sodass Tests die Konfiguration ohne Bereitstellung von Ressourcen verifizieren können. ```typescript // __tests__/infra.test.ts - Unit testing Pulumi resources with Vitest import { describe, it, expect, beforeAll } from "vitest"; import * as pulumi from "@pulumi/pulumi"; // Mock Pulumi runtime pulumi.runtime.setMocks({ newResource: (args: pulumi.runtime.MockResourceArgs) => { return { id: `${args.name}-id`, state: args.inputs }; }, call: (args: pulumi.runtime.MockCallArgs) => { return args.inputs; }, }); describe("S3 Bucket Configuration", () => { let bucketTags: Record; beforeAll(async () => { // Import the Pulumi program after mocks are set const infra = await import("../infra/index"); // Extract outputs for testing bucketTags = await new Promise(resolve => { infra.buckets[0].tags.apply(tags => resolve(tags as Record)); }); }); it("should tag buckets with Environment", () => { expect(bucketTags).toHaveProperty("Environment"); }); it("should tag buckets with ManagedBy", () => { expect(bucketTags.ManagedBy).toBe("pulumi"); }); }); ``` Terraform-Tests verwenden `terraform test` (eingeführt in Terraform 1.6) oder externe Tools wie Terratest. `terraform test` führt HCL-Testdateien aus, die echte Ressourcen in isolierten Konfigurationen erstellen. Terratest ist eine Go-Bibliothek, die Terraform-Befehle umhüllt und Assertions bereitstellt. ```hcl # tests/bucket.tftest.hcl - Terraform native test run "bucket_tags" { command = plan assert { condition = aws_s3_bucket.data["dev"].tags["Environment"] == "dev" error_message = "Bucket must be tagged with Environment" } assert { condition = aws_s3_bucket.data["dev"].tags["ManagedBy"] == "terraform" error_message = "Bucket must be tagged with ManagedBy" } } ``` Beide Ansätze validieren die Infrastrukturkonfiguration. Pulumis Vorteil ist die Integration mit TypeScript-Test-Runnern und Coverage-Tools. Terraforms native Tests laufen ohne externe Abhängigkeiten, erfordern aber HCL-Syntax. ## Interviewfragen: Pulumi vs Terraform DevOps-Interviews im Jahr 2026 beinhalten häufig IaC-Tool-Vergleiche. Hier sind Fragen, die Kandidaten unterscheiden, die beide Tools in der Produktion verwendet haben. **"Was passiert, wenn der Terraform-State von der tatsächlichen Infrastruktur abweicht?"** Erwartete Antwort: `terraform plan` erkennt Drift durch Vergleich des States mit der realen Infrastruktur. Der Plan zeigt Ressourcen zum Aktualisieren, Erstellen oder Löschen. Drift tritt auf, wenn Änderungen außerhalb von Terraform vorgenommen werden (Konsole, CLI, andere Tools). Optionen umfassen `terraform refresh` zum Aktualisieren des States, `terraform import` zum Einbringen von Ressourcen unter Management oder das Akzeptieren des Plans zur Wiederherstellung des gewünschten Zustands. **"Wie handhabt Pulumi Secrets anders als Terraform?"** Erwartete Antwort: Pulumi verschlüsselt Secrets im State standardmäßig mit einer Passphrase oder Cloud-KMS. Die `pulumi.secret()`-Funktion markiert Werte als sensibel, und sie bleiben im Ruhezustand verschlüsselt. Terraform speichert Secrets im Klartext in State-Dateien; Teams verlassen sich auf Backend-Verschlüsselung (S3-serverseitige Verschlüsselung) und Zugriffskontrollen. Terraform 1.4 fügte `sensitive`-Variablenmarkierung hinzu, aber Werte erscheinen weiterhin unverschlüsselt im State. **"Warum hat HashiCorp CDKTF eingestellt, und welche Migrationsoptionen gibt es?"** Erwartete Antwort: CDKTF verursachte Wartungsaufwand, ohne mit Terraforms Update-Kadenz Schritt zu halten. Neue Provider-Versionen und Terraform-Features erforderten manuelle Updates der CDK-Bindungen. HashiCorp entschied sich, sich auf HCL und Terraform Cloud zu konzentrieren. Migrationsoptionen sind: Konvertierung zu HCL mit `cdktf convert`, Neuschreiben in Pulumi, wenn TypeScript erforderlich ist, oder Weiterbetrieb bestehender CDKTF-Stacks ohne Updates. **"Wann würde man Pulumi gegenüber Terraform für ein neues Projekt wählen?"** Erwartete Antwort: Pulumi wählen, wenn das Team bereits TypeScript/Python/Go verwendet und IaC in derselben Sprache wie den Anwendungscode möchte, wenn komplexe Abstraktionen echte Programmierkonstrukte erfordern (Generics, Interfaces, Test-Frameworks) oder wenn integrierte Secret-Verschlüsselung eine Anforderung ist. Terraform wählen, wenn das Team HCL kennt, wenn das Provider-Ökosystem Nischen- oder Community-Provider enthalten muss oder wenn organisatorisches Tooling (Atlantis, Spacelift) mit Terraform integriert ist. ## Migrationsstrategien: Terraform zu Pulumi Pulumi bietet `pulumi import`, um bestehende Cloud-Ressourcen unter Management zu bringen, ohne sie neu zu erstellen. Für Teams mit Terraform-State übersetzt `pulumi convert` HCL in Pulumi-Programme. Die Konvertierung ist nicht perfekt: Komplexe Module und dynamische Blöcke erfordern manuelle Anpassung. ```bash # Convert Terraform HCL to Pulumi TypeScript pulumi convert --from terraform --language typescript # Import existing AWS resources into Pulumi state pulumi import aws:s3/bucketV2:BucketV2 my-bucket my-existing-bucket-name ``` Eine phasenweise Migration ermöglicht Teams, beide Tools während des Übergangs zu betreiben. Terraform verwaltet bestehende Stacks, während Pulumi neue Infrastruktur provisioniert. Sobald Teams Pulumi-Erfahrung gesammelt haben, konvertieren sie Terraform-Stacks inkrementell. Der State wird nicht zwischen Tools geteilt, sodass die Ressourcenverwaltung klar aufgeteilt werden muss, um Konflikte zu vermeiden. ## Entscheidungsrahmen für 2026 | Faktor | Terraform | Pulumi | |--------|-----------|--------| | Sprache | HCL (DSL) | TypeScript, Python, Go, C#, Java, YAML | | State-Management | Selbstverwaltet oder Terraform Cloud | Pulumi Cloud (Standard) oder selbstverwaltet | | Secret-Behandlung | Klartext im State, Backend-Verschlüsselung | Standardmäßig verschlüsselt | | Testing | `terraform test`, Terratest | Native Sprach-Test-Frameworks | | Provider-Abdeckung | 4.000+ in der Registry | Bridged Terraform-Provider + native SDKs | | TypeScript-Unterstützung | CDKTF (eingestellt Dezember 2025) | Erstklassig, aktiv gewartet | | Lernkurve | HCL ist zweckgebunden, schnell für IaC | Erfordert bestehendes Sprachwissen | | Enterprise-Features | Terraform Cloud/Enterprise | Pulumi Cloud/selbst gehostet | > **Interview-Tipp** > > Wenn nach Pulumi vs Terraform gefragt wird, sollte man vermeiden zu sagen, eines sei "besser". Stattdessen sollten Kompromisse artikuliert werden: Terraform hat ein größeres Ökosystem und HCLs Beschränkungen verhindern Laufzeitfehler; Pulumi bietet echte Sprachfeatures und typisierte SDKs. Es sollte deutlich werden, dass die Wahl von Team-Skills, bestehendem Tooling und Projektanforderungen abhängt. ## Wichtigste Erkenntnisse für Infrastructure as Code 2026 - Terraform 1.16 ist die stabile Wahl für HCL-basiertes IaC mit dem größten Provider-Ökosystem und ausgereiftem Tooling (Atlantis, Spacelift, env0). - Pulumi v3.263 bietet TypeScript, Python, Go und C# mit nativen Sprachtests, IDE-Integration und integrierter Secret-Verschlüsselung. - CDKTF ist seit Dezember 2025 eingestellt. Teams, die TypeScript-IaC wollen, sollten Pulumi evaluieren, anstatt neue CDKTF-Projekte zu starten. - Beide Tools unterstützen Multi-Cloud-Deployments, Remote-State-Backends und Team-Zusammenarbeit. Die Wahl hängt von Sprachpräferenz und bestehender Team-Expertise ab. - Interview-Diskussionen sollten Verständnis für State-Management, Drift-Erkennung, Provider-Ökosysteme und die Kompromisse zwischen DSL-Einfachheit und Allzwecksprachen-Power demonstrieren. - Migration von Terraform zu Pulumi ist mit `pulumi convert` und `pulumi import` möglich, erfordert aber sorgfältige Planung und schrittweises Rollout. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/de/blog/devops/pulumi-vs-terraform-2026-infrastructure-as-code-typescript-interview-questions