What rules about a Terraform input variable can a `validation` block enforce that a `type` constraint cannot?

## Two different questions Every input variable is checked twice before Terraform will use it, and the two checks answer different questions. The `type` argument answers **is this the right kind of thing**. `string`, `number`, `bool`, `list(string)`, `map(number)`, `set(string)`, and structural types like `object({ name = string, size = number })` or `tuple([string, number])`. Terraform will convert where it safely can and reject where it cannot. Structural types can go surprisingly far — an attribute can be declared `optional()` with a default — but everything the type layer knows is about shape. A `validation` block answers **is this a sensible thing**. It is a boolean rule about the value. The dividing line that matters in practice: *if a wrong value would still satisfy the type and would still build — just build the wrong thing — the type system cannot help you.* `"Production"` is as valid a string as `"prod"`. `0` is as valid a number as `30`. `"10.0.0.0/8"` is as valid a string as any bucket name. ## The five families of rule you actually write **Allowed set.** The most common by a distance. An environment, an instance class, a log level. `contains(["dev", "staging", "prod"], var.environment)`. There is no enum type in HCL, so this rule *is* the enum. **Numeric range.** Retention days, replica counts, ports, timeouts. ```hcl variable "retention_days" { type = number validation { condition = var.retention_days >= 1 && var.retention_days <= 365 error_message = "The retention_days value must be between 1 and 365." } } ``` **Naming pattern.** Cloud resource names have real syntax rules — lengths, allowed characters, no leading digit, lowercase only. `can(regex("...", var.name))` expresses them, and `can()` is there because `regex()` raises an error rather than returning `false` when it does not match. **Collection shape and content.** `length(var.subnets) >= 2` for a module that requires two availability zones. `alltrue([for p in var.ports : p > 1024])` to require every element of a list to satisfy something — the `for` expression plus `alltrue` idiom is how you validate collections element-wise. **Structural or cross-field rules.** A subnet CIDR that must be inside the VPC CIDR. A `backup_bucket` that must be set whenever `backups_enabled` is true. These involve either arithmetic no type can perform, or two variables at once. Cross-variable references inside a validation condition became legal in Terraform 1.9; before that, a condition could refer only to its own variable, and teams worked around it with a `null_resource` or a contrived local. If you are targeting an older version, say so, and put the cross-field rule in a `precondition` instead. ## Where types are still the better tool Do not turn validation into a hand-rolled type system. If the value is a number, declare `type = number` rather than accepting a string and validating that it parses. If it is a record of three fields, declare an `object({...})` rather than a `map(string)` plus five validations checking which keys exist. A type failure produces a clear message for free; a validation is code you have to write and maintain. Types first, values second. ## Why this earns points in an interview Because it is where a module stops being a pile of resources and starts being an interface. The module author knows things the caller does not: that this CIDR must be at least a /20 to fit the subnets it will carve, that this name becomes part of a DNS record and cannot contain an underscore. Encoding those as validations turns tribal knowledge into an error message that arrives at the moment somebody gets it wrong, in the terminal they are already looking at — at plan time, with no cloud calls, no CI minutes and no half-built environment.