HashiCorp Terraform Associate (004) Question 88
Single answer4 Terraform configurationA team maintains a reusable Terraform module that provisions an application stack. The module currently defines a variable as follows:
variable "instance_count" { type = number }
During several deployments, engineers accidentally passed 0 or negative values, causing downstream resource configuration errors. The team wants Terraform to fail early during planning with a clear message whenever the value is less than 1. Which configuration change best meets this requirement while keeping the variable type as a number?
- A
Add a validation block inside the variable: validation { condition = var.instance_count >= 1 error_message = "instance_count must be at least 1." }
- B
Add a lifecycle block to the resources that use count so Terraform prevents invalid variable values before planning
- C
Change the variable type from number to string and document that users must enter values greater than 0
- D
Add an output that checks whether instance_count is valid and prints a warning if the value is less than 1
Show answer and explanation
Correct answer: A
Explanation
The best solution is to use a variable validation block. In Terraform configuration, input variables can include custom validation rules using the validation argument with a condition expression and error_message. This allows module authors to enforce business or operational constraints beyond basic type checking. In this scenario, type = number ensures the value is numeric, while validation ensures it is at least 1.
A typical implementation is:
variable "instance_count" { type = number
validation { condition = var.instance_count >= 1 error_message = "instance_count must be at least 1." } }
This approach aligns with Terraform best practices for defensive module design: use type constraints for structural validation and validation blocks for semantic rules. By comparison, lifecycle blocks affect managed resources, outputs do not validate inputs, and changing the type to string removes useful schema enforcement. See Terraform documentation on input variables and custom validation for the supported pattern.
- A. Correct.
Correct. Input variable validation is the appropriate Terraform configuration feature for enforcing custom rules on variable values. A validation block within the variable definition allows Terraform to evaluate the condition during plan-time input processing and return the custom error message if the value is invalid. This is the recommended way to fail early with a clear, user-friendly message while preserving the variable's numeric type.
- B. Incorrect.
Incorrect. A lifecycle block controls resource behavior such as create_before_destroy, prevent_destroy, or ignore_changes. It does not validate input variables. Also, resource-level logic is too late for this use case because the requirement is to catch the issue early during planning before resource configuration proceeds.
- C. Incorrect.
Incorrect. Changing the type to string weakens the schema rather than improving it. Terraform would no longer enforce numeric input automatically, and the team would rely on documentation instead of configuration-based validation. This increases the chance of invalid inputs rather than reducing it.
- D. Incorrect.
Incorrect. Outputs are evaluated after Terraform has processed configuration and are intended to expose values, not enforce input constraints. An output cannot reliably serve as early validation for module inputs, and a warning would not stop an invalid plan from proceeding.