Pulumi lets you define infrastructure in TypeScript, Python, Go or C#, while Terraform uses HCL. What do you actually gain, and what do you give up, by choosing a general-purpose language?

## The two shapes Terraform configuration is a declarative document: you write HCL blocks, the tool builds a graph from them, diffs that desired state against what it has recorded, and calls providers. Pulumi is a program: your `main` runs, each resource constructor you call registers a resource with the Pulumi engine, and the engine then does the same diff-and-call. The end state is identical — a graph of provider-managed resources — but one is produced by parsing a document and the other by executing code. That single difference is the whole interview question. Everything below follows from it. ## What you actually gain **Control flow that is just control flow.** A `for` loop, an `if`, a `map`, a helper function. In HCL the same intent goes through `count`, `for_each`, `for` expressions and `dynamic` blocks, which are capable but are a second language you learn on top of the first. Deeply conditional shapes — this subnet layout for regions with three AZs, that one otherwise — read naturally as code. **Static types and tooling.** Resource arguments are typed, so a misspelled property is a red squiggle in the editor rather than an error surfaced when you run a plan. Go-to-definition lands in the provider SDK. Rename and find-usages work. On a large estate this is a real productivity difference, not a cosmetic one. **Abstraction with normal packaging.** Reusable pieces are classes and packages published to npm, PyPI or a Go module proxy, versioned by the same tooling your applications use, with interfaces expressing the contract. You can share a type between the infrastructure and the service that consumes it. **Genuine unit tests.** Because it is a program, you can run it in-process with the providers mocked and assert on the properties the program would submit — in Jest, pytest or `go test`, in milliseconds, with no cloud account. That is a different level from lint-and-validate. ```typescript import * as aws from "@pulumi/aws"; for (const env of ["dev", "staging", "prod"]) { const bucket = new aws.s3.BucketV2(`logs-${env}`, { tags: { Environment: env } }); if (env === "prod") { new aws.s3.BucketVersioningV2(`logs-${env}-versioning`, { bucket: bucket.id, versioningConfiguration: { status: "Enabled" }, }); } } ``` ## What you give up **Reviewability.** This is the honest cost. A change to an HCL file usually tells the reviewer what infrastructure changes. A change to a program tells the reviewer what the *logic* is now; deriving the infrastructure requires running a preview and reading its output. Teams that adopt Pulumi seriously post the preview into the pull request for exactly this reason. **Blast radius of cleverness.** A helper that loops over a list fetched at runtime can create or destroy resources based on data that appears nowhere in the diff. Programs can be non-deterministic — a timestamp, a random value, a network call — which a declarative document mostly cannot be. The discipline that HCL imposes by having no escape hatch, you must impose on yourself. **Onboarding and audience.** HCL is deliberately small; a network engineer or an SRE who does not write TypeScript can still read and review it. Pulumi asks the reader to know the cloud *and* the language *and* the codebase's own abstractions. **Ecosystem gravity.** Examples, blog answers, the public module registry and most static scanners target HCL and template files first, because scanning an arbitrary program is a much harder problem than scanning a document. Pulumi has its own policy tooling, but the third-party surface is thinner. ## What does not change Both tools drive the same provider ecosystem, both record what they manage, both preview before they mutate, both suffer drift when someone edits the console, and both can destroy a database if the diff says replace and nobody read it. Choosing Pulumi does not delete any of those problems; it changes the language you express the solution in. ## Taking a position Interviewers are testing whether you have one, so give it with a criterion attached. Mine: ask whether the infrastructure is *logic* or a *catalogue*. A broad, shallow estate — many similar accounts and services, reviewed by a large mixed-skill group, already sitting on a library of modules — is better in HCL, and the migration cost buys nothing. Infrastructure with real logic in it (per-tenant stamping, contracts shared with application code, heavy conditionality) owned by application engineers with a testing culture is where a general-purpose language earns its keep. Team fluency dominates: the tool your reviewers can read at 3am is the tool that keeps you safe. And whichever you pick, the guardrails are the same — preview on the pull request, policy checks before apply, and a least-privilege role doing the applying.