Learn Terraform - HCL Syntax Anatomy & Core Workflow

#Introduction

In episode 1, we discussed the long history of why Terraform was born: from inconsistent manual ClickOps, fragile imperative shell scripting, to declarative Infrastructure as Code — and why Terraform with its state management and dependency graph became the primary choice in the modern world. Well, in this episode 2, we'll start touching real code.

In this episode we'll discuss two foundations you'll use in every remaining episode of this series. First, the HCL syntax anatomy (HashiCorp Configuration Language) — Terraform's configuration language — starting from block structure, arguments, and identifiers. Second, the four core workflow steps of Terraform: terraform init, terraform plan, terraform apply, and terraform destroy. These two foundations are like learning "the alphabet and grammar" before writing a long essay: without mastering them, the following episodes (providers, resources, variables, state, modules) will feel like reading a book without knowing the letters.

Why is this important in the real world? Because this is the workflow that engineering teams around the world execute hundreds of times every day — including in CI/CD pipelines we'll discuss in episode 13. Understanding what happens behind each command will differentiate you from an operator who just "runs it" into an engineer who can debug and explain Terraform's behavior.

#HCL Syntax Anatomy

HCL was designed with one philosophy: easy to read for humans, easy to understand for machines. Before writing configuration, let's break down the three core concepts that form every .tf file: Block, Argument, and Identifier.

#Block: The Main Structure

A Block is the main unit in HCL. It starts with a keyword, followed by label pairs, then content wrapped in curly braces { }. Think of a block as a "box" that holds configuration for one specific thing.

resource "aws_instance" "web" {
  # block content: argument
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}

The structure above reads as: I declare a resource of type aws_instance named web. The general form is:

<block_type> "<label_1>" "<label_2>" {
  argument = value
}

The number of labels varies depending on the block type:

#Argument: Setting Values

An Argument is a key-value pair inside a block. It's the "material" that configures the block. In the resource "aws_instance" "web" block, the ami and instance_type arguments tell Terraform the desired instance specs.

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
 
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

Notice that argument values can be simple (string, number, boolean) or complex (list, map, even nested blocks like tags). Arguments can also reference other resources — this is the basis of the automatic dependency graph discussed in episode 1.

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.app.id
}

The aws_subnet.app.id reference is the attribute reference syntax: aws_subnet (block type) → app (name) → id (exported attribute). As soon as Terraform sees this reference, it automatically creates a dependency: the instance waits for the subnet to be created first.

#Identifier: Names That Give Meaning

An Identifier is the label you give to name a block — in the examples above, web, app, and ubuntu. Identifiers serve two roles:

1. Unique within scope — two resources of the same type can't share the same identifier.
2. Reference address — the identifier becomes how we call that resource from other resources (aws_instance.web.public_ip).

#Our First Configuration

Time to practice. As a first safe and free example, we'll use the random provider (built-in by HashiCorp, no cloud account needed) and the local provider to write files on your laptop. This example lets you experience Terraform's entire workflow without any cost risk.

Create a new project folder, then fill in the following main.tf:

terraform {
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.6"
    }
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
  }
}
 
resource "random_id" "server_id" {
  byte_length = 4
}
 
resource "local_file" "server_info" {
  filename = "server.txt"
  content  = "Server ID: ${random_id.server_id.hex}\n"
}

What's happening in this code?

• The terraform block declares the providers needed — this will be studied in depth in episode 3.
• The resource "random_id" "server_id" block generates a random 4-byte ID (8 hex characters).
• The resource "local_file" "server_info" block writes a server.txt file containing that random ID. Notice the ${random_id.server_id.hex} reference — this is the interpolation that connects the two resources.

#The Four Core Workflow Steps

Now comes the heart of this episode. Terraform has four main commands that form the full lifecycle of a project. Let's discuss them one by one, complete with their output.

#1. terraform init

The first command that must be run in any Terraform project. Its job: download the declared providers, initialize the backend (where state is stored), and prepare modules. Without init, other commands will refuse to run with the Missing required provider message.

terraform init
 
Initializing the backend...
 
Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.5"...
- Finding hashicorp/random versions matching "~> 3.6"...
- Installing hashicorp/local v2.5.2...
- Installed hashicorp/local v2.5.2 (signed by HashiCorp)
- Installing hashicorp/random v3.6.3...
- Installed hashicorp/random v3.6.3 (signed by HashiCorp)
 
Terraform has been successfully initialized!
 
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

#2. terraform plan

terraform plan is a preview of changes without touching the real environment. Terraform compares three things: your HCL code, the state file, and the actual condition in the cloud. The result is a list of operations that would be performed if you ran apply.

terraform plan
 
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create
 
Terraform will perform the following actions:
 
  # local_file.server_info will be created
  + resource "local_file" "server_info" {
      + content              = "Server ID: 1a2b3c4d5e6f\n"
      + content_base64sha256 = (known after apply)
      + filename             = "server.txt"
      + id                   = (known after apply)
    }
 
  # random_id.server_id will be created
  + resource "random_id" "server_id" {
      + b64_std     = (known after apply)
      + b64_url     = (known after apply)
      + byte_length = 4
      + id          = (known after apply)
    }
 
