🚨 Terraform Error Guide: 'Invalid value for variable' — Fix Type & Validation Failures

Overview

Terraform rejects an input before it touches any provider when the value does not satisfy the variable’s declared type or a custom validation {} block. The message points at the exact variable and, for a validation failure, echoes your own error_message:

╷
│ Error: Invalid value for variable
│
│   on variables.tf line 12:
│   12: variable "environment" {
│     ├────────────────
│     │ var.environment is "Prod"
│
│ The environment must be one of: dev, staging, prod.
│
│ This was checked by the validation rule at variables.tf line 15,1-13.
╵

A type-constraint failure looks similar but mentions the expected type — for example “a number is required” or “element 0: string required”. Either way the fix is on the input side, not in a resource: Terraform is telling you the value handed to the variable is wrong before the plan even begins.

Symptoms

• terraform plan, apply, or validate fails immediately with “Invalid value for variable” and no resource activity.
• The message quotes the current value (var.x is "...") and cites a line in your variables.tf.
• A pipeline that worked yesterday fails after someone edited a .tfvars file or a CI variable.
• The same config works locally but fails in CI (or vice versa) because a different -var source is in play.

Common Root Causes

• A value that violates a validation {} condition — an unexpected string, a number out of range, a malformed CIDR or region.
• A type mismatch — passing a string where a number or bool is expected, or a list where an object is required.
• A wrong or shadowed input source — a value from terraform.tfvars, an -var flag, or a TF_VAR_ environment variable overriding what you thought was set.
• Case or whitespace — "Prod" failing a check that expects lowercase "prod".
• A stale or out-of-date .tfvars file left behind after a variable’s constraints were tightened.

Diagnostic Workflow

Run validate first — it checks types and validation rules without contacting any provider, so it is the fastest way to surface the offending variable:

terraform validate

Read the variable declaration the error cites. The type, the validation condition, and the error_message together tell you exactly what a valid value looks like:

variable "environment" {
  type = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "The environment must be one of: dev, staging, prod."
  }
}

Now find which source supplied the bad value. Terraform applies inputs in a fixed precedence (lowest to highest): environment TF_VAR_*, then terraform.tfvars, then *.auto.tfvars (alphabetical), then -var-file, then -var on the command line. Inspect each:

env | grep '^TF_VAR_'                 # environment-variable inputs
grep -rn 'environment' *.tfvars *.auto.tfvars 2>/dev/null

Confirm the value Terraform actually resolves by evaluating it in the console (fixing any obvious type issue first so the console loads):

echo 'var.environment' | terraform console

To test a corrected value quickly, override on the command line — -var wins over every file-based source:

terraform plan -var 'environment=prod'

Example Root Cause Analysis

A CI pipeline began failing with “Invalid value for variable” for var.environment is "Prod", while the same code planned cleanly on a developer’s laptop.

terraform validate reproduced the failure and cited the validation block, whose condition used contains(["dev","staging","prod"], var.environment) — a case-sensitive check. The developer’s terraform.tfvars set environment = "prod", but the CI job passed -var 'environment=Prod' from a pipeline variable. Because -var on the command line has the highest precedence, it overrode the correct lowercase value in the file, and "Prod" failed the check.

Two robust fixes applied. The immediate one was to correct the CI variable to prod. The durable one was to make the validation tolerant of case by normalising the value before comparing, so the same input could never fail on capitalisation again:

variable "environment" {
  type = string
  validation {
    condition     = contains(["dev", "staging", "prod"], lower(var.environment))
    error_message = "The environment must be one of: dev, staging, prod (any case)."
  }
}

After correcting the pipeline variable, terraform validate passed and the plan proceeded.

Prevention Best Practices

• Write precise validation blocks with clear, actionable error_message text so failures explain themselves.
• Normalise inputs (lower(), trimspace()) inside conditions when case or whitespace should not matter.
• Keep a single authoritative source for each variable and document the precedence order so CI overrides do not silently shadow files.
• Run terraform validate in CI before plan to catch bad inputs early and cheaply.
• Validate structured strings (CIDRs, regions, ARNs) with functions like can(cidrhost(var.cidr, 0)) rather than accepting free text.
• Check your HCL with the Terraform validators before committing to catch obvious type and syntax mistakes.

Quick Command Reference

terraform validate                        # type + validation check, no provider
env | grep '^TF_VAR_'                      # find environment-variable inputs
grep -rn '<var>' *.tfvars *.auto.tfvars    # find file-based inputs
echo 'var.<name>' | terraform console      # see the resolved value
terraform plan -var '<name>=<value>'       # highest-precedence override to test

Conclusion

“Invalid value for variable” is an input problem, not a resource problem: the value handed to a variable failed its type or a validation {} rule before any plan ran. The error_message tells you what is wrong; input precedence (env, tfvars, auto.tfvars, -var-file, -var) tells you where the bad value came from. Run terraform validate, read the validation block, and trace the source. For more IaC fixes, see the Terraform guides.