HashiCorp Terraform Associate (004) Question 123
Single answer4g Validate configuration using custom conditionsA platform team maintains a reusable Terraform module that creates an AWS security group. They want to prevent unsafe input before any resources are created. The module currently accepts a variable named ingress_cidrs as list(string). The team wants Terraform to fail during planning if any CIDR in the list is not a valid IPv4 CIDR block or if the list is empty. Which implementation best meets this requirement using Terraform custom conditions?
- A
Add a
validationblock to theingress_cidrsvariable that checkslength(var.ingress_cidrs) > 0 && alltrue([for c in var.ingress_cidrs : can(cidrhost(c, 0))]). - B
Add a
preconditionblock inside theaws_security_groupresource that checks each CIDR withcidrhost, because preconditions are evaluated before variable values are accepted. - C
Add a
postconditionblock to the output that returns the security group ID, because postconditions stop invalid input before planning continues. - D
Add
nullable = falseto the variable and rely on the type constraintlist(string)to reject invalid CIDR syntax and empty lists.
Show answer and explanation
Correct answer: A
Explanation
Terraform supports custom conditions in several places, including variable validation blocks, preconditions, and postconditions. For this scenario, variable validation is the best choice because the goal is to validate user-supplied input to a module before any resources are processed. A common and effective pattern is to combine length(...) > 0 with alltrue(...) over a for expression and can(cidrhost(...)) to verify CIDR syntax. HashiCorp documentation describes input variable validation as the mechanism for enforcing requirements on variable values, while preconditions and postconditions are intended for assumptions and guarantees around resources, data sources, and outputs rather than primary input validation.
- A. Correct.
Correct. A variable
validationblock is the appropriate custom condition when you want to reject bad module input as early as possible.length(var.ingress_cidrs) > 0ensures the list is not empty, andalltrue([for c in var.ingress_cidrs : can(cidrhost(c, 0))])verifies every element can be parsed as a CIDR.cidrhostraises an error for invalid CIDR notation, and wrapping it withcan(...)converts that intofalsefor validation logic. This is a practical pattern for input validation in Terraform. - B. Incorrect.
Incorrect. A
preconditioncan validate assumptions for a resource, data source, or output, but it is not the best fit here because the requirement is specifically to validate module input before resource creation based on the variable itself. Preconditions are useful, but variable validation is the intended mechanism for checking input values directly. The statement that preconditions are evaluated before variable values are accepted is also misleading. - C. Incorrect.
Incorrect. A
postconditionis evaluated after Terraform has planned or applied an object and is used to verify the resulting object state, not to validate raw input before planning proceeds. Attaching a postcondition to an output would be too late for this use case and would not be the appropriate way to reject bad input to a module. - D. Incorrect.
Incorrect.
nullable = falseonly prevents the entire variable from beingnull; it does not enforce that the list contains at least one element. Likewise, the type constraintlist(string)ensures only that the value is a list of strings, not that each string is a valid CIDR. This is a common misconception: type constraints do not perform semantic validation of string contents.