In Terraform, what does a `validation` block inside a `variable` block do, and which two arguments does it take?

## What a validation block is A Terraform *input variable* is declared with a `variable` block, which is the public interface of a root module or a child module. The `type` argument constrains the **shape** of the value — string, number, a list of objects and so on. A `validation` block, nested inside the same `variable` block, constrains the **value**: it is a rule the incoming value must satisfy before Terraform is willing to proceed. ```hcl variable "environment" { type = string validation { condition = contains(["dev", "staging", "prod"], var.environment) error_message = "The environment must be one of: dev, staging, prod." } } ``` ## The two arguments `condition` is an expression that must evaluate to `true` or `false`. `true` means the value is acceptable; `false` means Terraform stops. The expression normally refers to the variable being validated through `var.<name>` — you write `var.environment`, not a bare `environment`. `error_message` is the string shown to whoever ran Terraform when the condition comes out `false`. It is not optional, and it is the entire point of the feature: the machine already knows the value is wrong, and the message is what turns that into something the caller can act on. Write it as a full sentence that states the rule and, where useful, the acceptable values — "The environment must be one of: dev, staging, prod" beats "invalid environment". ## When the rule runs Terraform evaluates variable validations while it is evaluating the configuration for a plan, which is before it has created or modified anything. A failure is a plan error: the command exits non-zero, no provider API calls are made for the resources you were about to build, and there is no saved plan file to apply. That is why this is described as the cheapest layer of the IaC test pyramid — it costs no cloud calls, no test harness and no minutes of CI, and it catches the mistake at the moment somebody typed it. Contrast the alternative. Without the rule, a value like `Prod` flows into a resource name, an S3 bucket name or a tag, and you find out either from a provider error partway through the apply — with some resources already created — or, much worse, not at all, because the value was merely wrong rather than illegal, and you have quietly built a fourth environment nobody meant to have. ## Several rules on one variable A variable may carry more than one `validation` block, and this is usually better than cramming several rules into one condition with `&&`. Terraform evaluates each block and reports every one that failed, each with its own `error_message`, so the caller sees "must be lowercase" and "must be at most 24 characters" together instead of discovering the second only after fixing the first. ```hcl variable "cluster_name" { type = string validation { condition = length(var.cluster_name) <= 24 error_message = "The cluster_name must be 24 characters or fewer." } validation { condition = lower(var.cluster_name) == var.cluster_name error_message = "The cluster_name must be lowercase." } } ``` One rule per block, one message per rule, is the readable form. ## What it is not It is not the `terraform validate` command. That command checks that the configuration itself is internally consistent — syntax, references, argument names — and is a different thing that happens to share the word. Variable validation is a rule you author about a value. It is also not a check on anything outside the module's input. Whether the AMI you were handed is the right architecture, or whether the instance that got built actually has a public address, are assumptions about the world rather than about the argument list, and Terraform has separate `precondition` and `postcondition` constructs for those. ## What interviewers are listening for That you know the two arguments, that the condition is a boolean and not the value itself, and above all that the check happens at plan time so a bad input costs nothing. Candidates who reach for validation first — before proposing a policy scanner or an integration test — are signalling that they know how to spend a testing budget.