How I Learned the Hard Way That Terraform Needs Policy as Code

By [Denislav Tsonev] on March 30, 2025. Reading time: 3 minutes and 14 seconds.

A few years ago, while working for a cloud consultancy company, I made a mistake that I will never forget. It was the kind of mistake that keeps DevOps engineers up at night. I accidentally deleted a Terraform state bucket—an S3 bucket that stored the state for bootstrapping 15 AWS accounts, each packed with resources. To make things worse, this wasn’t just any bucket—it belonged to a very tough client.

If you’ve ever worked with Terraform, you know how critical the state file is. Losing it meant that Terraform had no way of knowing what was already deployed. It was a disaster. The moment I realized what had happened, my mind started racing through possible solutions. I considered manually importing all the resources back into the Terraform state. We even contacted AWS Support just to ask if it was possible to restore the bucket—grasping at all sorts of insane solutions. But ultimately, the only real option was to inform the client.

Fortunately, the 15 accounts were brand new, as we were in the process of building their environment in AWS, and there were no “live” workloads yet. After some tense discussions with a very pushy client, we decided to start over—creating 15 new accounts and provisioning everything again from scratch.

The Wake-Up Call

That incident made me realize that Infrastructure as Code (IaC) alone wasn’t enough—I needed a way to enforce policies that could catch dangerous configurations before they were applied. At the time, Terraform was still in its early stages, around versions 0.11 and 0.12, and there weren’t many solutions available to properly validate the plan output. That’s when I started searching for a solution, and I found Open Policy Agent (OPA).

OPA is a policy engine that allows you to define rules to evaluate configurations, and one of its best use cases is analyzing Terraform plans. For example, it can check if an S3 bucket has force_destroy = true before applying changes, preventing accidental deletions like the one I experienced.

When we started, our IaC code was not very complicated—just a series of Terraform module invocations without any nested structures. Back then, it was relatively easy to spot such misconfigurations in the variables files. But as our deployments grew more complex, with nested module invocations and autogenerated tfvars files, it became much harder to detect these issues manually. We needed a secure and automated way to catch such dangerous actions early in our CI/CD process.

Why Policy as Code Matters

Terraform is a powerful tool, but with great power comes great responsibility. Without guardrails, it’s easy to misconfigure resources, expose sensitive data, or delete critical infrastructure. Policy as Code, using tools like OPA, provides a safety net by programmatically enforcing best practices.

With OPA, you can:

Prevent accidental deletions of critical resources.

Enforce security best practices, like ensuring all S3 buckets have encryption enabled.

Restrict which AWS regions can be used.

Ensure tagging standards for better resource tracking.

What’s Next

In this blog series, I’ll dive into how OPA can be integrated with Terraform to enforce policies and prevent costly mistakes. Next, we’ll explore how OPA works and how to get started with writing policies for Terraform.

Stay tuned, and in the meantime, learn from my mistake—don’t rely on manual checks when automation can save you from disaster.