When would you reach for a `precondition` or `postcondition` in Terraform instead of a variable `validation` block?

## Three checks, three different subjects Terraform's custom-condition family looks like one feature with three spellings. It is not — the three differ in *what they make a claim about*. | Construct | Lives in | Claims something about | |---|---|---| | `validation` | a `variable` block | the input this module was given | | `precondition` | a `lifecycle` block on a resource or data block, or directly in an `output` block | an assumption that must hold before this object is handled | | `postcondition` | a `lifecycle` block on a resource or data block | a guarantee about the object that resulted | `precondition` and `postcondition` arrived in Terraform 1.2. Both take the same two arguments as a validation: `condition` and `error_message`. ## Precondition: the assumption A precondition is a guard evaluated before Terraform plans or applies the object it is attached to. The classic case is an assumption that spans two things the module did not choose together: ```hcl resource "aws_instance" "app" { ami = var.ami_id instance_type = var.instance_type lifecycle { precondition { condition = data.aws_ami.selected.architecture == "x86_64" error_message = "The supplied AMI must be an x86_64 image for this instance type." } } } ``` No variable validation could express that, because the fact being checked is not in the input at all — it comes from a data source that had to be read first. Preconditions may reference anything in the module: other resources, data sources, locals, several variables at once. An `output` block takes a `precondition` directly, not nested in a `lifecycle` block, and that placement is worth remembering because it is the odd one out. It is how a module refuses to export a value it does not trust. ## Postcondition: the promise A postcondition is checked after the object is resolved, and it is the only one of the three that can use `self` to refer to the object's own attributes: ```hcl data "aws_ami" "app" { most_recent = true owners = ["self"] filter { name = "name" values = ["app-*"] } lifecycle { postcondition { condition = self.architecture == "x86_64" error_message = "The most recent app-* AMI is not an x86_64 image." } } } ``` That is a guarantee about a result the module computed rather than received: a `most_recent` filter will happily pick up whatever was published last night, and the postcondition is how the module notices. Timing has a consequence people miss. When the values a postcondition needs are known at plan time, it is checked during plan and stops the run cheaply. When they are only known after the object exists — a generated address, a computed ARN — the check happens during apply, *after* that object has been created. The apply fails, but the object is real and is recorded in state. A postcondition is a tripwire, not a rollback; Terraform has no transaction to undo. ## Choosing between them Ask what the claim is about. - About a value the caller passed in → `validation`, because it fails earliest, needs no data sources, and the error points at the argument the caller can actually change. - About a relationship between things, or a fact fetched from the provider → `precondition`, attached to the object that depends on the assumption so the error names the right thing. - About something the run produced → `postcondition`. There is a version wrinkle worth stating explicitly in an interview. Before Terraform 1.9, a validation condition could reference only its own variable, so every cross-field rule — "backup_bucket must be set when backups_enabled is true" — had to be written as a precondition. From 1.9 those rules can move back to the variable where they are more discoverable. If a codebase is full of preconditions doing input validation, that is usually the history, not a design choice. ## And the placement question Put the check where the failure will make sense. A precondition attached to the resource that relies on the assumption produces an error naming that resource; the same condition hoisted into an unrelated place produces an error somebody has to go and decode. All three constructs are documentation that executes, and the address in the diagnostic is part of the message.