Plan: 2 to add, 0 to change, 0 to destroy.

Notice the three symbols that appear in the plan output — these are Terraform's "universal language":

The summary line at the very bottom — Plan: 2 to add, 0 to change, 0 to destroy — is the summary of all operations. Reading this line quickly is an important everyday skill: before doing apply, you must make sure that what will be created/changed/deleted matches expectations. Why? Because a "0 to destroy" line you expected that turns out to be "5 to destroy" could mean you're about to delete production infrastructure unintentionally.

#3. terraform apply

terraform apply executes the plan in the real world. Terraform will show the plan again, then ask for confirmation (yes) — unless you add the -auto-approve flag.

terraform apply
 
Terraform will perform the following actions:
  # random_id.server_id will be created
  + resource "random_id" "server_id" {
      + b64_std     = (known after apply)
      + byte_length = 4
      + id          = (known after apply)
    }
 
  # local_file.server_info will be created
  + resource "local_file" "server_info" {
      + content  = "Server ID: 1a2b3c4d5e6f\n"
      + filename = "server.txt"
      + id       = (known after apply)
    }
 
Plan: 2 to add, 0 to change, 0 to destroy.
 
Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.
 
  Enter a value: yes
 
local_file.server_info: Creating...
local_file.server_info: Creation complete after 0s [id=...]
random_id.server_id: Creating...
random_id.server_id: Creation complete after 0s [id=...]
 
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

After apply succeeds, several things happen:

• Real resources are created in the cloud (or in this case, a server.txt file is written on your laptop).
• Terraform creates the terraform.tfstate file — Terraform's "memory" that maps your code to real resources.
• The Apply complete! Resources: 2 added, 0 changed, 0 destroyed. output confirms the execution result.

Try verifying the result:

cat server.txt
Server ID: 1a2b3c4d5e6f

#4. terraform destroy

terraform destroy deletes all infrastructure managed by the configuration. It's the opposite of apply: it reads the state, finds all resources, and deletes them one by one.

terraform destroy
 
  # local_file.server_info will be destroyed
  - resource "local_file" "server_info" {
      - content              = "Server ID: 1a2b3c4d5e6f" -> null
      - content_base64sha256 = "..." -> null
      - filename             = "server.txt" -> null
    }
 
  # random_id.server_id will be destroyed
  - resource "random_id" "server_id" {
      - b64_std     = "..." -> null
      - byte_length = 4 -> null
      - id          = "..." -> null
    }
 
Plan: 0 to add, 0 to change, 2 to destroy.
 
Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.
 
  Enter a value: yes
 
local_file.server_info: Destroying...
local_file.server_info: Destruction complete after 0s
random_id.server_id: Destroying...
random_id.server_id: Destruction complete after 0s
 
Destroy complete! Resources: 2 destroyed.

#Summary of the Four Steps

#Common Mistakes in the Early Episodes

Here are some mistakes beginners most often encounter — hopefully you can avoid them:

1. Forgetting terraform init in a new project → Missing required provider error. Solution: run init every time there's a new provider or new project.
2. Running apply directly without reading the plan → risk of deleting resources that shouldn't be deleted. Solution: get in the habit of reading the Plan: X to add, Y to change, Z to destroy. line.
3. Running apply in the wrong directory → Terraform works per directory. Make sure you're in the folder containing the correct main.tf (pwd, ls *.tf).
4. Typo in argument names → Unsupported argument error. Solution: use VS Code autocomplete and the provider documentation.
5. Committing .terraform/ and terraform.tfstate to Git → bloats the repo and leaks data. Solution: add them to .gitignore.
6. Deleting .terraform/ or .tfstate carelessly → Terraform loses track of resources and can't manage them anymore. Solution: don't delete, understand first (episodes 5 & 8).

#Conclusion

In this episode 2 we built the technical foundation that will be used throughout the series: understanding the HCL syntax anatomy — blocks as configuration boxes, arguments as the material filling them, and identifiers as the names connecting one resource to another — as well as mastering Terraform's four core workflow steps: init (prepare), plan (preview), apply (execute), and destroy (clean up).

Key takeaways you should bring along:

• HCL consists of block { argument = value }, with the resource block being the one you'll use most often.
• terraform init downloads providers; terraform plan doesn't change anything; terraform apply executes; terraform destroy deletes everything.
• Always read the Plan: X to add, Y to change, Z to destroy line before applying.
• The state file (terraform.tfstate) is a valuable asset — don't commit it, don't delete it.

How do you feel after running the init → apply → destroy cycle for the first time? It's a nice feeling, isn't it — the ability to create and delete infrastructure with just a few commands is a superpower you've just acquired.

Now that you understand the HCL "alphabet" and the basic workflow, in the next episode 3 we'll discuss a no less exciting topic: Providers, Resources & Data Sources — understanding the bridge between Terraform and cloud APIs, the difference between managed resources vs read-only data sources, and how to leverage existing infrastructure without recreating it. Stay excited, because from here you start building real infrastructure in the cloud!