⚙️ OpenTofu Error: 'Invalid value for variable' Validation Block Failed

Exact Error Message

╷
│ Error: Invalid value for variable
│
│   on variables.tf line 12:
│   12:   validation {
│   13:     condition     = contains(["dev", "staging", "prod"], var.environment)
│   14:     error_message = "environment must be one of dev, staging, or prod."
│   15:   }
│     ├────────────────
│     │ var.environment is "production"
│
│ environment must be one of dev, staging, or prod.
│
│ This was checked by the validation rule at variables.tf:12,3-13.
╵

The wording is always Invalid value for variable, followed by the custom error_message you wrote inside the validation block.

What It Means

A variable block can carry one or more validation blocks. Each contains a condition expression that must evaluate to true for the supplied value to be accepted. When you pass a value that makes the condition evaluate to false, OpenTofu halts before planning and prints Invalid value for variable along with your custom error_message.

This is not a bug or a state problem. It is your own guardrail doing exactly what it was written to do. The error means the value you passed on the command line, in a .tfvars file, or from an environment variable did not meet the rule the module author defined. The fix is either to pass a conforming value or to correct the validation rule if the rule itself is wrong.

Common Causes

• The supplied value genuinely violates the rule (for example "production" when only "prod" is allowed).
• A typo or trailing whitespace in a .tfvars file or TF_VAR_* environment variable.
• The condition expression is too strict, or was written incorrectly (wrong regex, inverted logic).
• A value comes from another automation layer (CI variable, wrapper script) that formats it differently than expected.
• A recently added or tightened validation block now rejects values that older pipelines still send.

Diagnostic Commands

See exactly which value OpenTofu received and which rule rejected it:

tofu plan -var 'environment=production'

Inspect the variable definition and its validation blocks:

tofu console
> var.environment

Check whether an environment variable is silently overriding your input:

env | grep '^TF_VAR_'

Test the condition expression in isolation before changing code:

echo 'contains(["dev","staging","prod"], "production")' | tofu console
# false

Step-by-Step Resolution

1. Read the error carefully. The ├── line shows the actual value OpenTofu evaluated (var.environment is "production"), and the last line is your own error_message. Together they tell you what was passed and what was expected.

2. If the value is simply wrong, pass a conforming one:

tofu plan -var 'environment=prod'

3. If the value lives in a .tfvars file, fix it there and re-plan:

# terraform.tfvars
environment = "prod"

4. If an environment variable is the culprit, unset or correct it. TF_VAR_environment overrides file values, so it is a common hidden source:

unset TF_VAR_environment

5. If the rule itself is wrong or too strict, fix the condition. For example, to accept "production" as an alias, broaden the list or normalize first:

variable "environment" {
  type = string
  validation {
    condition     = contains(["dev", "staging", "prod", "production"], var.environment)
    error_message = "environment must be one of dev, staging, prod, or production."
  }
}

6. Re-run the plan and confirm the error is gone:

tofu validate && tofu plan

Prevention

• Write error_message text that states the exact allowed values, so callers can self-correct without reading the code.
• Keep validation rules and the values your CI passes in sync; when you tighten a rule, update every pipeline that feeds it.
• Prefer contains(), can(), and regex() for readable conditions, and test them in tofu console before committing.
• Normalize input (for example lower(var.environment)) before validating so case differences do not trip the rule.
• Document expected variable formats in the module README and, where possible, generate them from the same source your automation uses. Our prompt library has ready-made prompts for drafting robust variable validation blocks.

Related Errors

• No value for required variable — a variable with no default and no supplied value, a different pre-plan failure.
• Invalid value for input variable — older wording for the same validation mechanism.
• Invalid function argument — a condition expression that errors out (for example bad regex) rather than returning false.
• Reference to undeclared input variable — the variable is used but never declared with a variable block.

Frequently Asked Questions

Why does OpenTofu stop before planning? Variable validation runs during variable evaluation, which happens before any resource is planned. A failed rule aborts the run immediately so no invalid value ever reaches a provider.

Can I temporarily bypass a validation rule? Not with a flag. Validation is part of the configuration, so you must either pass a conforming value or edit the condition/list in the variable block.

Why does the error show a value I did not type? A TF_VAR_ environment variable or an auto-loaded *.auto.tfvars file may be supplying it. Run env | grep TF_VAR_ and check for auto-loaded files.

Can one variable have multiple validation rules? Yes. You can add several validation blocks to one variable, and each is checked independently, so you can report distinct messages for distinct problems.

Where can I find more OpenTofu troubleshooting? See the OpenTofu guides for the full catalog of error walkthroughs.