Enhancing Code with Dynamic Values

Keeping Terraform code reusable and avoiding hard-coded values is essential. This article expands that idea by showing how to use dynamic values — combining variables, data sources, locals, and interpolation — to build names, tags, and other attributes at runtime instead of typing them manually. Dynamic configurations are more adaptable, easier to update, and far less error-prone. Small changes can make Terraform code significantly more powerful. Read on to learn practical patterns and see hands-on examples.

Variables recap

Variables provide dynamic inputs so you avoid hard-coding values in Terraform. Terraform supports several variable types and you can set variables via defaults, environment variables, *.tfvars files, or the CLI. Using variables keeps configuration DRY and makes it straightforward to target multiple environments or accounts with the same codebase.

Useful quick reference: variable types and typical use cases.

Variable type	Typical use case	Example
`string`	Names, ARNs, regions	`variable "region" { type = string }`
`number`	Port numbers, sizes	`variable "instance_count" { type = number }`
`bool`	Feature flags	`variable "enable_monitoring" { type = bool }`
`list(string)`	Ordered lists (subnets, AZs)	`variable "subnets" { type = list(string) }`
`map(string)`	Named key/value sets (tags)	`variable "tags" { type = map(string) }`

For the official variable docs, see: https://www.terraform.io/docs/language/values/variables

Data sources recap

Data sources allow Terraform to read provider-specific information — for example, current region, account details, or the latest AMI — and bring that information into your configuration. Data sources do not create or modify infrastructure; they make external or existing information available for interpolation in resources.

A presentation slide titled "Data Sources - Reap" that explains pulling external information into Terraform. It shows three columns labeled "Provider-Specific Info," "Common Use Cases," and "No Changes" with brief descriptions.

See the Terraform docs for data sources: https://www.terraform.io/docs/language/data-sources

Combining variables and data sources

The power of dynamic Terraform code comes from combining variables, data sources, locals, interpolation, and meta-arguments. Instead of embedding static values, you pull values in at runtime and compose them into resource attributes. This creates flexible, environment-aware infrastructure that’s easy to maintain.

What to avoid: hard-coded values

Hard-coded values reduce reuse and increase the chance of errors when values must change across many resources. Avoid this pattern:

resource "aws_instance" "example" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
}

resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "hardcoded-vpc"
  }
}

resource "github_repository" "example" {
  name        = "my-static-repo"
  description = "A static name"
  visibility  = "public"
}

resource "github_team" "example" {
  name        = "hardcoded-team"
  description = "A team with a name"
}

Problems you’ll encounter with this approach:

Changing the AMI or CIDR requires editing many resource blocks.
Names may collide across environments or accounts.
Reusing code across teams or regions becomes harder.

Dynamic example: use data, variables, locals, interpolation

Below is a practical replacement that discovers the AMI dynamically and composes names and tags from variables and locals. This pattern is reusable across environments:

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
}

locals {
  instance_type = "t3.micro"
  env           = "production"
}

variable "app" {
  type    = string
  default = "xyz"
}

resource "aws_instance" "example" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = local.instance_type

  tags = {
    Name = "${var.app}-${local.env}-server"
  }
}

variable "vpc_cidr" {
  type    = string
  default = "10.0.0.0/16"
}

variable "network" {
  type    = string
  default = "main"
}

data "aws_region" "current" {}

resource "aws_vpc" "example" {
  cidr_block = var.vpc_cidr

  tags = {
    Name = "vpc-${local.env}-${data.aws_region.current.name}-${var.network}"
  }
}

Key points:

AMI discovery uses data.aws_ami.ubuntu instead of a fixed AMI ID.
local.instance_type centralizes the instance type so it’s easy to change once.
Tags and resource names are constructed via interpolation to include var.app, local.env, and the current region.

Interpolation (string insertion and evaluation)

Interpolation evaluates expressions and inserts results into strings. Classic Terraform syntax uses ${...} — show these examples as code so MDX does not try to evaluate them during rendering.

