Known Terraform limitations, module by module
A lifecycle block cannot take a variable. That single restriction is behind
most of the recurring "why can't this module just…" requests: prevent_destroy
on a data bucket, ignore_changes on tags an external controller writes,
create_before_destroy on a security group that is still attached. No module in
any registry can expose them, because Terraform evaluates lifecycle before it
evaluates anything a module could pass in.
These pages document the ones that come up per module. Each problem states what causes it, links the upstream issues, gives the native workaround in full, and says whether compliance.tf has a rule for it yet - including where it does not.
The native option is named first, every time
Several of these problems have a good answer that needs nothing from
compliance.tf: provider default_tags, a resource's own deletion protection,
or simply not managing a field two systems both want to own. Those are named
before any rule is.
Modules
| Module | Recurring problems | Answered by a rule today |
|---|---|---|
| VPC | 1 | 1 |
| Security group | 1 | 0 |
| S3 bucket | 2 | 2 |
| IAM | 1 | 1 |
| RDS | 2 | 1 |
| RDS Aurora | 1 | 1 |
| EKS | 1 | 0 |
| Auto Scaling | 1 | 0 |
| ECS | 2 | 0 |
| Lambda | 1 | 0 |
| EC2 instance | 1 | 1 |
| DynamoDB table | 2 | 2 |
| KMS | 1 | 1 |
| Secrets Manager | 1 | 1 |
| ACM | 1 | 0 |
How to read a solutions page
- The symptom, written the way it gets searched for.
- Why Terraform cannot fix it, with the upstream issues so you can check.
- The native workaround in full, including when it is a fork.
- The rule, where one exists, with the HCL diff it produces - or an explicit "native option only, today" where it does not.
On a framework host you name the rules you want in ?add_rules=, on top of whatever
Baseline your organization has Enforced; on an organization host that
organization's configuration decides. See
Operational Rules for the model and
Operational Rule Definitions for what each rule is.