HashiCorp Terraform Associate

Most of the reliability work this course teaches eventually comes down to one unglamorous question: what infrastructure exists right now, and can you prove it? A disaster-recovery failover, a new region brought online, a capacity change that clears a production readiness review — all of it depends on infrastructure that's defined in code rather than remembered by whoever built it last. HashiCorp Certified: Terraform Associate is the entry-level credential for the tool most teams reach for to do exactly that. It isn't an SRE-specific certification and this course doesn't teach Terraform syntax directly, but the four ideas it tests — providers, state, modules, and the plan/apply workflow — are precisely the vocabulary underneath reproducible, reviewable infrastructure change. This page covers what the exam actually is, its current format and domains, how its content maps onto real SRE work, and who should — and shouldn't — spend a Saturday on it.

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

☺ Like you're 10: A one-hour, multiple-choice test of Terraform's core vocabulary — not a hands-on lab where you actually build anything live.

HashiCorp Certified: Terraform Associate is the entry-level rung of HashiCorp's certification ladder for its infrastructure-as-code tool. Unlike the CNCF's performance-based exams — the CKA and CKS drop you into a live cluster and grade the end state — this is a knowledge-based exam: multiple choice, multiple answer, true/false, and fill-in-the-blank questions delivered online through a remote proctor, with no terminal and nothing graded on whether infrastructure actually came up. It tests whether you know Terraform's core engine and workflow, not any one cloud's service catalog — the example resources you'll see reference AWS, Azure, and Google Cloud more or less interchangeably, because the thing being tested is provider-agnostic by design.

It targets cloud, platform, and reliability engineers who write, review, or operate Terraform configuration as part of their job, plus generalist developers who provision their own infrastructure. It assumes basic comfort at a terminal and some exposure to cloud or on-premises infrastructure concepts, but HashiCorp doesn't formally require any prerequisite course, exam, or years of experience to sit it.

Format, cost, and prerequisites — verify before you sit it

☺ Like you're 10: Here's the shape of the test as best it's publicly known right now — but HashiCorp revises this exam more often than a slow-moving standards body would, so double-check before you pay.

The table below reflects HashiCorp's own published certification page and the current exam version as of this writing. Treat the numbers as a planning aid, not a guarantee — this exact exam moved from version 003 to version 004 in January 2026, which is a useful reminder that "verify before you book" isn't boilerplate on this page.

The eight exam domains (Terraform Associate 004)

☺ Like you're 10: Eight topics — and unlike some certifications on this site, HashiCorp doesn't publish exactly how many points each one is worth.

Unlike the CNCF-governed exams this site also covers, HashiCorp's own exam content list doesn't publish a percentage weight per domain. What follows is the current domain structure and the objectives published under each, transcribed from HashiCorp's official Terraform Associate 004 exam content list.

The mechanics underneath: providers, state, modules, and the plan/apply workflow

☺ Like you're 10: Four ideas do almost all the work — where Terraform gets its cloud vocabulary, where it remembers what it already built, how to reuse a build someone else wrote, and the read-before-you-write habit that keeps a bad change from reaching production by accident.

A provider is a plugin that translates HCL configuration into API calls against a specific system — aws, azurerm, google, kubernetes, and hundreds of others. Each is pinned to a version range in a required_providers block, and terraform init downloads the matching plugin into a local cache while writing a .terraform.lock.hcl file that pins the exact version and checksum — the thing that guarantees a teammate's laptop and a CI runner resolve to the identical provider build rather than "whatever's newest today."

State — the terraform.tfstate file — is Terraform's record of what it believes exists. Every terraform plan is a diff between three things: the configuration, the state, and (if a refresh runs) reality itself. Local state — the default, a single file on one machine — is a non-starter for team or production use: nothing locks it, nothing shares it, and losing that laptop means losing Terraform's memory of an entire environment. Real teams configure a remote backend instead — commonly S3 with a DynamoDB lock table, or HCP Terraform's own managed state with built-in locking, encryption at rest, and team-level access control.

A module is a reusable, versioned bundle of configuration, referenced with a source (a local path, a Git URL, the public Terraform Registry, or a private registry such as HCP Terraform's own) and typically a version constraint. The same module graph, re-applied against a different backend and a different set of input variables, is literally how a lot of multi-region and disaster-recovery infrastructure gets stood up without hand-copying hundreds of lines of configuration between environments.

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket         = "acme-tfstate-prod"
    key            = "network/us-east-1/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tfstate-lock"     # state locking — see below
    encrypt        = true
  }
}

provider "aws" {
  region = var.region
}