variable "name" {
  type    = string
  default = "Bryan"
}

locals {
  greeting     = "Hello, ${var.name}!"
  introduction = "My name is ${var.name}, I'm your instructor!"
}
# Evaluates to: Hello, Bryan!
# Evaluates to: My name is Bryan, I'm your instructor!

Terraform 0.12+ supports richer expressions. While ${} is still valid, you can also use direct expressions in many contexts (for example: local.greeting = "Hello, ${var.name}!" vs. local.greeting = "Hello, " + var.name). Use the style that keeps your code readable.

Using data lookups and variables together

A common pattern is to combine data sources and variables to produce predictable, unique resource names. Examples below show a server name that includes the current region and environment, and a globally unique S3 bucket name using the AWS account ID.

variable "environment" {
  type    = string
  default = "dev"
}

data "aws_region" "current" {}

data "aws_caller_identity" "current" {}

locals {
  name        = "server-${data.aws_region.current.name}-${var.environment}"
  bucket_name = "s3-${data.aws_caller_identity.current.account_id}-backups"
}
# Example evaluated value: locals.name -> server-us-east-1-dev
# Example evaluated value: locals.bucket_name -> s3-9876543210-backups

S3 bucket names are globally unique. Including account identifiers, environment names, or other unique values via interpolation helps avoid naming collisions.

Why this matters

Designing resources to read values from variables and data blocks gives several practical benefits:

Reuse the same Terraform code for multiple environments (dev, staging, prod) by supplying different variables or switching workspaces.
Avoid repetitive edits across many resources when values change.
Generate predictable, environment-specific names that reduce manual errors and naming collisions.

Hands-on lab

Practice these patterns by editing the provided Terraform files in the lab directories. The project structure includes provider-specific folders and sample files:

lab_03_working_with_variables_and_dependencies
lab_04_managing_multiple_resources
lab_05_working_with_state_data_sources
lab_06_making_code_dynamic_and_reusable
AWS
AZURE
GITHUB
github.md
main.tf
providers.tf
variables.tf

Steps to practice:

Choose a provider folder (AWS, AZURE, or GITHUB).
Replace hard-coded values with variables and provide suitable defaults or *.tfvars.
Add data sources to query provider information (region, account ID, AMIs).
Use locals and interpolation to compose resource names and tags.

Tips:

Use terraform plan to preview how your interpolated names and tags evaluate.
When naming globally unique resources (S3, DNS), include account- or workspace-specific values.

Summary

Variables, locals, data sources, and interpolation let you write reusable, flexible Terraform configurations. Avoid hard-coded values and instead compose strings dynamically to make infrastructure code maintainable across environments and accounts. Practice the examples above to gain hands-on experience with these core patterns. Further reading and references:

Terraform variables and outputs: https://www.terraform.io/docs/language/values/variables
Terraform data sources: https://www.terraform.io/docs/language/data-sources
AWS AMI filtering examples: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html

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

Enhancing Code with Dynamic Values

Variables recap

Data sources recap

Combining variables and data sources

What to avoid: hard-coded values

Dynamic example: use data, variables, locals, interpolation

Interpolation (string insertion and evaluation)

Using data lookups and variables together

Why this matters

Hands-on lab

Summary

Watch Video

Practice Lab

​Variables recap

​Data sources recap

​Combining variables and data sources

​What to avoid: hard-coded values

​Dynamic example: use data, variables, locals, interpolation

​Interpolation (string insertion and evaluation)

​Using data lookups and variables together

​Why this matters

​Hands-on lab

​Summary

Watch Video

Practice Lab

Variables recap

Data sources recap

Combining variables and data sources

What to avoid: hard-coded values

Dynamic example: use data, variables, locals, interpolation

Interpolation (string insertion and evaluation)

Using data lookups and variables together

Why this matters

Hands-on lab

Summary