HashiCorp Terraform Associate (004) Question 86
Single answer4 Terraform configurationA team maintains a reusable Terraform module that creates a VPC and related networking resources. They want to make the module safer to consume by failing early if callers pass an invalid CIDR block for the VPC. A developer adds the following variable definition inside the module:
variable "vpc_cidr" { type = string
validation { condition = can(cidrhost(var.vpc_cidr, 0)) error_message = "vpc_cidr must be a valid IPv4 CIDR block." } }
A caller then runs terraform plan and sets vpc_cidr = "10.0.0.0". What is the expected behavior?
- A
Terraform accepts the value because it is a string, and the provider will validate it only during apply.
- B
Terraform fails during planning with the custom error message because the variable validation condition evaluates to false.
- C
Terraform automatically converts the value to "10.0.0.0/32" and continues because cidrhost can normalize host addresses.
- D
Terraform ignores the validation block unless the variable is marked as nullable = false.
Show answer and explanation
Correct answer: B
Explanation
This question tests practical use of Terraform configuration features to enforce input correctness in reusable modules. In Terraform, variable validation allows module authors to catch bad inputs early, before provider-specific API calls are attempted. The pattern can(cidrhost(var.vpc_cidr, 0)) is a common and valid way to verify that a string is parseable as a CIDR block because cidrhost requires a proper CIDR prefix expression. If the function would error, can(...) returns false, causing Terraform to fail with the custom error_message.
This behavior aligns with Terraform best practices for module design: validate assumptions close to the input boundary so consumers get clear, actionable errors. Relevant Terraform documentation includes input variable validation and built-in functions such as can and cidrhost. In practice, this improves module reliability and makes plans fail fast when values are malformed.
- A. Incorrect.
Incorrect. Although the variable type is string, the validation block adds an additional constraint beyond type checking. Terraform evaluates input variable validation during plan operations when values are provided. Because "10.0.0.0" is not a valid CIDR prefix expression, Terraform does not defer this check to the provider.
- B. Correct.
Correct. The expression can(cidrhost(var.vpc_cidr, 0)) uses the cidrhost function in a safe way to test whether the supplied value is a valid CIDR block. For the value "10.0.0.0", cidrhost would raise an error because the input lacks a prefix length such as /16 or /24. Wrapping it in can(...) causes the condition to evaluate to false instead of halting expression evaluation, so Terraform reports the custom error message during planning.
- C. Incorrect.
Incorrect. Terraform does not implicitly rewrite a plain IP address into CIDR notation for variable validation. The cidrhost function requires a valid CIDR prefix string as input, and "10.0.0.0" without a mask is invalid for that function.
- D. Incorrect.
Incorrect. Variable validation blocks are independent of nullable. The nullable argument controls whether null is an allowed value for the variable, not whether validation runs. If a non-null value is supplied, Terraform evaluates the validation condition during plan/apply input processing.