A required variable with no value
Terraform prompts on stdin rather than failing, which is how a pipeline hangs silently
variable "region" {
type = string
description = "Where to deploy."
}Terraform Variables Checker
Paste your variables.tf and your .tfvars together. The two problems this finds both fail quietly: one hangs a pipeline, the other applies the wrong configuration.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A typo in a tfvars key
Only a warning, so the apply succeeds and the variable keeps its default
variable "instance_count" {
type = number
default = 1
}
instance_cout = 3A string where a list is declared
Terraform converts what it can, and this is not one of those cases
variable "zones" {
type = list(string)
}
zones = "eu-west-1a"Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Running Terraform in CI without -input=false
A missing required variable prompts on stdin instead of failing. The job produces the prompt and then hangs until the runner times out, with nothing in the log naming the variable.
Instead:Add -input=false to every plan and apply in automation. The run then fails immediately and says which variable is missing.
Trusting an apply that warned about an undeclared variable
The warning means a tfvars key matched no variable, so the value was thrown away and the default was used. The apply succeeds with configuration nobody intended.
Instead:Treat that warning as an error. It is almost always a typo in the key.
Putting a sensitive value in a committed tfvars file
sensitive = true only stops Terraform printing it. The file still holds the plaintext, and so does state.
Instead:Pass it as TF_VAR_name from your CI secret store, or read it from a secret manager with a data source.
A missing required variable does not fail, it prompts
That single behaviour is why a pipeline can hang with no error and no output. Terraform is waiting on stdin for a value nobody is there to type.
A variable with no default and no value asks on stdin
Interactively this is convenient. In CI the job produces the prompt text and then nothing, until the runner's timeout kills it, and the log gives no indication that a value is what was wanted. Adding -input=false to every automated command turns this into an immediate, readable failure.
An undeclared tfvars key is only a warning
Terraform reports a value for an undeclared variable and carries on. So a typo in a tfvars key is discarded, the variable it was meant to set keeps its default, and the apply succeeds with the wrong configuration. This is the failure with no failure attached.
No type means the variable accepts anything
Without a type the variable is any, and a wrong shape is not caught where it is set. It surfaces wherever the value is finally used, often several modules down, as an error about a type that appears nowhere in the file you are reading.
sensitive controls printing and nothing else
It stops Terraform echoing the value. It does not affect the tfvars file the value is written in, and it does not affect state, where the value is stored in plaintext. A sensitive variable with a literal value in a committed tfvars file is a committed secret.
The description is what somebody reads at the worst moment
It is what terraform-docs publishes, and it is the text shown by the interactive prompt when the value is missing. So the one place a description definitely gets read is when somebody is confused and blocked.
Type conversion is helpful right up to the point it is not
A number written as a string converts. A string where a list is declared does not, and the error arrives at plan time naming the variable and the expected type. list(string) wants ["a"], not "a".
Related terraform tools
Terraform variables.tf Generator From the var. references you already wrote Terraform Deprecated Syntax Checker What a current Terraform rejects Terraform Validator & Formatter Does it parse, and is it formatted? Terraform dynamic Block Generator It is ingress.value, not each.value Terraform check and precondition Generator A failed check does not stop the apply Terraform Unused Declaration Linter Dead variables, locals and data sources
All 35 terraform tools