HashiCorp Certified: Terraform Associate

The certifications page summarizes this exam in a few paragraphs alongside two others. This page is the deep profile: the full official domain breakdown — infrastructure-as-code concepts, Terraform's purpose, the basics and providers, the CLI, modules, the core workflow, state, HCL configuration, and HCP Terraform — the version note every returning candidate needs (004 replaced the retired 003), and a direct map from each domain onto the two lessons that actually teach it: infrastructure as code for the vendor-neutral model the exam assumes you already hold, and the Terraform tool page for the tool-specific syntax the exam tests directly.

What the Terraform Associate is, and who it's for

☺ Like you're 10: A one-hour, closed-book, multiple-choice test about one specific tool's syntax and workflow — no terminal, no real infrastructure touched.

The HashiCorp Certified: Terraform Associate is HashiCorp's own entry-level credential for people who write, read, or review Terraform configuration. Unlike the CKA, it is entirely knowledge-based — multiple choice, true/false, and multiple-answer questions delivered online, proctored remotely, with no live terminal and no infrastructure actually provisioned during the exam. It certifies foundational knowledge of the tool itself: HCL syntax, the core workflow, state, providers, and modules. It does not certify infrastructure architecture, cloud design, or the judgment to choose Terraform over another approach in the first place — that broader, vendor-neutral thinking is what infrastructure as code covers, and this exam assumes you already hold it.

It targets anyone who writes or reviews Terraform day to day — application engineers provisioning their own service's infrastructure, platform engineers building the shared modules other teams consume, and anyone whose job touches a .tf file often enough that "I've picked it up informally" is starting to feel shaky. HashiCorp does not formally require anything before you sit it, but its own study guide assumes some hands-on Terraform usage already — this is not the exam to attempt before you've run terraform apply against something real at least a few times.

↗ HashiCorp official page

004 vs. the retired 003: what changed, and why it matters if you're studying with old material

☺ Like you're 10: If your study notes still say "Terraform Cloud" instead of "HCP Terraform," they were written for the old version of this test.

The exam you'll actually sit today is version 004. Version 003 is retired — HashiCorp does not let you register for it anymore, but plenty of study guides, flashcard decks, and old blog posts written against it are still circulating, and they are the single most common way candidates walk in under-prepared. The nine domain topics carry over largely intact between the two versions — HCL syntax, the workflow, state, providers, and modules were the substance of 003 and remain the substance of 004 — so old material is not wrong, exactly. It is stale in three specific ways worth checking for before you trust anything you didn't get from HashiCorp's own current page.

• Terraform Cloud became HCP Terraform. HashiCorp rebranded its hosted product; any objective, question, or study note still saying "Terraform Cloud" is describing the same product under its old name — the underlying concepts (managed state, run history, policy checks, a private registry) didn't change, only the label did.
• The CLI has moved on underneath the objectives. Features that didn't exist when 003 was written — the declarative import block (1.5+), moved blocks (1.1+) for safe resource renames, -consolidate-warnings-era plan output changes — are fair game under a 004-era objective that just says "read, generate, and modify configuration." A study guide frozen at 003 won't mention any of them.
• Exact question counts and pass marks are rarely republished verbatim. Neither version has ever had a precisely, permanently published passing score — both are informally reported, not vendor-confirmed — so a number quoted from an old 003 writeup is no more or less authoritative than one quoted today. Treat any specific percentage you read anywhere, including this page, as directional.

The official domain breakdown

☺ Like you're 10: Nine topics, and — unlike the CKA — HashiCorp doesn't publish a percentage for each one, so don't assume they're weighted equally or that any one is "the big one."

HashiCorp's own exam guide lists nine objective domains, each broken into several specific, testable sub-objectives. Unlike the CKA's curriculum, HashiCorp does not publish a percentage weight per domain — there is no "30% troubleshooting" equivalent here, so treat the list below as complete coverage, not a prioritization guide, and verify the exact current wording against HashiCorp's own study guide before you treat any single sub-bullet as gospel.

