Writing and Organizing Terraform Configurations

Terraform configurations are written in a language called HCL (HashiCorp Configuration Language). HCL is designed to be human-readable: you do not need to be a programmer to understand it. Every configuration file ends in either .tf or .tf.json. The most common is .tf, which looks like regular text with labels and brackets.

At its simplest, a configuration has three building blocks: resources, providers, and blocks. A *resource* is the thing you want to create — for example, an AWS EC2 instance (a virtual server), an Azure storage account, or a DNS record. A *provider* is the plugin that lets Terraform talk to a specific cloud or service (like AWS, Azure, or Google Cloud). A *block* is a unit of code that starts with a keyword followed by curly braces {}.

Here is a real example:

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

In this example, provider "aws" is a block that tells Terraform to use the AWS provider plugin and sets the region to us-east-1. resource "aws_instance" "web_server" is a block that creates a single EC2 instance. The ami (Amazon Machine Image) is like a blueprint for what operating system the server should run, and instance_type defines how powerful the server should be.

Why do we need organisation? A real-world infrastructure might have dozens of resources: several servers, a database, a load balancer, network rules, and storage buckets. Shoving all of that into one giant file is messy and hard to read. That is why Terraform lets you split your configuration into multiple files. For example, you might have:

This separation is called “modular organisation”. It is not required — Terraform will load every .tf file in the folder — but it makes your configuration easier to read, update, and share with a team.

A critical concept is *variables*. Instead of writing a specific AMI ID directly inside the resource block, you define a variable in variables.tf:

variable "instance_type" {
  description = "Size of the server"
  type        = string
  default     = "t2.micro"
}

Then in main.tf, you reference it:

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.instance_type
}

If your team decides to use larger servers, you only change the value in one place — the terraform.tfvars file — instead of editing every resource block.

*Outputs* are like the takeaway from your recipe: they show you the result. After Terraform creates the server, you might want to see its public IP address. In outputs.tf you write:

output "public_ip" {
  value = aws_instance.web_server.public_ip
}

When you run terraform apply, Terraform prints this value to the terminal.

Finally, the *backend* configuration tells Terraform where to store the state file (a record of what it created). By default, it saves to your local disk, but for teams, you often use a remote location like an S3 bucket (AWS) or Azure Storage. The backend configuration is its own block, usually in a file called backend.tf.

To summarise: writing and organising Terraform configurations is about using HCL to describe your infrastructure in a structured, reusable way. You break your configuration into multiple files (main.tf, variables.tf, outputs.tf, terraform.tfvars), use variables to avoid hardcoding, and use outputs to see what you created. This approach replaces manual clicks in a cloud console, reduces errors, and makes your infrastructure auditable.

Imagine you work for a small e-commerce company that sells handmade furniture. Your boss tells you, “We need a new web server to handle increased traffic during the holiday season.” In the old way, you would log into the AWS Management Console, click “Launch Instance,” select an AMI, choose an instance type, configure security groups, and wait for the server to spin up. You would repeat these exact same clicks every time you needed a new server — and if you missed a setting, you might accidentally expose the database to the public internet.

With Terraform, you do this once. You open your code editor and navigate to your team’s Terraform project folder. Inside, you see the following files:

Now, when the boss needs a second server for a different region, you do not start from scratch. You create a new folder called eu-west-1 and copy the same files. You change only the terraform.tfvars to point to a different region and a different AMI for that region. You run terraform init (to download the provider plugin) and then terraform apply. Two minutes later, a new server is live in Europe — with consistent settings.

Later, your colleague realises the security group (a firewall rule) is too permissive. Instead of logging into the console, hunting down each server, and manually updating the rule, they edit the main.tf file, change the security group block, run terraform apply, and every server gets the fix automatically.

This scenario shows what an IT professional actually does: they write configuration files as code, store them in a version control system like Git (so everyone can see the history of changes), and use Terraform commands to apply or destroy resources. The exam expects you to understand that this is not just about syntax — it is about the workflow of defining, sharing, and updating infrastructure in a repeatable way.