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."
} 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.
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.
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.
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.
Terraform prompts on stdin rather than failing, which is how a pipeline hangs silently
variable "region" {
type = string
description = "Where to deploy."
}Only a warning, so the apply succeeds and the variable keeps its default
variable "instance_count" {
type = number
default = 1
}
instance_cout = 3Terraform converts what it can, and this is not one of those cases
variable "zones" {
type = list(string)
}
zones = "eu-west-1a"These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".