When I decided to build my own site, I knew I wanted something fast, scalable, and modern — not just in terms of the tech stack, but also in the way it’s managed and deployed. This post walks you through exactly how my site (Cloudy Mountains) is deployed using Hugo, AWS (S3 + CloudFront), Terraform, GitHub Actions, and OIDC authentication. I’ll show you the challenges that I had and how to solve them properly.

As I mentioned in my previous blog post, my first OPA policy was just to catch one simple parameter, if we have in the S3 Terrafom module set the force_destroy = true.

Here’s a simple OPA policy that will catch this dangerous configuration:

package terraform.plan

deny[msg] {
    # Find all resources in the plan
    resource := input.resource_changes[_]
    
    # Check if it's an S3 bucket
    resource.type == "aws_s3_bucket"
    
    # Look for force_destroy in the configuration
    resource.change.after.force_destroy == true
    
    msg := sprintf("S3 bucket '%s' has force_destroy set to true. This is dangerous as it allows bucket deletion even when not empty.", [resource.address])
}

This policy works by:

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.