← Back to Home
🏗️

Configuration & Variables

From hard-coded values to clean, reusable, parameterised infrastructure.

11 min read📚DevOps Fundamentals

Hard-coding values everywhere makes configs impossible to reuse. Terraform gives you variables for inputs, outputs for results, and references to wire resources together — so one clean config can build many environments.


🎯 Learning Objectives

By the end of this lesson you will:


Input Variables

Variables turn hard-coded values into parameters:

hcl
variable "region" {
type    = string
default = "us-east-1"
}

variable "instance_count" {
type    = number
default = 2
}

variable "environment" {
type = string
# no default → Terraform will prompt or require a value
}

Use them with var.<name>:

hcl
provider "aws" {
region = var.region
}

💡 Type your variables

Always give variables a type (string, number, bool, list, map). It catches mistakes early and documents what each variable expects.


Supplying Variable Values

Terraform reads variables from several sources, in order of precedence (later wins):

Source Example
Defaults in the variable block default = "us-east-1"
terraform.tfvars file region = "eu-west-1"
-var on the command line terraform apply -var="region=ap-south-1"
Environment variables TF_VAR_region=us-west-2

A typical terraform.tfvars:

hcl
region         = "eu-west-1"
instance_count = 3
environment    = "production"

⚠ Keep secrets out of tfvars in Git

Never commit real credentials or secrets in .tfvars. Use environment variables (TF_VAR_...) or a secrets manager, and add sensitive .tfvars files to .gitignore.


Outputs

Outputs surface useful values after an apply — like a server’s IP or a bucket’s name:

hcl
output "bucket_name" {
value = aws_s3_bucket.data.bucket
}

output "bucket_arn" {
value = aws_s3_bucket.data.arn
}
bash — 80×24
student@devops:~$terraform output

Outputs are also how one Terraform configuration hands values to another.


Referencing Resources

The real power: use one resource’s attributes when defining another. Terraform automatically works out the correct creation order from these references.

hcl
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
vpc_id     = aws_vpc.main.id    # reference the VPC
cidr_block = "10.0.1.0/24"
}

Because the subnet references aws_vpc.main.id, Terraform knows to create the VPC first. This dependency graph is built automatically — you never sequence things by hand.

💡 Implicit dependencies

Referencing another resource creates an implicit dependency. This is the preferred way to order resources — Terraform figures out the graph for you.


🧪 Hands-on Lab

📝

Parameterise a Config

  1. Create a variable filename with a default, used by a local_file resource
  2. Add an output that returns the file’s content
  3. Override the filename with -var on apply

🧠 Knowledge Check

Knowledge Check

How do you reference an input variable named 'region' in your configuration?

Knowledge Check

What happens when one resource references another resource's attribute?


💼 Interview Preparation

Interview Q&A

How would you use one Terraform configuration to manage multiple environments (dev, staging, prod)?


Summary

You can now parameterise configs with variables, return values with outputs, and wire resources together with references that build Terraform’s dependency graph automatically. Next, we tackle the most important operational topic: state.

Up Next

State & Remote Backends

You've mastered this lesson. Continue your journey to becoming a DevOps Engineer.

Start Next Lesson