In March 2026, Alexey Grigorev asked Claude Code to clean up a Terraform mess of his own making. It did. Two production databases and 2.5 years of backups were gone in a single session. He wrote a postmortem. Buried in the checklist was something more important than the checklist: AWS deletion protection is flawed. You pay for a feature called deletion protection. It does not protect against deletion. That is not a misconfiguration. That is a product that does not do what it says.
Grigorev is initiated. He knows the toolchain. He identified the flaw. He published it.
The crowd read the headline and blamed the AI. Then the developer. Neither conclusion required understanding how Terraform works.
Both missed the point entirely.
The Stack Overflow problem
Developers love Stack Overflow. It is the first instinct. Hit an error, search the error, find the answer, apply the fix. The workflow is so ingrained it happens without thinking.
The deletion_protection error looks like any other blocker. The Stack Overflow answer looks like any other fix. The developer who disables it is not being reckless — they are doing exactly what they were trained to do. Nothing in the answer says: this flag was set by someone with production authority. Nothing says: disabling this requires approval outside your team. Nothing says: you are crossing a governance boundary.
It says: here is how to fix the error. And the developer fixes the error.
That is what makes this so effective at bypassing governance. It fits perfectly into the normal development workflow. It does not feel like a violation. It feels like unblocking yourself.
You paid for this
deletion_protection is not a free community plugin. It is a feature AWS sells as part of RDS. You pay for the database. You enable a flag called deletion protection because you reasonably expect it to protect against deletion.
It does not. The bypass has been on Stack Overflow for years. It is not an exploit. It is not a hack. It is a well-known, widely-used answer to a common error message. The protection that AWS sells you is defeated by a search result.
That is not a misconfiguration on your part. That is a product that does not do what its name says.
Who sets deletion_protection
deletion_protection on a production database is not a development decision. It is set by someone with production authority — a DBA, an infrastructure lead, an ops team — whose explicit responsibility is to ensure that database does not disappear.
It is a governance decision. It sits outside the development lifecycle by design. The developer does not own it. The developer should not be able to touch it.
A DBA who discovered that a terraform apply had silently disabled deletion_protection — because a developer hit an error and followed a Stack Overflow answer — would have every right to be furious. Their governance decision was overridden without a ticket, without approval, without anyone realising a boundary had been crossed.
The bypass in four lines
This is the Stack Overflow answer. Every initiated developer has seen it or a version of it.
resource "aws_db_instance" "production" {
# ... rest of your config ...
deletion_protection = false
}
Run terraform apply. Terraform calls the AWS API to set deletion_protection = false. The database is now unprotected. Run terraform destroy, or remove the resource block and apply again. The database is gone.
No special permissions. No approval workflow. No audit trail that reads as anything other than a routine plan-apply cycle. The governance decision your DBA made in a meeting with a ticket and a sign-off is undone in four lines and two commands.
What could actually fix this
There are two places where this could be enforced. Neither has acted.
The strongest fix is AWS enforcing that deletion_protection cannot be lifted without a separate, explicit authorisation — production-level credentials, audit trail, a distinct action outside the development toolchain. No Stack Overflow answer fixes that.
The simplest fix costs nothing: change the name. deletion_protection implies protection against deletion. It does not provide that. A name that accurately describes what the flag actually does — guards against console deletion, not API deletion — means no DBA sets it expecting coverage it does not have. The governance confusion starts with the name.
AWS has not done either. Documenting the correct configuration costs nothing and shifts responsibility to whoever did not read it. That is the cheaper option, so that is what happened.
The Stack Overflow answer is still there. The database is already gone.