HashiCorp Terraform Associate (004) Question 125
Single answer4g Validate configuration using custom conditionsA platform team maintains a reusable Terraform module that provisions an AWS EC2 instance. The module accepts a variable named "instance_type" and must enforce the company policy that only general-purpose instance types from the t3 family are allowed. The team wants Terraform to fail early during planning if a caller passes any other value. Which implementation best meets this requirement?
- A
Add a validation block to the variable: variable "instance_type" { type = string validation { condition = can(regex("^t3\.", var.instance_type)) error_message = "instance_type must be a t3 instance type." } }
- B
Add a precondition block inside the provider "aws" configuration to verify var.instance_type starts with "t3."
- C
Add a postcondition block to the aws_instance resource so Terraform rejects non-t3 types before it creates the resource
- D
Use terraform validate alone, because it automatically checks whether variable values match company naming and instance family policies
Show answer and explanation
Correct answer: A
Explanation
The best solution is to use input variable validation, because the requirement is to restrict what values callers can pass into a module and to fail as early as possible during planning. In Terraform, custom conditions include variable validation, preconditions, and postconditions. Variable validation is specifically designed for validating module inputs. Preconditions are useful when a resource, data source, or output has assumptions that must be true before evaluation, while postconditions verify guarantees after evaluation. HashiCorp documentation recommends using the mechanism closest to the intent: variable validation for input constraints, preconditions for assumptions, and postconditions for guarantees. In this scenario, enforcing that instance_type belongs to the t3 family is an input constraint, so a validation block on the variable is the correct implementation.
- A. Correct.
Correct. Input variable validation is the appropriate custom condition for enforcing constraints on module inputs. A validation block inside the variable definition lets Terraform detect invalid values during plan-time input evaluation and return a custom error message. Using a regex anchored to the start of the string ensures only values beginning with "t3." are accepted. This is the most direct and maintainable way to fail early when callers pass unsupported instance types.
- B. Incorrect.
Incorrect. Preconditions are supported on resources, data sources, and outputs, not in provider configuration blocks. Even if the intent is to validate early, provider blocks are not where custom condition checks for input policy enforcement are implemented.
- C. Incorrect.
Incorrect. Postconditions are evaluated after Terraform plans or applies an object and are used to verify guarantees about the resulting object. They are not the best choice for validating module input values before resource creation. A postcondition on aws_instance would be later and less appropriate than variable validation for this requirement.
- D. Incorrect.
Incorrect. terraform validate checks whether configuration is syntactically valid and internally consistent, but it does not automatically enforce organization-specific input rules such as restricting instance families unless you explicitly define custom conditions like variable validation, preconditions, or postconditions.