Before we start: what you are signing up for
The HashiCorp Certified: Terraform Associate (004) exam is a one-hour, multiple-choice exam, delivered online with a proctor, in English. It tests Terraform 1.12. HashiCorp lists the price as $70.50 USD plus local taxes and fees, with no free retake, and the credential expires after two years. Check the registration page before you book, because prices and policies change.
"Multiple choice" covers three question styles in HashiCorp's own sample questions:
- True or false: one statement, and you judge it.
- Multiple choice: pick the one correct answer.
- Multiple answer: pick several correct answers from a list.
HashiCorp's stated prerequisites are modest: basic terminal skills and a basic understanding of on-premises and cloud architecture. You do not need provider-specific knowledge. The official tutorials happen to use particular clouds, but the exam is about Terraform, not about AWS or Azure.
Two honest notes. This course is independent of HashiCorp: it is not endorsed by them, and its practice questions are original, not real exam questions. And no course can promise you a pass. What this one can do is cover every published objective, in the exam's own words, with real configuration and commands.
The map: eight sections
The exam content list has eight sections, and this course follows them in order:
| # | Exam section | What you will be able to do |
|---|---|---|
| 1 | Infrastructure as Code (IaC) with Terraform | Explain what IaC is and why teams use it |
| 2 | Terraform fundamentals | Install and version providers, explain state |
| 3 | Core Terraform workflow | Run init, validate, plan, apply, destroy, fmt |
| 4 | Terraform configuration | Write resources, data blocks, variables, outputs, expressions |
| 5 | Terraform modules | Source, use and version modules |
| 6 | Terraform state management | Backends, locking, drift |
| 7 | Maintain infrastructure with Terraform | Import, inspect state, verbose logging |
| 8 | HCP Terraform | Workspaces, projects, governance, integration |
If you studied for the older 003 exam, note that 004 adds topics (custom conditions, ephemeral values and write-only arguments, depends_on and create_before_destroy, HCP Terraform workspaces and projects) and moves to version 1.12. HCP Terraform is the current name for what used to be called Terraform Cloud. Use the new name; older blog posts still use the old one.
This level covers objective 1a: Explain what IaC is.
Three ways to build the same thing
Say you need a storage bucket for application logs. There are three ways to get it.
1. Click in the console. You log in to the cloud provider's web console, fill in a form and press Create. It is quick the first time. But nothing records what you chose, nobody can review it, and building an identical bucket for staging means remembering every click.
2. Write an imperative script. You capture the steps as commands:
# Imperative: you spell out HOW, step by step
aws s3api create-bucket --bucket acme-app-logs --region us-east-1
aws s3api put-bucket-tagging --bucket acme-app-logs \
--tagging 'TagSet=[{Key=Environment,Value=dev}]'
This is better: it is text, so it can live in Git. But run it a second time and the first command meets a bucket that already exists. The script knows nothing about what is already there, so you write the "if it exists, skip; if the tag differs, update" logic. That logic grows with every resource you add.
3. Declare the end state. You describe what should exist and let a tool work out the steps.
HashiCorp's definition is worth memorising: Infrastructure as Code (IaC) tools allow you to manage infrastructure with configuration files rather than through a graphical user interface. Terraform is HashiCorp's IaC tool. It lets you define cloud and on-premises resources in human-readable configuration files that you can version, reuse and share.
Terraform's configuration language is declarative: it describes the desired end state of your infrastructure. A procedural (imperative) language needs step-by-step instructions. A recipe versus a photo of the finished dish is a fair analogy: the script is the recipe, and Terraform takes the photo and works out the cooking.
Your first HCL file
Terraform configuration is written in HCL (HashiCorp Configuration Language), in files ending .tf. Here is the logs bucket again:
# main.tf
# "resource" declares one piece of infrastructure Terraform should manage.
# "aws_s3_bucket" is the resource TYPE: an Amazon S3 bucket.
# "logs" is a local NAME, used only inside this configuration.
resource "aws_s3_bucket" "logs" {
bucket = "acme-app-logs" # the bucket's real name in AWS
tags = {
Environment = "dev" # a label attached to the bucket
}
}
Read it aloud as a statement of fact: "There is an S3 bucket called acme-app-logs, tagged Environment = dev." The file contains no "create", no "if exists" and no ordering. That absence is what declarative means in practice.
The S3 bucket is only an example. You need to read the shape (block type, resource type, local name, arguments), not know S3. Full working setups also include provider settings, which come in a later level.
Gotcha: the label
logsis not the bucket's name in the cloud. It is how the rest of your configuration refers to this block, asaws_s3_bucket.logs. The real name comes from thebucketargument.
What Terraform does with that file
Terraform compares the configuration with the infrastructure it already manages and proposes only the difference. You preview that with terraform plan:
$ terraform plan
Terraform will perform the following actions:
# aws_s3_bucket.logs will be created
+ resource "aws_s3_bucket" "logs" {
+ bucket = "acme-app-logs"
+ tags = {
+ "Environment" = "dev"
}
# (other attributes trimmed for this lesson)
}
Plan: 1 to add, 0 to change, 0 to destroy.
The + means "will be created". Approve it with terraform apply and the bucket exists. Run terraform plan again with nothing changed and Terraform reports no changes, because reality already matches the file. The two-line script would have failed on that second run.
Terraform can do this because it keeps a state file recording what it manages. HashiCorp describes state as the source of truth for your environment, and Terraform uses it to work out what changes are needed to match your configuration. State gets its own levels later.
HashiCorp sums up the workflow in three stages, each with its own level later: Write the configuration, Plan to preview the changes, Apply to make them.
From experience: IaC only works if the files stay the source of truth. Once someone "just fixes it in the console", the configuration and reality disagree. Treat the console as read-only for anything Terraform manages.
What the exam asks about this
Expect short conceptual questions:
- Recognise the definition of IaC: configuration files rather than a graphical user interface.
- Tell declarative (describe the end state) from imperative or procedural (list the steps), and know Terraform is declarative.
- Read a small block and say which part is the resource type, the local name and an argument.
- Watch for distractors claiming Terraform needs step-by-step instructions, or that IaC means "scripts that click the console for you".
Key takeaways
- The 004 exam is one hour, multiple choice, online proctored and tests Terraform 1.12, across eight sections. This course is independent of HashiCorp and promises no pass.
- IaC means managing infrastructure with configuration files rather than through a graphical user interface.
- Terraform configuration is declarative: you describe the end state and Terraform works out the steps and their order.
resource "TYPE" "NAME" { ... }declares one managed object, with arguments inside the braces setting its properties.- Terraform compares configuration with what it manages and changes only the difference, so re-running an unchanged configuration changes nothing.