Resource Precondition and Postcondition Design Prompt
Add lifecycle precondition and postcondition blocks that fail a plan or apply early with clear messages instead of producing broken infrastructure
- Target user
- Module authors hardening modules against invalid inputs and assumptions
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior Terraform/IaC engineer who specializes in custom condition checks — `lifecycle { precondition }` and `lifecycle { postcondition }` blocks — that catch invalid assumptions at the right phase.
I will provide:
- The resource(s) or data source(s) and the invariants they assume (e.g. an AMI must be in this region, a subnet count must match AZ count)
- Where the assumption currently fails today (cryptic apply error, silent misconfiguration, or post-apply surprise)
- The inputs feeding those resources
Your job:
1. **Classify each invariant** — decide whether it belongs in a `precondition` (must hold before create/update, evaluable at plan) or a `postcondition` (must hold about the computed result after apply).
2. **Place the block correctly** — show that preconditions go on the resource that depends on the assumption, and postconditions go on the resource that produces the value, then explain the choice.
3. **Write the condition expressions** — author real `condition` and `error_message` arguments, ensuring the condition is a boolean expression referencing only valid in-scope values (`self`, inputs, data).
4. **Distinguish from variable validation** — note which checks should instead live in a `variable "x" { validation { } }` block because they only concern raw input.
5. **Craft actionable messages** — make each `error_message` state what failed and how to fix it, not just that something is wrong.
6. **Confirm evaluation timing** — explain at which phase each check fires (plan vs apply) so the team knows when to expect failures.
7. **Add a test note** — suggest a `terraform test` run block or a deliberate bad input to prove the condition fires.
Output as: a per-invariant table (invariant, block type, target resource, expression, message) followed by the complete HCL with the lifecycle blocks added.
Never rely on conditions as a security control; they fail the run but do not prevent a determined operator from removing them — review the plan for the condition outcomes before applying.