module "vpc" {
  source     = "app.terraform.io/acme/vpc/aws"   # a private HCP Terraform registry module
  version    = "~> 4.2"
  cidr_block = "10.20.0.0/16"
  region     = var.region                        # same module, reapplied per region
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.al2023.id
  instance_type = "t3.small"
  subnet_id     = module.vpc.private_subnet_ids[0]
  tags          = { Name = "web-${var.region}" }
}

The plan/apply workflow is the discipline that makes all of the above safe to run twice: terraform init to fetch providers and modules, terraform validate to catch syntax errors, terraform plan -out=tfplan to compute and save a reviewable diff, terraform apply tfplan to execute exactly the plan that was saved — not a freshly recomputed one that might have drifted since review — and terraform destroy to tear down what Terraform manages. One command worth knowing precisely: the old terraform taint, which marked a resource for forced recreation on the next apply, is deprecated in current Terraform in favor of terraform apply -replace=<resource.address>, which does the same job without silently mutating state ahead of a plan.

Why SRE teams lean on this: reproducible changes, disaster recovery, and multi-region builds

☺ Like you're 10: If your disaster-recovery plan is a document that says "click these twelve buttons in this order," it will fail exactly when you're too rushed to follow it correctly. If it's Terraform code, it's a command.

A disaster-recovery runbook that says "recreate the VPC, subnets, load balancer, and database subnet group" by hand is a plan that's tested once a year, during a fire drill, if that. A runbook that says "run terraform apply against the dr workspace" is a plan that gets exercised every time someone applies the same module to keep a staging or DR environment in sync with production — which means it's far more likely to actually work the one time it matters. The exam's "core workflow" and "modules" domains are the mechanics underneath exactly that pattern.

The same property serves multi-region architecture: parameterizing a module by region and backend key, the way the code sample above does, is how "stand up region three" becomes a variable change and a plan review instead of a multi-week manual build. And a saved terraform plan output is a natural artifact to attach to a production readiness review or a change ticket, because it's a computer-verified statement of exactly what will change — not a description someone typed from memory the night before a launch.

It's worth being precise about where Terraform's job ends, too. It typically provisions a database instance or cluster resource — the thing covered in database reliability engineering — but not the schema migrations or replication topology running inside it, and it provisions VPCs, subnets, and route tables — the raw material behind network reliability engineering — without owning BGP sessions or DNS failover logic on top. Knowing that boundary is as much a part of using this certification well as knowing the syntax.

Who should consider it — and who should skip it

☺ Like you're 10: If you'd be the one actually running the rebuild-the-treehouse instructions during a real disaster, this is worth an afternoon. If someone else always runs them for you, it might not be.

The case for taking it

Take it if you write, review, or are accountable for Terraform that manages production infrastructure — it builds a shared vocabulary across an infra team faster than reading the docs cold, and it's a common baseline expectation in job postings for SRE, platform, and cloud-infrastructure roles. It pairs naturally with the cloud-specific associate certifications on this site's own certifications hub — AWS Solutions Architect Associate, Azure Administrator Associate, and Google Associate Cloud Engineer — because Terraform Associate deliberately doesn't test any one cloud's service depth; it tests the engine you'd use to provision whichever cloud those certifications cover.

When to skip it

Deprioritize it if any of these fit. Your organization's primary IaC tool isn't Terraform — Pulumi, AWS CDK, and Crossplane all solve the same problem differently, and this credential's specifics won't transfer. Worth flagging explicitly here: HashiCorp changed Terraform's license from the open-source MPL to the more restrictive Business Source License in August 2023, and the Linux Foundation responded by backing OpenTofu, a fully open-source, syntax-compatible hard fork. This certification is HashiCorp's own and specifically Terraform-branded — it doesn't certify OpenTofu, even though almost everything it tests about HCL and the plan/apply workflow transfers directly. If your organization moved to OpenTofu specifically to get away from the license change, weigh that before paying for a HashiCorp-branded badge. You already operate Terraform daily at a senior level — it will confirm what you know and teach you little. Your actual gap is one cloud's service depth, not IaC mechanics — the cloud-specific associate exams listed above are the better use of your study time.

How to prepare using this site

☺ Like you're 10: This course doesn't teach Terraform syntax directly, but plenty of pages teach exactly what you'd use it for — here's the map.

None of this replaces working through HashiCorp's own free tutorials against a real, disposable cloud account — the exam tests a workflow, and a workflow is best learned by running it, plan by plan, the same way this course insists every reliability practice gets learned by doing it, not just reading about it.

Pair this page with disaster recovery & business continuity and multi-region & multi-AZ architecture for where this vocabulary gets used under pressure. For a broader credential across the whole SRE discipline, see this course's own SRE Practitioner path. Full comparisons against every other certification on this site live on the certifications hub.