Reading left to right above roughly matches how most candidates find it natural to study: understand why IaC and Terraform exist, learn the language and workflow that makes up the bulk of the exam, then round out state and the hosted platform. The full nine, in HashiCorp's own published order:

1. Understand infrastructure as code (IaC) concepts — what IaC is, and the advantages of the declarative pattern over ad hoc scripting. Covered in full at infrastructure as code.
2. Understand Terraform's purpose (vs. other IaC) — multi-cloud and provider-agnostic benefits, and why state is what makes Terraform's approach work.
3. Understand Terraform basics — installation and versioning, the plugin-based provider architecture, using multiple providers (including aliased providers for multi-region setups), and when — and when not — to reach for a provisioner.
4. Use the Terraform CLI outside the core workflow — fmt, import, workspace, state, output, console, and the resource-replacement mechanics historically covered by taint.
5. Interact with Terraform modules — module sources, inputs and outputs, variable scope across parent and child modules, discovering modules on the public registry, and pinning module versions.
6. Navigate the Terraform workflow — init, validate, plan, apply, destroy, in order, and what each one is actually responsible for.
7. Implement and maintain state — the default local backend, state locking, backend authentication, remote backend options, handling drift, and what does and doesn't stay secret inside a state file.
8. Read, generate, and modify configuration — variables and outputs, secure secret injection, collection and structural types, resources vs. data sources, resource addressing, built-in functions, dynamic blocks, and Terraform's implicit dependency graph.
9. Understand HCP Terraform capabilities — how the hosted platform helps manage infrastructure, and how it supports team collaboration and governance (policy checks, a private registry, run history).

Domain wording above is written from HashiCorp's long-published objective structure and is a close, study-oriented paraphrase rather than a verbatim quote — check the exact current sub-bullet text on HashiCorp's own study guide before treating any single phrase as exam-verbatim.

What you need to know cold: HCL syntax, workflow, state, providers, modules

☺ Like you're 10: Five things your fingers and your eyes both need to recognize instantly — the shape of the language, the five-command workflow, where state lives, how a provider gets pinned, and how a module gets called.

HCL syntax: blocks, meta-arguments, and the pieces that actually get tested

Every .tf file is blocks: a keyword, optional labels in quotes, a body in { }. The exam expects instant recognition of terraform, provider, resource, data, variable, locals, output, and module — the same set the Terraform tool page covers in full — plus the handful of meta-arguments that aren't tied to any one resource type: count and for_each for creating multiple instances, depends_on for an explicit dependency the graph can't infer on its own, provider for pointing a resource at a non-default aliased provider, and the lifecycle block (create_before_destroy, prevent_destroy, ignore_changes).

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

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

resource "aws_s3_bucket" "primary" {
  bucket = "acme-reports-primary"
}

resource "aws_s3_bucket" "replica" {
  provider = aws.replica          # meta-argument: use the aliased provider, not the default
  bucket   = "acme-reports-replica"

  lifecycle {
    prevent_destroy = true         # meta-argument: refuse to destroy this resource, even via destroy
  }
}

resource "aws_instance" "web" {
  for_each      = toset(["a", "b", "c"])   # meta-argument: one instance per set member, stable keys
  ami           = data.aws_ami.app.id
  instance_type = "t3.micro"
  depends_on    = [aws_s3_bucket.primary]  # meta-argument: explicit ordering the graph can't infer
}

One distinction the exam tests directly: resource blocks create and own something; data blocks only read something that already exists and never modify it. Confusing the two — writing a data source expecting Terraform to manage its lifecycle, or a resource block expecting it to just look something up — is a reliable source of wrong answers.

The core workflow: five commands, in order

Domain 6 is exactly this sequence, and exam questions frequently describe a symptom and ask which stage of the workflow it belongs to.

$ terraform init        # download providers/modules, set up the backend — run first, always
$ terraform validate    # syntax + internal consistency check — no state, no provider API calls
$ terraform plan        # read-only diff: desired config vs. real infrastructure via provider APIs
$ terraform apply       # execute the diff — the only command in this list allowed to change anything
$ terraform destroy     # plan and apply the removal of everything this config owns

