Parameterizing Configurations with Input Variables

Welcome to this lesson on Terraform variable blocks. In this guide you’ll learn what Terraform input variables are, why they matter, and how to use them to make configurations flexible and reusable across environments (production, QA, dev). By the end you’ll know how to declare variables, supply values, and apply best practices for multi-environment infrastructure as code. Let’s jump in.

The problem with hard-coded values

When infrastructure for multiple environments is nearly identical, hard-coded values force you to duplicate resources across files. That duplication increases maintenance effort, creates configuration drift, and raises the risk of human error. Example of repeated resources with hard-coded values:

resource "azurerm_resource_group" "prd" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_virtual_network" "dv" {
  name                = "example-network"
  resource_group_name = "example-resources"
  location            = "West Europe"
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_mssql_database" "db1" {
  name      = "example-db"
  server_id = "server_db"
  collation = "sql_general"
}

resource "azurerm_resource_group" "dev" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_virtual_network" "dev" {
  name                = "example-network"
  resource_group_name = "example-resources"
  location            = "West Europe"
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_mssql_database" "db2" {
  name      = "example-db"
  server_id = "server_db"
  collation = "sql_general"
}

resource "azurerm_resource_group" "test" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_virtual_network" "tst" {
  name                = "example-network"
  resource_group_name = "example-resources"
  location            = "West Europe"
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_mssql_database" "db3" {
  name      = "example-db"
  server_id = "server_db"
  collation = "sql_general"
}

Common problems when repeating configuration like this:

Maintenance burden: single change must be applied in many places.
Risk of human error: accidental copy/paste of production values.
Configuration drift: environments diverge over time.
Onboarding friction: new team members face multiple near-duplicate files.
Violates DRY (Don’t Repeat Yourself) principles.

How variables solve this

Variables let one shared configuration accept environment-specific inputs. Teams provide variable values (via files, CLI, or environment variables) and the single codebase produces the appropriate resources for each environment. Refactored resources that reference variables:

resource "azurerm_resource_group" "prd" {
  name     = var.rg_name
  location = var.rg_location
}

resource "azurerm_virtual_network" "dv" {
  name                = var.net_name
  resource_group_name = var.net_rg
  location            = var.net_location
  address_space       = var.net_cidr
}

resource "azurerm_mssql_database" "db1" {
  name      = var.mssql_name
  server_id = var.server_id
  collation = var.collation
}

With this approach:

Use production.tfvars, qa.tfvars, and dev.tfvars to supply environment-specific values.
Or override variables with -var on the CLI or with TF_VAR_<NAME> environment variables.
One configuration becomes a single source of truth, reducing errors and improving maintainability.

What is a variable block?

A variable block declares an input to your Terraform configuration. It documents intent (via description), constrains values (type), and can provide a default (default). Variables can be simple scalars or complex structures.

A presentation slide titled "Variable Block" with a photo of glossy purple jigsaw puzzle pieces on the left. The right side explains that variable blocks let you parameterize inputs to make configurations reusable and avoid hardcoding values.

Key characteristics of variable blocks:

Dynamic inputs that make configurations reusable.
Centralized management of environment values.
Type validation to catch mistakes early.

A simple string variable:

variable "vsphere_datacenter" {
  description = "Name of datacenter"
  type        = string
  default     = "prd-workload-dc"
}

A variable that holds a list of strings:

variable "vsphere_networks" {
  description = "List of networks"
  type        = list(string)
  default     = [
    "VM Network",
    "Management Network"
  ]
}

These definitions give you:

A human-readable description for documentation and plan output.
An explicit type so Terraform can validate input.
An optional default so values aren’t mandatory at runtime.

If you omit the type argument, Terraform will infer the variable type from the value you provide. Explicit types are recommended for clarity and earlier validation.

Anatomy of a variable block

A variable block follows a predictable structure:

Name: referenced in config as var.<name>.
Description: purpose and expected values.
Type: one of string, number, bool, list(...), map(...), object(...), tuple, etc.
Default: optional fallback if no value is supplied.

This structure scales from simple scalars to complex objects and makes documenting inputs straightforward.

Terraform variable types (cheatsheet)

Type	Purpose	Example
`string`	Single string value	`variable "env" { type = string }`
`number`	Numeric values	`variable "count" { type = number }`
`bool`	True/false flags	`variable "enabled" { type = bool }`
`list(<type>)`	Ordered list of values	`variable "subnets" { type = list(string) }`
`map(<type>)`	Key/value map	`variable "tags" { type = map(string) }`
`object({...})`	Structured object with named attributes	`variable "server" { type = object({ name = string, size = string }) }`
`tuple([...])`	Fixed-length heterogeneous list	`variable "coords" { type = tuple([number, number]) }`

Note: In the table above, examples containing curly braces or angle brackets are wrapped in backticks to avoid MDX parsing issues.

Ways to provide variable values

You can supply values to Terraform variables using several mechanisms. Below is a summary of common methods and a short example for each.

Method	Description	Example
`terraform.tfvars` / `*.tfvars`	File with variable assignments loaded automatically	`cat production.tfvars`
`-var-file`	Explicit var file on the CLI	`terraform apply -var-file="production.tfvars"`
`-var`	Single variable override on the CLI	`terraform apply -var="env=prod"`
Environment variables	Prefix `TF_VAR_` to the variable name	`export TF_VAR_env=prod`
`default` in variable block	Fallback value if no other value is provided	`variable "env" { default = "dev" }`
Workspace-specific overrides	Use workspaces to change behavior per workspace	(see Terraform workspaces docs)

Example production.tfvars:

rg_name    = "example-resources-prd"
rg_location = "West Europe"
net_cidr   = ["10.0.0.0/16"]
mssql_name = "example-db-prd"

Example CLI usage:

terraform init
terraform plan -var-file="production.tfvars"
terraform apply -var-file="production.tfvars"

Precedence (higher to lower):

CLI -var or -var-file (explicit on command)
Environment variables (TF_VAR_<NAME>)
terraform.tfvars or files named *.auto.tfvars
default in variable block

Best practices

Give variables descriptive names and include description.
Explicitly declare type for early validation.
Prefer *.tfvars or -var-file for environment-specific values (keeps secrets out of VCS).
Keep secrets in a secure secret store and inject them via CI or environment variables (do not commit secrets to source control).
Group related values with object or map types for clarity.
Use a consistent variable file naming convention: production.tfvars, staging.tfvars, dev.tfvars.
Document required variables in a README for each module.

Next steps

You’ll want to explore:

Available complex types in detail (object, tuple, nested map).
How to pass sensitive values securely and use sensitive = true.
How variable scoping works across modules.
Organizing variable files and inputs for multi-team workflows.

Links and references:

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Parameterizing Configurations with Input Variables

The problem with hard-coded values

How variables solve this

What is a variable block?

Anatomy of a variable block

Terraform variable types (cheatsheet)

Ways to provide variable values

Best practices

Next steps

Watch Video

​The problem with hard-coded values

​How variables solve this

​What is a variable block?

​Anatomy of a variable block

​Terraform variable types (cheatsheet)

​Ways to provide variable values

​Best practices

​Next steps

Watch Video

The problem with hard-coded values

How variables solve this

What is a variable block?

Anatomy of a variable block

Terraform variable types (cheatsheet)

Ways to provide variable values

Best practices

Next steps