Guardrails: prevent_destroy, Preconditions, and check Blocks

1. 1

   Protect the database from Terraform itself

   Add prevent_destroy to the DB instance's lifecycle. It has to be a literal, so this applies to dev too. That's deliberate friction: to tear down dev you'll consciously remove the line first (see Clean up), and that removal shows up in review.

   Add inside resource "aws_db_instance" "main".

     lifecycle {
       prevent_destroy = true
   
       precondition {
         condition     = var.environment != "prod" || var.db_multi_az
         error_message = "Production databases must be Multi-AZ (set db_multi_az = true)."
       }
   
       precondition {
         condition     = var.environment != "prod" || !startswith(var.db_instance_class, "db.t")
         error_message = "Burstable (db.t*) instance classes aren't allowed in prod."
       }
     }

2. 2

   Verify an assumption about a data source

   The probe's AMI lookup filters by name. If Amazon ever changed naming and the filter matched an x86 image, an ARM t4g instance would fail to launch with a confusing error. A postcondition turns that into a clear message at plan time.

   Add inside data "aws_ami" "al2023_arm".

     lifecycle {
       postcondition {
         condition     = self.architecture == "arm64"
         error_message = "AMI lookup returned ${self.id} (${self.architecture}); expected an arm64 image for t4g instances."
       }
     }

3. 3

   Add a live health check

   The http provider can make requests from within a check block. Add http = { source = "hashicorp/http", version = "~> 3.4" } to required_providers and run terraform init. The check calls the database health endpoint through the public URL, which covers the ALB, ECS, the app, secrets, and RDS in one request.

   check "api_health" {
     data "http" "db_health" {
       url = "http://${aws_lb.main.dns_name}/healthz/db"
   
       retry {
         attempts = 3
       }
     }
   
     assert {
       condition     = data.http.db_health.status_code == 200
       error_message = "ShopLite /healthz/db returned ${data.http.db_health.status_code}: ${data.http.db_health.response_body}"
     }
   }

   terminalcopy cmd

   $ terraform init -upgrade >/dev/null && terraform apply

   ── expected output ──

   ...

   Plan: 0 to add, 0 to change, 0 to destroy.

   ...

   Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

4. 4

   Rebuild something on purpose with -replace

   Occasionally a resource is broken in a way Terraform can't see, such as a corrupted instance or a stuck task definition. -replace=ADDRESS plans a replacement of exactly that resource. It's the modern substitute for the old terraform taint. Try it on the probe; it's safe.

   terminalcopy cmd

   $ terraform apply -var enable_probe=true -auto-approve >/dev/null

   terraform plan -var enable_probe=true -replace='aws_instance.probe[0]'

   ── expected output ──

   # aws_instance.probe[0] will be replaced, as requested

   -/+ resource "aws_instance" "probe" {

   ...

   Plan: 1 to add, 0 to change, 1 to destroy.

Make each change, run the command, and read the error before revealing the diagnosis. Recognising these messages on sight is what makes you fast on a real team. Undo the change afterwards.