Week 20: Advanced Terraform — Testing, Workspaces & Policy as Code

1. Workspaces & Terragrunt

Terraform workspaces let one configuration manage multiple named instances of the same infrastructure, each with its own state file, switched with terraform workspace select. It's built into core Terraform and needs no extra tooling, but it has a sharp edge: workspaces share the exact same .tf files, so any environment-specific difference has to be threaded through variables and terraform.workspace conditionals, which gets messy fast once staging and production genuinely diverge.

terraform workspace new staging
terraform workspace new production

terraform workspace select staging
terraform apply -var-file=staging.tfvars

terraform workspace select production
terraform apply -var-file=production.tfvars

Terragrunt takes a different approach that scales better once you have real per-environment differences: it's a thin wrapper around Terraform that generates backend and provider configuration and lets each environment live in its own directory, each pointing at the same underlying module.

infra/
├── modules/vpc/              # the actual Terraform module, environment-agnostic
├── staging/vpc/terragrunt.hcl
└── production/vpc/terragrunt.hcl

terraform {
  source = "../../modules/vpc"
}

remote_state {
  backend = "s3"
  config = {
    bucket = "acme-tfstate"
    key    = "production/vpc/terraform.tfstate"
    region = "us-east-1"
  }
}

inputs = {
  cidr_block  = "10.1.0.0/16"
  environment = "production"
  instance_count = 3
}

Run terragrunt apply from the production/vpc directory and it generates the backend block, injects the inputs, and calls Terraform against the shared module — the module code itself never needs an if environment == "production" conditional anywhere inside it, because the difference lives entirely in each environment's own small config file.

2. Automated Testing with Terratest

terraform plan tells you what will change; it says nothing about whether the module is actually correct — whether the security group it creates really only opens the ports you intended, or whether the VPC it provisions actually has working internet access. Terratest, a Go library, applies a module against real (throwaway) infrastructure and asserts on the result, then destroys it — an actual integration test, not a static check.

package test

import (
	"testing"
	"github.com/gruntwork-io/terratest/modules/terraform"
	"github.com/stretchr/testify/assert"
)

func TestVpcModule(t *testing.T) {
	opts := &terraform.Options{
		TerraformDir: "../modules/vpc",
		Vars: map[string]interface{}{
			"cidr_block":  "10.99.0.0/16",
			"environment": "test",
		},
	}

	defer terraform.Destroy(t, opts)      // always tears down, even on failure
	terraform.InitAndApply(t, opts)

	vpcId := terraform.Output(t, opts, "vpc_id")
	assert.NotEmpty(t, vpcId)

	subnetCount := terraform.OutputList(t, opts, "public_subnet_ids")
	assert.Len(t, subnetCount, 2)          // module is supposed to create exactly 2
}

defer terraform.Destroy is the line that makes this safe to run repeatedly in CI — it guarantees the throwaway VPC gets torn down even if an assertion fails partway through, so a failing test doesn't leave orphaned billable infrastructure behind. Wiring this into the GitHub Actions pipeline from Week 6 means a pull request that changes a Terraform module gets its actual behavior verified against real cloud resources, not just a syntax check.

3. Policy as Code with OPA/Conftest

Least-privilege IAM from Week 14 relies on someone remembering the rule during code review. Policy as code makes the rule mechanically enforced: the Open Policy Agent (OPA) and its CLI, Conftest, evaluate a Terraform plan's JSON output against rules written in Rego, and can fail a CI job before a non-compliant plan is ever applied.

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket_public_access_block"
  resource.change.after.block_public_acls == false
  msg := sprintf("S3 bucket '%s' must block public ACLs", [resource.address])
}

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_security_group_rule"
  resource.change.after.cidr_blocks[_] == "0.0.0.0/0"
  resource.change.after.from_port == 22
  msg := sprintf("Security group rule '%s' opens SSH to the entire internet", [resource.address])
}

terraform plan -out=tfplan
terraform show -json tfplan > plan.json
conftest test plan.json --policy policy/

# FAIL - main - S3 bucket 'aws_s3_bucket.uploads' must block public ACLs

The second rule is a direct, mechanical version of a habit Week 8 taught by instruction alone — "don't open port 22 to 0.0.0.0/0." Policy as code turns that from a reviewer's memory into something CI enforces on every single plan, for every engineer, without anyone needing to remember to check it by eye. Wired into the same pipeline as Terratest, a PR now fails for either reason: the module doesn't behave correctly, or it behaves correctly but violates an organizational rule.

4. Hands-on Exercise

5. Knowledge Check

Three quick questions. Expand each to check your answer.