Terraform HCL — Variables, Outputs, Locals, and Expressions Explained

Overview and What You Will Learn

A Terraform configuration that hardcodes every value — region, instance type, bucket name, environment tag — is a configuration you can only use once. The moment you need a second environment, you copy the entire folder, change twenty values, and now maintain two near-identical codebases. When a security group rule needs updating, you change it in two places. Miss one, and your environments drift.

Terraform variables are the solution. They turn your configuration into a template — write the infrastructure once, fill in the blanks differently for dev, staging, and production. This is the exact pattern Zerodha uses to run the same Terraform code across three environments without duplication.

In this lab you will master every HCL building block that makes configurations reusable and maintainable:

• Input variables — parameters that callers pass in, with types, defaults, and validation
• Output values — infrastructure attributes exposed after apply for humans and other configs to read
• Local values — intermediate calculations you write once and reference many times
• Expressions — conditionals, for loops, and built-in functions that add logic to your config
• Dynamic blocks — generating repeated nested blocks programmatically from a list

By the end, you will refactor a hardcoded configuration into a fully parameterised one that works across any environment with a single variable file.

Why This Matters in Production

At Zerodha, one Terraform configuration manages infrastructure for dev, staging, and production. The resources are identical in structure — same VPC layout, same security group rules, same RDS schema. Only the values differ: t3.micro in dev, t3.large in prod; 20 GB storage in dev, 500 GB in prod; deletion protection off in dev, on in prod.

Variables make this possible. When a new port needs to be opened in the security group, an engineer changes one variable definition. Terraform applies it to all three environments through a CI/CD pipeline. No copy-paste. No missed environments. No drift.

Without variables, the team would maintain three copies of the same configuration — and every change would need to be made in triplicate, with a high chance of divergence.

Core Principles

Detailed Step-by-Step Practical Lab

This lab refactors a hardcoded configuration into a fully parameterised one. Start with this rigid configuration and improve it step by step.

Starting Point — The Hardcoded Configuration (Do Not Copy This Into Production)

This config cannot be reused. Every environment change means editing the file directly. By the end of this lab, a single terraform apply -var-file=prod.tfvars will deploy the same code to production with the correct values.

Part 1 — Input Variables

Input variables are the parameters of your configuration. They separate the what (resource structure) from the how (specific values). Declare every variable in variables.tf.

Primitive Types

Collection Types

Structural Types

Validation — Catching Mistakes Before Plan

Part 2 — Passing Variable Values

Variables can be set in four ways. Terraform applies them in priority order — highest wins.

Variable Precedence — Highest to Lowest

Part 3 — Output Values

Outputs expose specific infrastructure attributes after apply. They serve two purposes: printing useful information for engineers reading the terminal, and making values available for other Terraform configurations to read via remote state.

Part 4 — Local Values

A local value is a named expression you compute once and reference many times. Locals are not input parameters — callers cannot set them. They are internal to your configuration.

Use locals when:

• You write the same expression ("${var.project}-${var.environment}") in more than one place
• An expression is complex and naming it makes the intent clear
• You want to build a common_tags map once and attach it to every resource

Part 5 — Expressions and Built-In Functions

Part 6 — For Expressions

For expressions transform lists and maps. They are like list comprehensions in Python or Array.map in JavaScript — but for HCL.

Part 7 — Dynamic Blocks

Dynamic blocks generate repeated nested blocks from a list or map variable. Without them, you would write one ingress block per port — hardcoded, inflexible.

Part 8 — The Refactored Configuration

Here is the complete refactored main.tf using all the concepts above — the hardcoded version from the start of the lab, now fully parameterised:

Apply for dev environment:

Apply the identical code for prod — only values change:

Production Best Practices and Common Pitfalls

• Write a description for every variable without exception. Engineers reading a prod.tfvars file six months later have no other documentation. The description field is the inline docs.

• Always add validation blocks to variables with restricted values. An invalid environment name caught at terraform plan time (before any API calls) saves debugging a confusing apply failure. Use contains() for enums, regex() for format checks, length() for size limits.

• Never put secrets in .tfvars files that go into Git. Use TF_VAR_ environment variables for passwords and API keys. In CI/CD, pull secrets from Vault or AWS Secrets Manager and export them as TF_VAR_ before running Terraform.

• Use sensitive = true for secret variables and outputs. This hides values from terminal output and plan logs. It does NOT encrypt them in the state file — that requires a properly secured remote backend.

• Use locals instead of repeating the same expression. The pattern "${var.project}-${var.environment}" written in eight resource blocks is eight places to update when the naming convention changes. Write it once in locals.

• Use for_each with maps instead of count with lists. If you use count = 3 to create three S3 buckets and later remove the middle one from the list, Terraform renumbers everything and may destroy and recreate buckets you did not intend to touch. for_each with a map gives each instance a stable key.

• Commit per-environment .tfvars files to Git. Files like dev.tfvars, staging.tfvars, and prod.tfvars are configuration, not secrets. Having them in Git gives you a clear audit trail of what values each environment uses and when they changed.

• Use terraform console to test expressions before putting them in config. The console gives you an interactive HCL evaluator — type upper("hello") or cidrsubnet("10.0.0.0/16", 8, 3) to test your expression before adding it to a resource argument.

Quick Reference and Troubleshooting Commands