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.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Related prompts
-
Terraform Check Block Scoped Data Source Prompt
Design `check` blocks that use scoped data sources to assert post-apply runtime health (endpoints, DNS, cert expiry) as non-blocking warnings instead of hard plan failures.
-
Terraform Variable Type Constraints Design Prompt
Design precise complex type constraints for module inputs using object, map, and optional() so misuse fails fast at plan time with clear errors.
-
Terraform Check Blocks & Post-Apply Assertions Prompt
Add `check` blocks with scoped data sources and assertions that validate live infrastructure after apply — endpoints reachable, TLS valid, DNS resolving — turning silent misconfigurations into loud plan/apply warnings.
-
Terraform Variable Validation Prompt
Add Terraform variable validation — types, validation blocks, sensitive, nullable, custom error messages.
More Terraform prompts & error guides
Browse every Terraform prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.