Callers of a shared network module keep passing malformed values for the vpc_cidr input, and the error only appears deep in the cloud provider's API response during apply. The maintainer wants a clear, module-specific error at plan time. What should the maintainer add?
Select an answer to reveal the explanation.
Short Explanation
Check the ticket at the door, not after the guest is already inside. A validation block with can() around a CIDR function rejects a bad value during planning with your message, long before the provider ever sees it.
Full Explanation
Input variable validation blocks enforce the input contract. Each block has a condition, an expression that must be true for Terraform to proceed, and an error_message shown when it is false. Terraform evaluates variable validations while it creates a plan and stops with that message if a condition fails. Wrapping a CIDR function such as cidrhost or cidrnetmask in can() turns its error on malformed input into false, so a value that is not a valid CIDR fails validation with a clear, module-specific explanation before any API call. A check block reports a failed assertion as a warning and never blocks the plan or apply, so the malformed value would still reach the provider. A postcondition on the resource is evaluated after the provider has planned or applied the object; with a malformed CIDR the provider call fails first, so the postcondition never gets to deliver its message. A string type constraint with nullable = false only guarantees that a non-null string is supplied; type constraints do not validate format. Exam caveat: validation conditions can reference other variables in modern Terraform, but keep each condition focused on one rule so its error message stays precise. Operational check: add a test run that passes an invalid CIDR and lists the variable in expect_failures to prove the validation fires.