terraform fmt rewrites files into canonical formatting and is technically part of domain 4 (CLI outside the workflow), not domain 6 — a distinction the exam has been known to probe directly. Note also that validate cannot catch an error that only a real provider API would know about (a bad AMI ID, an out-of-range instance size) — that's exactly what plan, which does talk to the provider, is for.

State: where it lives, what locks it, what's in it

Without backend configuration, state is a local terraform.tfstate file — plain JSON holding every tracked resource's attributes and the dependency graph between them. A remote backend (S3, GCS, Azure's azurerm, or HCP Terraform's own managed state) moves that file to shared storage and adds locking, so two concurrent applies can't race against the same state. The domain-7 fact most candidates miss: marking an output sensitive = true only hides it from CLI and UI display — the raw value is still written to the state file in plaintext, which is why state file access control is a real secret boundary and not a formality. Full depth, including the exact backend configuration syntax and the state list / state mv / state rm / import command family, lives on the Terraform tool page; the secrets angle specifically is covered in secrets & credential management.

Providers: versioning and where plugins come from

Providers are plugins, resolved and pinned in the terraform block's required_providers, downloaded by terraform init from the public Terraform Registry by default, and recorded — exact version and hash — in .terraform.lock.hcl, which belongs in version control so every teammate and every CI run gets identical providers. The version-constraint operators are worth memorizing cold:

terraform {
  required_version = ">= 1.9.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"   # registry namespace/name — how init knows where to fetch it
      version = "~> 5.60"
    }
  }
}

Modules: composing configuration, not just writing it

A module is any directory of .tf files invoked through a module block. The directory you run Terraform in directly is the root module; anything it calls is a child module. Domain 5 tests source-type recognition specifically: a local relative path (./modules/vpc), the public Terraform Registry's short form (terraform-aws-modules/vpc/aws), a Git URL with an optional ?ref=, or a generic HTTP/S3 archive — plus variable scope (a child module cannot see its caller's variables or locals unless they're explicitly passed in as module inputs) and version pinning on registry modules using the same operators as providers.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"   # registry short form
  version = "~> 5.13"
  cidr    = "10.20.0.0/16"
}

module "app" {
  source = "./modules/service"                 # local path — no version argument; it isn't versioned
  vpc_id = module.vpc.vpc_id                    # a child module's output feeding another module's input
}

Try writing one yourself in Drill — Write a Reusable IaC Module, then use it in a real stack in Capstone Part 2 — Infrastructure as Code.

How to prepare using this site

☺ Like you're 10: Two lessons here cover almost the entire exam — one for the "why," one for the "how" — plus a few smaller pages for the edges.

A workable shape for most candidates: a few days on infrastructure as code to lock in the vendor-neutral model, most of the remaining time inside the Terraform tool page actually typing every code block rather than reading it, and a final pass working through flashcards and the domain list above from memory, out loud, without looking anything up.

Exam logistics — verify these yourself before you register

☺ Like you're 10: Prices and question counts drift over time — read the vendor's own page the week you plan to book, not a page like this one from months ago.

Where it sits, and who should take it

☺ Like you're 10: It's the fast, narrow one — a good first certification, and a weak substitute for actually operating a cluster or a cloud account under pressure.

Of the three certifications this course covers in depth, the Terraform Associate is the narrowest and the fastest to prepare for — one tool, no hands-on component, an hour long. That makes it a strong first certification if you're building a résumé with no prerequisites to clear first, and a weak only certification if the job actually requires proving you can operate infrastructure under a clock, which is what the performance-based CKA is for instead.

Take it if: you write or review Terraform regularly and have never had that knowledge externally checked, or you want a fast, concrete, no-prerequisite win while building toward a harder performance-based exam. Consider skipping it if: you already hold deep, provable Terraform experience and a knowledge-based multiple-choice exam would tell a hiring manager nothing they couldn't already see in your work; or your actual gap is elsewhere entirely — Kubernetes operations (CKA) or AWS-specific delivery services, in which case the certifications page walks the full comparison.