Terraform Configuration Basics: Providers, Resources, and Variables

Terraform is a tool that lets you describe your entire IT infrastructure — servers, databases, networking rules — in plain text files. Those files use a specific language called HashiCorp Configuration Language (HCL). The language has several main building blocks: providers, resources, data sources, variables, and outputs. For TF-003, you must understand each one precisely.

Let us start with providers. A provider is a plugin that teaches Terraform how to talk to a particular platform. The platform could be a public cloud like Amazon Web Services (AWS), Microsoft Azure, or Google Cloud, or it could be a smaller service like a DNS provider or a database-as-a-service. In technical terms, the provider knows the Application Programming Interface (API) of that platform — the set of rules and commands the platform understands. Without the provider, Terraform would have no idea how to create a virtual machine on AWS because it would not speak 'AWS language'.

You declare a provider in your configuration with a block that looks like this:

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

The name inside the quotes — 'aws' — tells Terraform to download and use the AWS provider. The configuration inside the curly braces sets any credentials or default settings, such as which geographical region to use. You can have multiple providers in one configuration, for example, one for AWS and one for Azure, each managing its own resources.

Now resources. A resource is a single piece of infrastructure you want Terraform to create, update, or destroy. If the provider is the translator, the resource is the thing you are ordering. Every resource belongs to exactly one provider. For example, an AWS virtual machine is declared like this:

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

Here, 'aws_instance' is the resource type. The label after it, 'web_server', is a local name you choose so you can refer to this resource elsewhere in your code. Inside the block, you set properties such as the Amazon Machine Image (AMI) identifier and the instance size. Terraform reads this, talks to the AWS provider, and says: 'Please create one virtual server with these exact settings.'

The key insight: resources are declarative. You write what you want, not how to do it. Terraform figures out the steps. If the resource already exists and its settings match your code, Terraform does nothing. If settings differ, Terraform changes the resource to match your code. If the resource is missing, Terraform creates it. If you delete the resource block, Terraform destroys the real-world resource.

Data sources are cousins of resources. While a resource creates something new, a data source reads information about something that already exists outside Terraform. For example, you might use a data source to fetch the latest available AMI ID for Ubuntu, rather than hardcoding it:

data "aws_ami" "ubuntu" { most_recent = true owners = ["099720109477"] }

The syntax is 'data' instead of 'resource', followed by the type and a local name. Terraform queries the provider for the information and stores it, so you can use it elsewhere. Data sources do not create, modify, or destroy anything — they just fetch data.

Variables make your configuration reusable. Instead of hardcoding a value like 't2.micro' in multiple places, you define a variable once and use it everywhere. A variable is declared like this:

variable "instance_type" { description = "Type of EC2 instance" type = string default = "t2.micro" }

You then use it by writing var.instance_type. When someone else wants to use your code, they can override the default value by setting the variable in a separate file (terraform.tfvars) or via command line. This means you can write one set of Terraform files for a test environment and reuse the same files for production — just change the variable values.

Outputs are like the report card for your Terraform run. An output block tells Terraform to display a specific piece of information after applying the configuration:

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

When you run terraform apply, you see the IP address printed in the terminal. Outputs are also useful for passing information between different Terraform configurations (called root modules).

How do all these pieces work together? When you run terraform init, Terraform downloads the provider plugins you declared. When you run terraform plan, it compares your configuration against the real-world state saved in a state file (stored locally or remotely) and shows what will change. When you run terraform apply, it executes those changes. The whole process is called 'Infrastructure as Code' (IaC) — managing infrastructure through code that can be versioned, reviewed, and automated.

Before Terraform, IT teams used to log into cloud consoles, click buttons, and inevitably make mistakes. They might also write scripts (like shell scripts or Python) that were brittle and hard to maintain. Terraform replaced that with a standardised, human-readable language that works across clouds. The exam expects you to know the difference between these blocks and when to use each one.

Imagine you work for a small e-commerce company, 'ShopQuick', that is moving its website from a physical server in a closet to the cloud. Your boss says: 'We need two web servers, one database, and a load balancer to distribute traffic.' A few years ago, you would have clicked around the AWS Management Console for an hour, and if you made a mistake — say, made a server public when it should be private — your company's data could be exposed.

Instead, you write a Terraform configuration. You start by declaring the AWS provider so Terraform knows who to talk to:

provider "aws" { region = "us-west-2" }

Then you declare a variable for the instance type, because you might want to upgrade the servers later without changing the main code:

variable "web_instance_type" { description = "Instance type for web servers" type = string default = "t3.medium" }

Now you define the resources. First, the two web servers. You might use a count or for_each (advanced patterns), but for simplicity, you write two separate resource blocks, or better, one block using count = 2. You also create a security group (a firewall) that allows HTTP traffic. Then you create the database server using a separate resource block for an RDS instance. Finally, you create an Application Load Balancer (ALB) and attach the web servers to it.

To make the configuration reusable, you add outputs for the load balancer's DNS name, so your dev team can update the website's CNAME record in their DNS provider.

At the end, you run terraform plan. It prints a list of everything it will create. You review it with your boss and catch a mistake: the database security group is open to the whole internet. You fix the code, run plan again, and only then run apply. Terraform creates all five resources in the correct order — the load balancer first because the servers need to register with it, the security groups before the servers because the servers need the firewall rules to exist.

A month later, traffic spikes. You need bigger servers. You change the variable default from 't3.medium' to 't3.large' and run apply again. Terraform detects that the instance type has changed, so it replaces each server one at a time (if you configured it properly) without downtime.

This is what an IT professional actually does with Terraform every day: write code, review it, apply it, and iterate. The exam focuses on whether you understand the syntax and purpose of each block, because in real life you will be reading and writing them constantly.