Preconditions and Postconditions in Terraform
What Are Preconditions and Postconditions?
Preconditions and postconditions are validation mechanisms introduced in Terraform 1.2 that allow you to define custom validation rules within your resource, data source, and output blocks. They help ensure that your infrastructure meets specific requirements before and after Terraform applies changes.
Preconditions are checks that run before a resource is created or modified. They validate that all necessary conditions are met for the operation to proceed successfully.
Postconditions are checks that run after a resource is created or modified. They verify that the resulting infrastructure state meets your expectations.
Why Are They Important?
1. Early Error Detection: Catch configuration errors before they cause deployment failures
2. Self-Documenting Code: Conditions serve as inline documentation of requirements
3. Improved Reliability: Ensure infrastructure meets business and technical requirements
4. Better Error Messages: Provide custom, meaningful error messages instead of cryptic provider errors
5. Assumption Validation: Verify assumptions about external data or resource behavior
How They Work
Both preconditions and postconditions use a lifecycle block with a condition argument and an error_message argument:
resource "aws_instance" "example" {
ami = data.aws_ami.example.id
instance_type = "t3.micro"
lifecycle {
precondition {
condition = data.aws_ami.example.architecture == "x86_64" error_message = "The selected AMI must use x86_64 architecture." }
postcondition {
condition = self.public_ip != "" error_message = "Instance must have a public IP address." } }}
Key Differences:
- Preconditions can reference input variables, data sources, and other resources, but NOT the resource's own attributes (since it doesn't exist yet)
- Postconditions can use the self keyword to reference the resource's own computed attributes after creation
Where Can You Use Them?
- Resource blocks
- Data source blocks
- Output blocks
Exam Tips: Answering Questions on Preconditions and Postconditions
1. Remember the Timing: Preconditions evaluate BEFORE resource creation; postconditions evaluate AFTER. Questions often test this distinction.
2. Know the self Keyword: Only postconditions can use self to reference the current resource's attributes. If you see self in a precondition, it's invalid.
3. Lifecycle Block Location: Both conditions must be placed inside the lifecycle block. Watch for questions with incorrect block placement.
4. Required Arguments: Both condition and error_message are mandatory. A missing error_message makes the configuration invalid.
5. Boolean Expressions: The condition must evaluate to a boolean (true/false). If true, the check passes; if false, Terraform reports the error.
6. Multiple Conditions: You can define multiple precondition and postcondition blocks within a single lifecycle block.
7. Common Exam Scenarios:
- Validating AMI properties before launching instances
- Ensuring required tags exist after resource creation
- Verifying data source returns expected values
- Confirming output values meet requirements
8. Distinguish from Variable Validation: Variable validation blocks validate input variables at the variable level, while preconditions and postconditions validate within resource context with access to more data.