Terraform vs Pulumi: A Governance Model That Won't Slow You Down

Terraform uses its own declarative language, HCL, and a large, mature provider ecosystem; almost anything you'd provision already has a Terraform provider. Pulumi lets you write infrastructure in TypeScript, Python, Go, or another general-purpose language, so you get real loops, conditionals, and unit tests instead of HCL's more limited expressions.

If your platform team already lives in TypeScript, Pulumi cuts the context switch. If your infrastructure is mostly standard cloud resources with little custom logic, HCL's constraints rarely bite, and Terraform's larger community means more prior art for edge cases. Neither tool changes your governance obligations: state locking, plan review, and policy checks are still your job either way.

Say your team runs $40,000 a month in cloud spend and nobody's audited what's attached to a Terraform or Pulumi stack in the last two quarters. That's a common setup for waste: a staging cluster a deprecated module never tore down, a load balancer created by hand during an incident and never imported into state, three near-identical VPC modules because nobody wanted to touch the one already in prod.

None of it shows up as a single line item. It surfaces only when someone finally runs a drift-detection pass against the live account and finds a cloud bill much higher than the workload actually needs.

• Inventory first. Run `terraform plan` (or `pulumi preview`) against every stack and list anything showing unexpected drift before you write a single policy.
• Pick a policy engine that matches your tool: Open Policy Agent or Conftest for either, Sentinel if you're on Terraform Cloud, or Pulumi's own CrossGuard for Pulumi stacks.
• Ship policies in warn-only mode for two to three weeks. Log every violation without blocking a merge, and use that log to find rules too strict for how your team actually works.
• Flip to blocking, one policy at a time, starting with the highest-risk category: public security groups, unencrypted storage, IAM roles with wildcard permissions.

DORA groups engineering orgs into four performance clusters by deployment frequency: the top cluster ships on demand, while low performers can go up to 180 days between releases¹. A governance layer that adds a manual approval step to every infrastructure change is a fast way to drift toward that low end.

The fix isn't skipping review, it's moving the review earlier: catch a bad security group in a policy check that runs in seconds during CI, not in a human approval queue that runs once a week.

• Writing one global policy set for every environment, so a rule tuned for production blocks a throwaway sandbox stack.
• Locking down apply access before anyone has mapped which resources are actually safe to change without review.
• Skipping an exception path, so an on-call engineer fixing a live incident has no way to bypass a policy check that's correctly blocking a routine change but wrongly blocking an emergency one.
• Buying a policy engine before writing a single rule by hand, so nobody on the team actually understands what the tool is enforcing when it eventually blocks something during an incident.

The policies that survive past the first quarter tend to be the small set that map directly to something that already caused an incident: a public bucket, an overly permissive IAM role, a security group open to the world. Teams that start instead with a large, generic ruleset borrowed from a compliance framework tend to either abandon it under noise or leave it in warn-only mode indefinitely because nobody has the time to review the backlog of violations.

A useful signpost that governance is working: the policy engine's blocked-attempt log is short and each entry is something an engineer recognizes as a real near-miss, not a wall of false positives nobody reads. If the log is long and nobody reads it, the rules need tuning before they need enforcing more strictly.