Input Variables

Input variables are a configuration's parameters — the values you change between environments or runs without editing the code. A variable block declares one; var.name reads it. Variables are how a single configuration serves dev and prod, how a module exposes a clean interface, and how environment specifics stay out of the committed code.

The thing that trips people up is not the syntax — it is where a value actually comes from. Terraform reads a variable from several sources with a strict precedence, and a surprising number of "why is it using the wrong region?" sessions end with someone discovering a -var flag or a stray .auto.tfvars file was winning.

Declaring a Variable

A variable block has three fields worth setting on every declaration: type constrains what callers may pass, default makes the variable optional by supplying a fallback, and description documents the interface. The block below declares an instance type that defaults to t3.micro and a required environment name with no default.

variable "instance_type" {
  type        = string
  default     = "t3.micro"
  description = "EC2 instance type for the app servers"
}

variable "environment" {
  type        = string
  description = "Deployment environment: dev, staging, or prod"
}

Reading a Variable

You reference a variable anywhere a value is allowed with var.name. There is no special interpolation needed for a bare reference — var.instance_type evaluates to the string. The resource below reads both variables, building a name from the environment and selecting the instance type from the input.

resource "aws_instance" "app" {
  ami           = "ami-0abc123"
  instance_type = var.instance_type
  tags = {
    Name        = "app-${var.environment}"
    Environment = var.environment
  }
}

Where Values Come From

Terraform collects a variable's value from several sources and the most specific wins. In ascending order of precedence: the default in the block, then terraform.tfvars, then any *.auto.tfvars files (alphabetical), then -var-file and -var flags on the command line. The TF_VAR_ environment variables sit below the tfvars files. Knowing this order is what lets you predict which value actually applies.

# prod.tfvars
instance_type = "m5.large"
environment   = "prod"

# an environment variable feeds var.environment
export TF_VAR_environment=staging

# a -var flag overrides the tfvars file
terraform apply -var-file=prod.tfvars -var="instance_type=m5.xlarge"

Required Variables and Automation

A variable with no default is required. In an interactive session Terraform prompts for it; in automation there is no human to answer, so an unset required variable either hangs waiting for input or fails the run. That is why CI pipelines always supply every required variable through a -var-file or TF_VAR_ environment variable, never relying on the prompt.

Per-Environment Variable Files

The same code drives dev and prod by swapping the variable file: terraform apply -var-file=dev.tfvars versus -var-file=prod.tfvars. The configuration stays byte-for-byte identical across environments, and the only thing that differs is the inputs — which is exactly the property that makes a config reusable rather than copy-pasted per environment.

Sensitive Variables

Setting sensitive = true on a variable keeps its value out of plan and apply output, so a password passed in does not get echoed into a terminal or a CI log. It does not encrypt anything and it does not keep the value out of state — if the value flows into a resource attribute, it lands in the state file in plaintext regardless. sensitive is about display, not storage.