Terraform vs. Pulumi: Building Real Governance Into Your IaC

Terraform's state file is the ground truth for what it thinks exists, and if two engineers run apply against the same workspace without a remote backend that locks state, you get a corrupted or conflicting state file. Pulumi has the same problem with its own state backend. Neither tool fixes this by default. The fix is the same for both: a remote backend (S3 with DynamoDB locking, Terraform Cloud, or Pulumi's managed service) so applies queue instead of racing. Drift, someone changing a resource by hand in the console, is the other failure mode, and both tools need a scheduled plan-only run that alerts on any diff, not just a manual check before the next deploy.

Terraform's policy layer is bolted on: Sentinel if you're on Terraform Cloud/Enterprise, or Open Policy Agent's Rego language if you're running open source with a tool like Conftest. Pulumi's CrossGuard runs policy checks in the same general-purpose language (TypeScript, Python, Go) as your infrastructure code, so a rule like "no public S3 buckets" or "every resource needs a cost-center tag" reads like a unit test instead of a separate DSL. If your engineers already write policy exceptions in code review comments instead of enforced checks, that's the gap. The choice between Rego and a general-purpose language is really a choice about who's writing the policies: a dedicated platform team can learn Rego; a smaller team reuses skills it already has in CrossGuard.

Both tools support reusable modules or components, and both let any engineer publish one without review unless you set up a registry with an approval step. The governance question isn't whether modules exist, it's whether a module that provisions a database or opens a security group has been reviewed once, centrally, instead of copy-pasted and modified twenty times across repos. A private registry (Terraform's or Pulumi's) with a required review on new module versions turns "everyone reinvents the VPC module" into "everyone imports the same reviewed one."

For example, if three teams each copy and modify a VPC module, a security fix made in one copy never reaches the others. Publish one reviewed VPC module in a private registry, require review on every new version, and have teams import it instead of copying it. When the security team later tightens ingress rules, that change ships once, passes through the same approval step as everything else, and appears in every team's next plan as a visible diff. The common mistake is setting up the registry but leaving publishing open to everyone, which recreates the sprawl with extra steps.

Federal binding operational directives put a hard clock on remediating known, internet-facing vulnerabilities once they're detected¹, and the same discipline applies to infrastructure drift: if a plan shows an unapproved change, treat it the way you'd treat an unpatched CVE, on a clock, not a backlog. Compliance platforms like Vanta and Drata can pull evidence directly from your CI pipeline, the plan output, the approval, the apply log, instead of an engineer manually screenshotting a console for an auditor. That only works if your pipeline actually gates on a human approval step; if applies run unattended on merge, there's no evidence to collect.

Regardless of which tool you use: require a plan on every pull request with the diff visible to the reviewer, require a second approver before apply on production workspaces, lock state with a remote backend, run policy checks in CI before the plan is even shown for review, and schedule a nightly drift check that pages someone instead of waiting for the next deploy to surface it. None of this depends on Terraform versus Pulumi specifically. It depends on treating infrastructure changes with the same review discipline as application code, not a faster, looser path around it.

The same baseline as a checklist you can adopt this week:

• Require a plan on every pull request, with the diff visible to the reviewer.
• Require a second approver before apply on production workspaces.
• Lock state with a remote backend so applies queue instead of racing.
• Run policy checks in CI before the plan is even shown for review.
• Schedule a nightly drift check that pages someone instead of waiting for the next deploy to surface a diff.