In Terraform, what happens when a root-module variable has no default and no value is supplied — first in an interactive terminal, and then in a CI job running terraform apply -input=false?

## Required versus optional variables A `variable` block with a `default` is optional — omit it everywhere and the default applies. A `variable` block without a `default` is required: Terraform must obtain a value from some source before it can evaluate the configuration. There is no implicit empty string, no zero value and no null fallback. ```hcl variable "environment" { type = string # required: no default } variable "instance_count" { type = number default = 1 # optional } ``` ## Interactive behaviour Run `terraform plan` with `environment` unset and Terraform stops before doing any work and prompts on the terminal, one variable at a time, showing the variable's `description` if it has one. Whatever you type is used for that run only — nothing is written to a file. This is a convenience for a human exploring a configuration, and it is a trap as a workflow: the value is unrecorded, unreviewed and different every time somebody's fingers slip. Only root-module variables can be prompted for. A child module's variables are set by arguments in its `module` block, so a missing one there is a configuration error at plan time, not a prompt. ## Non-interactive behaviour `-input=false` tells Terraform never to ask a question. With a required variable unsupplied, the run then fails with an error reporting that the root module input variable is not set and has no default value, and pointing at `-var` or `-var-file` as the way to provide one. The equivalent environment switch is `TF_INPUT=0`, which is handy when the command line is assembled by a wrapper you do not control. Without `-input=false`, a non-interactive runner behaves badly in a way that depends on the runner: some fail immediately because stdin is closed, others sit waiting for input until the job's timeout kills it, burning a runner slot and leaving a state lock held for the duration. Neither is a good outcome, and both are avoidable by making `-input=false` unconditional in automation. ```bash terraform plan -input=false -var-file=envs/prod.tfvars -out=tfplan terraform apply -input=false tfplan ``` ## Designing for the loud failure The interesting judgment is not the mechanics but the choice of which variables get a default: - **No default** for anything whose wrong value is dangerous or unguessable: the environment or account name, the region when the blast radius differs per region, a release identifier the pipeline supplies. If it is missing, the run must stop. - **A default** for genuinely optional knobs where a sensible value exists and a missing one is harmless: log retention, an instance count that a module consumer rarely overrides, a feature toggle that is off. A default on a dangerous variable converts a forgotten `-var-file` into a silent, successful run against the wrong target. A missing default on a harmless knob just makes every caller pass boilerplate. Getting this split right is most of what "good module interface" means in practice. ## Related failure that looks the same If a value *is* supplied but the variable name is misspelled in the tfvars file, Terraform emits a warning about a value for an undeclared variable, ignores it, and then reports the declared variable as unset — so the same error appears even though a value was clearly in the file. Reading the warning above the error is the whole diagnosis. ## What good looks like in a pipeline Every automated Terraform invocation carries `-input=false`, supplies environment values through an explicit `-var-file`, and injects per-run values through `TF_VAR_` or `-var`. Required variables have no defaults, so the pipeline cannot drift into a run with unintended inputs — the worst case is a failed job with an error that names exactly which variable was missing.