Technical Deep-Dive: Building "Golden Path" Modules with Terraform and OPA

Infrastructure as Code (IaC) at Scale, specifically moving from "copy-paste" Terraform to a Modular, Policy-Driven Architecture.

In my previous post, I mentioned that Senior DevOps Engineers build guardrails, not gates. Today, I want to show you exactly what that looks like in a Terraform repository.

When you have 50+ developers, you cannot manually review every S3 bucket or RDS instance. You need a system that is secure by default and automatically enforced.

1. The "Golden Path" Module Pattern
   Instead of letting developers use the raw aws_s3_bucket resource, we provide a "Golden Path" module. This module encapsulates our company's security standards (encryption, versioning, public access blocks) so the developer doesn't have to think about them.
   The "Senior" Module Structure:
   # modules/secure-s3/main.tf

resource "aws_s3_bucket" "this" {

bucket = var.bucket_name

# Hardcoded security—developers can't override these to be 'false'

}

resource "aws_s3_bucket_public_access_block" "this" {

bucket = aws_s3_bucket.this.id

block_public_acls = true

block_public_policy = true

ignore_public_acls = true

restrict_public_buckets = true

}

resource "aws_s3_bucket_server_side_encryption_configuration" "this" {

bucket = aws_s3_bucket.this.id

rule {

apply_server_side_encryption_by_default {

sse_algorithm = "AES256"

}

}

}

1. Policy as Code (The Guardrail)
   Even with modules, someone might try to bypass them or use a raw resource. This is where Open Policy Agent (OPA) or Terraform Cloud Sentinel comes in.
   We treat our infrastructure requirements like unit tests. Here is a simple Rego policy that fails any plan containing an S3 bucket with public read access:
   package terraform.policies

deny[msg] {

resource := input.resource_changes[_]

resource.type == "aws_s3_bucket"

resource.change.after.acl == "public-read"

msg = sprintf("Resource %v has a public-read ACL. This is forbidden.", [resource.address])

}

1. Implementing the "Promotion" Workflow
   A junior engineer pushes to main and runs terraform apply. A senior engineer designs a promotion pipeline that mimics the software development lifecycle.
   | Stage | Action | Validation |
   |---|---|---|
   | Commit | tflint & terraform fmt | Syntax and linting check |
   | Plan | terraform plan | OPA Policy check (Security) |
   | Staging | terraform apply | Integration testing (Infracost) |
   | Production | Manual Gate / Promotion | Final sanity check |


2. Handling State at Scale
   Stop using local state or individual S3 backends for every project. As a senior, you should be implementing:
   
   
   
   
   • Remote State Management: Centralized in Terraform Cloud, Spacelift, or an enterprise-grade S3/DynamoDB setup.
   
   
   • State Locking: To prevent two engineers from corrupting the environment simultaneously.
   
   
   • Decoupling: Breaking large state files into smaller, environment-specific stacks to reduce the "blast radius" of a failed apply.
     The Takeaway
     Seniority is about reducing cognitive load for your teammates. By providing pre-hardened modules and automated policy checks, you allow your developers to move at 100mph without the risk of a data breach.
     What does your "Golden Path" look like? Do you prefer OPA, Terragrunt, or native Terraform modules? Let’s swap notes below.