Terraform Associate (003) Overview — Format, What’s Tested & How to Prepare

Exam snapshot

• Certification: HashiCorp Terraform Associate (003)
• Audience: Cloud/DevOps/platform engineers, SREs, developers who write/review Terraform
• Experience target: ~3–6 months hands-on with Terraform + a cloud provider
• Format: Multiple-choice (single/multiple); code/CLI snippets and plan interpretation
• Focus: Practical fundamentals over vendor trivia

Study funnel: Read this Overview → work the Syllabus objective-by-objective → keep the Cheatsheet open for commands/workflows → validate with Practice.

What the exam measures (at a glance)

1) Core workflow
init → fmt/validate → plan → apply → destroy, plans vs binary plan files, review practices.

2) State & backends
What state is, why it’s sensitive, local vs remote, locking (e.g., S3+DynamoDB), reconfigure with -backend-config, state CLI for surgical moves.

3) Variables, outputs & expressions
Types/validation, sensitive, var precedence, locals, for_each vs count, dynamic blocks, common functions.

4) Modules & versioning
Module structure, pinning module/provider versions, composition, registry usage and documentation.

5) Providers & authentication
Provider config and constraints, multiple providers/aliases, common auth flows (env/CLI profiles/ADC).

6) Change management
-replace for intentional recreate, refresh-only plans for drift, judicious use of -target, lifecycle meta-args (create_before_destroy, ignore_changes, prevent_destroy).

7) Workspaces & environments
When workspaces are enough vs when to use separate states/backends for real isolation.

8) Policy awareness & CI
Plan review, least-privilege credentials, remote runs/state, Sentinel/OPA awareness.

Readiness checklist (be honest)

• I can run the full init → plan → apply loop and explain each step.
• I can configure a remote backend with locking and describe why it matters.
• I know variable precedence, can write validation, use locals, and mark sensitive.
• I choose for_each over count when stable addressing is needed.
• I can import existing resources and intentionally recreate using -replace.
• I can detect external drift with plan -refresh-only and decide next steps.
• I know when to prefer workspaces vs separate state/backends.
• I pin versions, commit the lock file, and review binary plans in PRs.

If fewer than ~6 boxes are checked, spend two extra days with the Cheatsheet + targeted drills.

Compact 2–4 week study plan

Week 1 — Workflow & State

• CLI loop, plan files, review discipline
• Backends, locking, state moves (state mv/rm/show)

Week 2 — Variables/Modules/Providers

• Var types/validation/precedence, locals, loops/functions
• Module usage & version pinning; multi-provider auth and aliases

Week 3 — Changes, Import & Environments

• -replace, lifecycle meta-args, refresh-only
• Import blocks/legacy import; workspaces vs separate states

Week 4 (optional) — Polish & Mocks

• Sentinel/OPA awareness; CI patterns
• 1–2 full mock exams; remediate recurring miss themes next day

Daily cadence: 30–45 min reading → 20–25 question drill → convert misses into two bullets (why wrong / why right) → re-drill within 24–48h.

High-yield workflows to memorize

Safe change flow
Make change → fmt/validate → plan -out=plan.bin → review → apply plan.bin.

Import flow
Add HCL for the resource → import block (or terraform import) → plan → apply.

Intentional recreate
plan -replace=addr → apply -replace=addr (prefer over taint).

Drift detection
plan -refresh-only → decide remediate vs tolerate (possibly ignore_changes).

Stable fan-out
Prefer for_each with meaningful keys; avoid index churn from count.

Common decision pickers

• Need zero downtime on replace → lifecycle.create_before_destroy = true.
• External system mutates one field → lifecycle.ignore_changes = [that_field].
• Prod vs non-prod isolation → separate states/backends; workspaces for lighter variants.
• Multi-region/provider setup → provider aliases; explicit provider = on resources/modules.

Exam-day tactics

• First pass fast, flag long code items.
• Read the final ask before parsing HCL; focus on the relevant block/flag.
• Prefer answers that are safe and auditable (reviewed plans, pinned versions, remote state with locking).
• Use -target sparingly; favor architectural fixes or staged applies.

What to read next

• Syllabus: domain objectives & quick links → Open
• Cheatsheet: commands, flags, and workflows → Open
• Practice: timed drills & mocks → Start