Input Variables and Type Constraints

## What a type constraint actually is A `variable` block declares one input to a Terraform module — the root module included. Its `type` argument is not a runtime check bolted on the side; it is part of the module's published interface, and Terraform uses it to *convert* as well as to *reject*. ```hcl variable "instance_name" { type = string description = "Name tag applied to the instance" } ``` When Terraform evaluates the root module's variables at the beginning of a plan, it takes the value supplied for `instance_name`, attempts to convert it to `string`, and either succeeds (the module now sees a `string`) or aborts the entire run with an "Invalid value for input variable" error. For a child module, the same thing happens to each argument written in the calling `module` block. Nothing is created, nothing is refreshed against the API — the failure lands before the graph walk begins. ## The three families **Primitive types** are `string`, `number` and `bool`. Terraform has exactly one number type; there is no separate integer. **Collection types** — `list(T)`, `set(T)` and `map(T)` — hold zero or more elements that must all have the same type `T`. `list(string)` is ordered and indexed by position, `set(string)` is unordered and de-duplicated, `map(string)` is keyed by arbitrary strings. **Structural types** — `object({...})` and `tuple([...])` — describe a fixed shape whose members may each have a different type: ```hcl variable "database" { type = object({ engine = string size_gb = number multi_az = bool }) } ``` A caller passes `{ engine = "postgres", size_gb = 100, multi_az = true }`. Each attribute is checked against its own declared type. `tuple([string, number])` is the positional equivalent and is rare in hand-written code — it mostly shows up as the type Terraform infers for a mixed literal like `["a", 1]`. These nest freely: `list(object({name = string, port = number}))` is an ordinary and very useful constraint for something like a list of listener rules. ## Conversion comes before rejection Terraform is not strictly typed in the "exact match or die" sense. It applies automatic conversions where there is only one sensible reading: `"5"` converts to the number `5` for a `number` variable, `true` converts to `"true"` for a `string`, and a bracketed literal — which is really a *tuple* — converts to `list(string)` or `set(string)` when its elements can all become strings. A braced literal is an *object* and converts to `map(...)` on the same terms. Conversions that would lose information or are ambiguous, such as `"abc"` to `number`, fail. This is why a `.tfvars` file full of quoted values usually works against numeric variables: the conversion, not the author, did the work. ## Omitting the type If you leave `type` off, the variable's constraint is `any` and every value is accepted as-is. That is legal, and it is what a lot of older module code does, but it means the module has no declared interface: a caller learns the expected shape only by reading the module body or by watching the plan fail somewhere deep inside a resource argument. ## Why this matters more in infrastructure code than elsewhere Infrastructure code has an unusually expensive failure mode: a run that dies in the middle has already created some real resources and left the rest undone. Type constraints are the cheapest possible test in that world — they run in the first second of `terraform plan`, cost nothing, and need no credentials or test harness. Declaring `number` on a retention period and `object({...})` on a subnet definition converts a class of caller mistakes from a partially-applied estate into a message on the terminal. The practical rule for module authors: declare the tightest type that is honestly true. `string` beats `any`; `list(object({...}))` beats `list(any)`; and where the shape is genuinely rich but partly optional, the object type with optional attributes is the modern way to say so.