	In Browser
	StumbleUpon
	del.icio.us
	Google
	Google Buzz
	reddit
	LinkedIn

	Facebook
	Twitter
	Linkedin
	E-Mail

Terraform and IaC > Terraform Basics > Terraform Variables, Locals and Outputs

Terraform Variables, Locals and Outputs

Author: Venkata Sudhakar

Terraform variables make your configurations reusable and environment-agnostic. Instead of hardcoding values like region, instance size, or project ID directly in resource definitions, you define them as input variables with optional defaults and validation rules. The same Terraform configuration can then be applied to dev, staging, and production environments simply by supplying different variable values, without changing any resource code.

Terraform supports three types of values: input variables (var.) which are the inputs to a configuration that callers supply, local values (local.) which are computed intermediate values you define once and reuse throughout the configuration to avoid repetition, and output values which expose attributes of created resources so they can be consumed by other Terraform modules or used in CI/CD pipelines. Together, variables, locals, and outputs make Terraform configurations modular, DRY (Do not Repeat Yourself), and composable.

The below example shows a complete variables.tf, locals.tf, and outputs.tf for a multi-environment GCP deployment, demonstrating all variable types including string, number, bool, list, map, and object.

# variables.tf - Input variable definitions

variable "project_id" {
  description = "GCP project ID"
  type        = string
  # No default - must be supplied by caller
}

variable "environment" {
  description = "Deployment environment"
  type        = string
  default     = "dev"
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging or prod."
  }
}

variable "region" {
  description = "GCP region"
  type        = string
  default     = "us-central1"
}

variable "machine_type" {
  description = "Compute Engine machine type per environment"
  type        = map(string)
  default = {
    dev     = "e2-micro"
    staging = "e2-medium"
    prod    = "n2-standard-4"
  }
}

variable "enable_monitoring" {
  description = "Enable Cloud Monitoring agent on VMs"
  type        = bool
  default     = true
}

variable "allowed_ips" {
  description = "List of IPs allowed to reach the app"
  type        = list(string)
  default     = ["0.0.0.0/0"]
}

variable "db_config" {
  description = "Database configuration"
  type = object({
    tier      = string
    disk_size = number
  })
  default = {
    tier      = "db-f1-micro"
    disk_size = 10
  }
}

locals.tf and outputs.tf showing computed values and resource outputs,

# locals.tf - Computed intermediate values (not supplied by callers)
locals {
  # Common prefix for all resource names
  name_prefix = "${var.project_id}-${var.environment}"

# Pick machine type for the current environment from the map variable
  vm_machine_type = var.machine_type[var.environment]

# Common labels applied to all resources
  common_labels = {
    environment = var.environment
    project     = var.project_id
    managed_by  = "terraform"
    team        = "platform"
  }

# Derive zone from region
  zone = "${var.region}-a"

# DB disk size doubles in prod
  db_disk_size = var.environment == "prod" ? var.db_config.disk_size * 2 : var.db_config.disk_size
}

# outputs.tf - Values exposed after apply
output "vm_name" {
  description = "Name of the created VM"
  value       = google_compute_instance.app_server.name
}

output "vm_external_ip" {
  description = "External IP of the VM"
  value       = google_compute_instance.app_server.network_interface[0].access_config[0].nat_ip
}

output "bucket_name" {
  description = "Name of the GCS bucket"
  value       = google_storage_bucket.app_bucket.name
}

output "db_connection_name" {
  description = "Cloud SQL connection name for use in app config"
  value       = google_sql_database_instance.main.connection_name
  sensitive   = false
}

Using the locals in resource definitions and running apply for different environments,

It gives the following output,

# Dev apply:
local.name_prefix     = "my-project-dev"
local.vm_machine_type = "e2-micro"
local.db_disk_size    = 10

Apply complete! Resources: 3 added.

Outputs:
vm_name        = "my-project-dev-server"
vm_external_ip = "34.72.10.11"
bucket_name    = "my-project-dev-data"

# Prod apply:
local.name_prefix     = "my-project-prod"
local.vm_machine_type = "n2-standard-4"
local.db_disk_size    = 200  (100 * 2 for prod)

Apply complete! Resources: 3 added.

Outputs:
vm_name        = "my-project-prod-server"
vm_external_ip = "34.102.200.5"
bucket_name    = "my-project-prod-data"

# Validation error when wrong environment is supplied:
Error: Invalid value for variable
  environment must be dev, staging or prod.

Variable precedence order (highest to lowest):

1. Command-line -var and -var-file flags. 2. Environment variables prefixed with TF_VAR_ (e.g. TF_VAR_project_id). 3. terraform.tfvars or terraform.tfvars.json in the working directory. 4. *.auto.tfvars files. 5. Default values defined in the variable block. Variables with no default and not supplied through any of these methods will prompt interactively during plan and apply.

Send your comments, suggestions or queries regarding this site to [email protected].