Terraform — Part 5 — Variables, Outputs, and Locals

Introduction

Every resource block in this series so far has had its values written directly into it — a fixed region, a fixed filename, a fixed pet-name length. That works for a single throwaway example. It stops working the moment the same configuration needs to run against two environments, or the moment someone other than you needs to run it without editing the file first.

The variable Block

A variable block declares an input parameter. Its single label is the variable’s name:

variable "pet_length" {
  type        = number
  description = "Number of words in the generated pet name."
  default     = 2

  validation {
    condition     = var.pet_length >= 1 && var.pet_length <= 3
    error_message = "pet_length must be between 1 and 3."
  }
}

type constrains what kind of value is acceptable (string, number, bool, and structural types like list and map). description documents intent for anyone else reading the configuration. default is used whenever no other value is supplied. A nested validation block can reject a bad value outright with a clear error message, rather than letting it silently reach a resource and fail there instead.

Reference a variable anywhere in the configuration with var.<NAME>:

resource "random_pet" "server" {
  length = var.pet_length
}

Setting Variable Values

A variable can get its value from several places, and Terraform applies a fixed precedence when more than one source sets the same variable, from lowest to highest priority:

Marking a Variable Sensitive

Set sensitive = true on a variable holding a password, API key, or other secret, and Terraform redacts it from CLI output — plan and apply summaries show (sensitive value) instead of the real value:

variable "db_password" {
  type      = string
  sensitive = true
}

Local Values

A locals block assigns a name to an expression, computed once, for reuse elsewhere in the same configuration. Unlike a variable, a local never takes outside input — it’s purely a way to avoid repeating a calculation:

locals {
  greeting = "Server name: ${random_pet.server.id}"
}

Reference it with local.<NAME> — singular, unlike the plural locals block that defines it:

resource "local_file" "hello" {
  filename = "${path.module}/hello.txt"
  content  = local.greeting
}

Locals are most useful for naming conventions and derived values used in more than one place — computing a resource name pattern once and reusing local.resource_name everywhere, instead of repeating the same string interpolation in five different resource blocks.

The output Block

An output block surfaces a value after apply finishes — the piece of the workflow that answers “what did Terraform actually just build, and what do I need from it?”

output "pet_name" {
  description = "The generated pet name used as the server identifier."
  value       = random_pet.server.id
}

value is required and accepts any valid expression — a resource attribute, a local, a computed expression. description documents what the output represents. Setting sensitive = true on an output redacts it from the normal CLI summary the same way it does for a variable, though it’s still visible via terraform output -json or -raw when explicitly requested.

Terraform prints every root module output automatically at the end of a successful apply. To read one later without re-running apply:

# Print every output
terraform output

# Print just one output's raw value, unquoted
terraform output -raw pet_name

Putting It Together

Extending Part 4’s example with a variable, a local, and an output:

variable "pet_length" {
  type        = number
  description = "Number of words in the generated pet name."
  default     = 2
}

resource "random_pet" "server" {
  length = var.pet_length
}

locals {
  greeting = "Server name: ${random_pet.server.id}"
}

resource "local_file" "hello" {
  filename = "${path.module}/hello.txt"
  content  = local.greeting
}

output "pet_name" {
  description = "The generated pet name used as the server identifier."
  value       = random_pet.server.id
}

Nothing about the resources themselves changed. What changed is that the pet name’s length is now a parameter someone can override without editing the file, the greeting text is computed once instead of repeated, and the generated name is visible immediately after apply instead of requiring a manual look inside hello.txt.

Quick Reference Summary

Final Thoughts

Variables, locals, and outputs don’t add any new infrastructure capability on their own — they’re entirely about making configuration reusable and legible instead of a pile of hard-coded values. That distinction matters more as configurations grow, which is exactly the direction the rest of this series heads.