HashiCorp Terraform Associate (004) Question 122
Single answer4g Validate configuration using custom conditionsA platform team maintains a reusable Terraform module that creates an AWS security group. To reduce misconfigurations, they want Terraform to fail early if a caller provides an ingress port outside the valid TCP/UDP range. They also want the validation to happen before any provider API calls are made. Which approach best meets this requirement?
- A
Add a validation block to the input variable for the port, using a condition that checks the value is between 1 and 65535 and an error_message that explains the constraint.
- B
Add a lifecycle precondition block inside the aws_security_group resource to check that the port is between 1 and 65535.
- C
Use terraform validate by itself, because it automatically verifies that all numeric values are semantically valid for the target provider.
- D
Add a depends_on argument to force the security group to be evaluated after variable assignment, which will prevent invalid port values from reaching the resource.
Show answer and explanation
Correct answer: A
Explanation
The best solution is to use a variable validation block on the module input. Terraform supports custom conditions for validating configuration in several places, including input variable validation, preconditions, and postconditions. For this scenario, the team wants to validate a caller-provided module input and fail as early as possible, so variable validation is the most appropriate tool. A typical implementation would look like: variable "ingress_port" { type = number validation { condition = var.ingress_port >= 1 && var.ingress_port <= 65535 error_message = "ingress_port must be between 1 and 65535." } }. Preconditions are valuable when validating assumptions about resources or data sources, especially when expressions depend on values known only later in planning or applying. However, best practice is to validate direct module inputs with variable validation first. This aligns with Terraform documentation on custom conditions, which distinguishes input variable validation from resource preconditions and postconditions.
- A. Correct.
Correct. A variable validation block is designed to validate input values using custom conditions and return a clear error message when the condition fails. This is the best fit when you want to reject invalid module inputs such as a port number outside 1-65535. Because the check happens during Terraform's evaluation of input values, it fails before Terraform attempts provider operations, which aligns with the requirement to catch the problem early.
- B. Incorrect.
Incorrect. A precondition can enforce custom rules on resources, data sources, and outputs, and it is useful when validating assumptions tied to resource configuration or computed values. However, for a simple module input constraint like an allowed port range, variable validation is the more appropriate and earlier mechanism. Precondition is not the best answer here because the requirement is specifically about validating caller input before provider API calls, and variable validation is intended for that purpose.
- C. Incorrect.
Incorrect. terraform validate checks whether a configuration is syntactically valid and internally consistent, but it does not automatically understand every semantic constraint of provider-specific values such as whether a custom input should be limited to a certain range unless you explicitly define that rule. Without a custom condition, Terraform will not infer this business rule for you.
- D. Incorrect.
Incorrect. depends_on controls dependency ordering in the graph; it does not perform input validation and does not stop a bad variable value from being used. This option reflects a common misconception that dependency management can enforce correctness rules. It cannot validate that a number falls within a required range.