Why Did My AI-Generated Terraform Config Almost Delete Production?

Quick answer

• AI-generated Terraform often “works” but omits the guards that prevent destroying real data.
• The three dangerous gaps are missing prevent_destroy, mishandled state files, and blind terraform apply of a plan nobody read.
• Always review the plan line by line and protect data stores before applying anything to a real account.

The pattern behind “almost deleted production”

An AI assistant is very good at producing plausible Terraform: resources, variables, providers — all syntactically valid and often able to run. What it does not reliably produce is the intent that keeps you safe: lifecycle rules that forbid destroying a database, a state file strategy that doesn’t lose track of resources, and the habit of reading a plan before applying it. The config looks complete, but the safety rails are missing.

Missing prevent_destroy

A database or object store should usually carry a guard:

resource "aws_db_instance" "main" {
  # ...
  lifecycle {
    prevent_destroy = true
  }
}

With this, Terraform refuses to destroy the resource, and a destructive plan fails with an error. An AI-generated config frequently omits it, so a small change that forces a replacement quietly destroys the database.

State file mishandling

Terraform tracks resources in a state file. If that file lives only on one laptop, is committed to a public repo, or gets out of sync, the next apply can try to recreate or orphan real resources. The generated config rarely mentions configuring remote state, because state is an operational concern, not part of the resource block.

Blind apply

The single most dangerous habit is running terraform apply -auto-approve on an AI-suggested plan. The plan output is the one place the assistant’s mistakes become visible — a force replacement line, an unexpected deletion. Skipping the read is skipping the safety check.

Where this bites vibecoders

This is the signature vibecoding incident: prompt for a stack, paste the config, apply, and only notice the plan: 3 to add, 1 to destroy line after the destroy. The fix is procedural, not technical: protect data stores, store state safely, and read every plan before applying — the same discipline a human operator brings.

Where AI coding assistants get this wrong

• Omitting prevent_destroy on databases, buckets, and volumes.
• Hardcoding secrets in resource blocks instead of variables.
• Generating configs with no remote-state backend configured.
• Encouraging -auto-approve in suggested commands.

Checklist

• Add prevent_destroy to every data-bearing resource.
• Configure remote state with locking and backups before first apply.
• Read every plan in full, watching for destroy and force replacement.
• Keep secrets in variables or a secret manager, never in resource blocks.
• Apply in a non-production environment first, then promote.

FAQ

What is a Terraform plan?

A plan is Terraform’s preview of what an apply will change: resources to add, change, or destroy. It is computed by comparing the configuration and state against the real environment, and reading it is the primary safety check before any change.

Why does Terraform need a state file?

State records which real resources Terraform manages and their attributes, so the next run knows what to update or destroy instead of creating duplicates. Losing or corrupting state can make Terraform try to recreate existing resources.

How do I undo a bad Terraform apply?

If the change is recent and the state is intact, revert the configuration and apply again, or restore from a state backup. If data was destroyed, recovery depends on backups — which is why prevent_destroy and database backups matter so much. See How to Set Up Automated Database Backups.

Related topics

• What Is Infrastructure as Code (IaC)?
• Terraform vs Pulumi vs OpenTofu
• How to Set Up Automated Database Backups
• What Is DevSecOps?

Sources

• Terraform — lifecycle blocks
• Terraform — state
• Terraform — plan