RoleMath Study Track for HashiCorp Certified: Terraform Associate (004) (004)
A free study companion keyed to the officially published exam domains of HashiCorp Certified: Terraform Associate (004) (004): what each domain covers in plain language, clearly labeled free resources, a guided lab outline for every domain, and interactive self-checks from our own question bank. HashiCorp Terraform Associate (004) Exam Review objectives
A free, source-cited study companion built on HashiCorp's published Terraform Associate (004) Exam Review objective list, for independent study only. It is not official training, is not affiliated with or endorsed by HashiCorp, and is not a pass guarantee. Terraform Associate is a provider-agnostic, entry-level exam, and every hands-on lab here runs on the free Terraform CLI with zero-cost local providers (or a free HCP Terraform account that deploys no cloud infrastructure), always ending with terraform destroy. HashiCorp does not publish domain weights or a numeric passing score; verify the current objectives on the official Exam Review page before your exam.
A complete free HashiCorp Certified: Terraform Associate (004) program pinned to HashiCorp's currently published Exam Review objectives (004 went live 2026-01-08; 003 retired 2026-01-07), sequenced the way the concepts build rather than in numeric order - fundamentals and the core workflow first, then providers, configuration, modules, state, maintenance, and HCP Terraform - with every hands-on lab run on the free Terraform CLI plus zero-cost local providers (hashicorp/random, kreuzwerker/docker) or a free HCP Terraform account that needs no credit card and deploys no cloud infrastructure. Every lab ends with terraform destroy and costs nothing. This is an accessible, provider-agnostic first infrastructure cert: it assumes only basic command-line comfort, needs no coding background, and rechecks the official objectives before any exam scheduling. HashiCorp publishes no domain weights and no numeric passing score, so this program invents neither. It does not predict a score, confer experience, or serve as a credential.
This draft exposes RoleMath’s authored sequence and evidence plan. The current labs are guided outlines, not yet a fully fixture-backed course, and objective-leaf coverage has not passed the gold-standard gate. Completion does not predict an exam result.
Modules
8
Labs
8
Concept checks
16
Resource mix
5 official / 1 community
Choose an outcome
Three routes through the same evidence
Choose provisionally. Change routes when the work tells you something new about fit, time, or readiness.
Certification-focused
Learners with basic command-line comfort who want one current, dependency-ordered Terraform Associate (004) sequence across all eight domains, with every lab run on the free Terraform CLI and zero-cost local providers (or a free HCP Terraform account) and a recheck of the official objectives before scheduling.
Completion emphasis: Complete every phase, run each lab on the free Terraform CLI with local providers or a free no-card HCP Terraform account (always ending with terraform destroy), correct every missed check against its cited source, finish the integrated capstone, and diff the current Exam Review objectives before booking the exam - never inferring a pass from coverage, since HashiCorp publishes no passing score.
Required phases: Fundamentals and the core Terraform workflow, Providers, versioning, and the configuration language, Modules and state management, Maintenance, HCP Terraform, and the integrated capstone
IaC skills first
Career changers who want reviewable evidence that they can write declarative Terraform, run the plan/apply/destroy workflow, pin providers, build and reuse a module, inspect and safely refactor state, import existing resources, and connect a configuration to HCP Terraform - whether or not they sit the exam soon.
Completion emphasis: Retain a labeled command transcript plus the HCL for each domain - a full workflow run, a provider-versioned variables/outputs config, a custom-validation config, a reusable local module called twice, a state-inspection-and-moved-block record, a Docker import-and-logging record, and an HCP Terraform remote-run record - plus the capstone transcript and a note confirming every lab was destroyed and nothing billable remained.
Required phases: Fundamentals and the core Terraform workflow, Providers, versioning, and the configuration language, Modules and state management, Maintenance, HCP Terraform, and the integrated capstone
Career-fit sprint
Learners deciding whether infrastructure as code and Terraform - declarative configuration, the plan/apply workflow, and the provider-agnostic multi-cloud model - is a direction worth deeper investment before committing to the full Terraform Associate grind.
Completion emphasis: Complete the diagnostic and the fundamentals-and-core-workflow phase (running your first real Terraform lifecycle on the free local random provider), sample the configuration work, then choose a next Terraform experiment or a full exam commitment rather than inferring job readiness or a pass from partial coverage.
Required phases: Fundamentals and the core Terraform workflow
Start safely
Prerequisite diagnostic
Confirm you can run the free Terraform CLI and have the basic command-line comfort the labs assume before you start; this diagnostic is not a HashiCorp prerequisite, a cost promise, or an exam prediction. Terraform Associate is a provider-agnostic, entry-level exam that needs no coding background and no cloud account.
Are you comfortable running commands in a terminal - navigating directories, running a tool, and reading its text output - since every Terraform lab and the exam's workflow questions are command-line first?
Ready when: Yes, or you will practice basic terminal use in parallel while following each lab's documented commands, because the core workflow (init/plan/apply/destroy) is all typed at a terminal.
If not yet: Spend a little time on basic command-line fundamentals first (a free primer); the labs assume you can run a command and read its output, though they require no scripting or coding.
Can you install the free Terraform CLI on your own machine (from the official install page) and run 'terraform version', or will you use the guided browser tutorials instead?
Ready when: Yes, with the Terraform CLI installed and on your PATH, or a plan to use HashiCorp's free browser-readable certification tutorials when a local install is impractical.
If not yet: Start with HashiCorp's free guided tutorials (browser-readable, runnable commands) while you sort out a local install, since they reach the same workflow understanding and evidence.
Do you have Docker Desktop or Docker Engine available (free) for the one Docker-based lab (import and verbose logging), or will you use the local-random-provider alternative for state inspection?
Ready when: Yes, with Docker installed and running for the Docker lifecycle lab, or you will use the local random-provider state-inspection route instead - both are free and reach the same maintenance-skill understanding.
If not yet: Docker is optional: if you cannot run it, the local random-provider labs still cover state inspection, and the Docker Get Started tutorials remain browser-readable, so no lab is blocked.
Are you willing to create a FREE HCP Terraform account (no credit card required) for the single HCP Terraform lab, or will you complete that domain from documentation instead?
Ready when: Yes, you will create a free no-card HCP Terraform account for the remote-run lab, or you will complete the HCP Terraform domain from the free official tutorials and documentation.
If not yet: The HCP Terraform lab has a full documentation-only route, so a learner who prefers not to create an account can still cover the domain; the free tier never requires a card.
Have you chosen a pace whose weekly hours you can realistically protect across roughly 23 to 33 total hours (more if you are entirely new to IT, less if you already work with infrastructure)?
Ready when: Yes, with a pace selected and the hands-on labs, the missed-check corrections, and the integrated capstone left uncompressed.
If not yet: Pick the steady pace if you are newer to IT and reserve the intensive pace for learners already comfortable with infrastructure tooling; never compress the hands-on labs or the capstone to save time, because Terraform fluency comes from running the workflow.
Plan, then adapt
Pace options
Steady
6 weeks 5-6 hours/week
A planning estimate of roughly 30-33 hours for a learner newer to IT: one phase at a time, every lab run on the free Terraform CLI with local providers or a free no-card HCP Terraform account and always ended with terraform destroy, plus the missed-check corrections, the integrated capstone, and an objectives recheck before scheduling. A learner with no IT background at all should expect the upper end of this range.
Standard
4 weeks 6-8 hours/week
A planning estimate of roughly 24-30 hours for learners with some IT or command-line exposure that pairs the objective-cited domain study with one retained command transcript and HCL set per domain, preserves the custom-conditions (new-in-004) practice and the state-refactoring work, and keeps an objectives-diff block before any exam logistics.
Intensive
3 weeks 8-10 hours/week
Roughly 23-27 hours for an experienced learner already comfortable with infrastructure tooling or another cloud; do not compress the hands-on labs, the new-in-004 custom-conditions practice, the moved-block state-refactoring work, or the HCP Terraform remote-run lab, since the exam tests recognition of behavior you only truly learn by running it.
Evidence-gated sequence
Program roadmap
1
Fundamentals and the core Terraform workflow
Build the conceptual frame and the physical act of using Terraform. First take 'Terraform and infrastructure-as-code fundamentals' (Domain 1, HashiCorp's 'Infrastructure as Code with Terraform'): what IaC is, its advantages, and Terraform's provider-agnostic multi-cloud design. Then, out of numeric order, take 'Core Terraform CLI workflow' (Domain 3, HashiCorp's 'Core Terraform Workflow'): the init -> validate -> plan -> apply -> destroy loop and how to read a plan's create/update/replace/destroy symbols. Running the workflow early makes every later concept concrete, and both domains share one free local-random-provider lifecycle lab.
Complete the diagnostic (CLI comfort, install Terraform, optional Docker, optional free HCP account, and study-time), choose a pace you can protect, and install the free Terraform CLI (or plan to use the guided browser tutorials).
Complete the Domain 1 + Domain 3 core-workflow lab with the free local hashicorp/random provider: run init/fmt/validate/plan/apply/show/state list, prove idempotence with a no-change re-apply, make one edit to see an update or replacement in the plan, and destroy - reading the plan's +/~/-/-+ symbols correctly.
Be able to explain, in your own words, what infrastructure as code is, three concrete advantages it brings, why Terraform is provider-agnostic, and what job each core-workflow command does.
Attempt every authored Domain 1 and Domain 3 check and correct each miss against its cited source before moving on, then run terraform destroy so no local state persists.
2
Providers, versioning, and the configuration language
Learn where Terraform's real work comes from and how to write configuration well. First take 'Provider installation versioning and multi-provider use' (Domain 2, HashiCorp's 'Terraform Fundamentals'): the required_providers block, version constraints and the dependency lock file, how Terraform uses providers, multi-provider and aliased configurations, and the role of state. Then take 'Terraform configuration language patterns' (Domain 4, HashiCorp's 'Terraform Configuration') - the deepest domain: resources versus data sources, variables and outputs, complex types, expressions and functions, dependencies, sensitive data, and the custom validation and precondition/postcondition blocks that are NEW in 004.
Complete the Domain 2 providers/variables lab on the free local random provider: pin a provider with a pessimistic '~> 3.6' constraint, inspect the exact selected version in .terraform.lock.hcl, drive the config with a typed variable, a CLI override, and an auto-loaded terraform.tfvars, read a raw output, and use terraform console.
Complete the Domain 4 custom-conditions lab (NEW in 004): deliberately feed invalid input and read the custom error a variable validation block produces at PLAN time (before creation), then apply valid input with a satisfied lifecycle postcondition - all on the local random provider.
Be able to explain provider version constraints (what '~> 3.6' allows and forbids), resource-versus-data-source, implicit-versus-explicit dependencies, and how validation/precondition/postcondition blocks move errors from apply-time to plan-time.
Attempt every authored Domain 2 and Domain 4 check and correct each miss against its cited source, retaining the version-pinned config and the custom-validation config, both destroyed afterward.
3
Modules and state management
Package configuration for reuse, then master the file that remembers everything. First take 'Module sourcing scope usage and versioning' (Domain 5, HashiCorp's 'Terraform Modules'): module sources, input/output variable scope and encapsulation, calling a module multiple times with namespaced state, and version pinning for registry/Git modules. Then take 'Terraform state backends locking drift and refactoring' (Domain 6, HashiCorp's 'Terraform State Management'): the local versus remote backend, state locking, drift detection and refresh-only, and safe refactoring with the moved block instead of destroy-and-recreate.
Complete the Domain 5 module lab on the local random provider: source a local ./modules/naming module, call it twice with different inputs, inspect the module-namespaced state (module.web.* versus module.api.*), and read how inputs flow in and outputs flow out.
Complete the Domain 6 state lab on the default local backend: inspect state with state list, state show, and show -json, use a moved block so a resource rename is a state MOVE (contrasted against the destroy-and-recreate a rename would otherwise force), and run apply -refresh-only.
Be able to explain module input/output scope and versioning, local versus remote backends and state locking, what drift is and how refresh-only reconciles it, and why moved blocks make refactoring safe.
Attempt every authored Domain 5 and Domain 6 check and correct each miss against its cited source, retaining the two-call module transcript and the state-inspection-and-moved-block record, both destroyed afterward.
4
Maintenance, HCP Terraform, and the integrated capstone
Learn the day-two operating skills and the team platform, then prove you can span the whole exam. First take 'Infrastructure maintenance with import state inspection and logging' (Domain 7, HashiCorp's 'Maintain Infrastructure with Terraform'): importing existing objects, inspecting state at the CLI, and enabling verbose TF_LOG logging - practiced against LOCAL Docker (free). Then take 'HCP Terraform workflow collaboration governance and integration' (Domain 8, HashiCorp's 'HCP Terraform'): remote runs, collaboration and governance, workspaces and projects, and integration - practiced in a free no-card HCP Terraform account deploying NO cloud infrastructure. Finish with the integrated capstone spanning all eight domains.
Complete the Domain 7 Docker lifecycle lab against LOCAL Docker: run and inspect an nginx container in state, enable TF_LOG=DEBUG to read verbose provider logs, import a hand-created container into Terraform management with a matching config, and tear everything down (terraform destroy plus docker cleanup) leaving no lab containers.
Complete the Domain 8 HCP Terraform lab in a FREE no-card account: connect via a cloud block, run terraform login and a REMOTE apply whose only resource is a local value (so NO cloud infrastructure is deployed), tour the workspace's state versions, run history, variables, and settings, and destroy remotely.
Complete the integrated capstone spanning all eight domains on the free CLI and a free HCP Terraform account, then confirm every lab was destroyed and nothing billable remained.
Diff the current Exam Review objectives (confirm the 004 objective list and the new-in-004 custom conditions), record remaining gaps, and choose a continue, practice, defer, Terraform experiment, or exam-scheduling next decision rather than inferring a pass from coverage.
Before a lab
Environment, access, and safety
Required and optional setup
Required
A browser plus text tools for the HashiCorp Exam Review objectives, the free HashiCorp Developer study path, and the Terraform documentation, and for recording each lab's commands, HCL, CLI output, and destroy confirmation
The free Terraform CLI on your own machine (install from the official page) - the tool every lab uses; and a text editor to read and lightly edit the HCL fixtures
The free, zero-cost providers and images the labs use - hashicorp/random for the local-only labs (no cloud, no credentials) and, for the maintenance lab, local Docker (Docker Desktop or Docker Engine) with the public nginx image - used only on your own machine
A destroy-and-cleanup checklist recording, for each lab, that terraform destroy was run (plus docker cleanup for the Docker lab and a remote destroy for the HCP Terraform lab) and that nothing billable or lingering remained
Optional
A free HCP Terraform account (no credit card) for the single HCP Terraform lab; the domain also has a full documentation-only route for learners who prefer not to create an account
The free HashiCorp Developer certification tutorials and Docker Get Started series as browser-readable, guided alternatives to running the CLI locally (verify they remain free before relying on them)
A free community video course (for example the freeCodeCamp / ExamPro course) as an alternate explanation after the official study path - note it covers the previous 003 exam (roughly 90% transfers), so supplement the new-in-004 items (custom conditions, multi-cloud framing, HCP Terraform workspaces) from the official tutorials
Accounts and accessibility routes
Accounts
The local labs require NO account and NO payment: the Terraform CLI, the hashicorp/random and kreuzwerker/docker providers, and Docker are free, and everything runs on your own machine.
The one HCP Terraform lab requires a FREE HCP Terraform account but NO credit card; the free tier is sufficient and the domain has a documentation-only alternative that needs no account at all.
No lab requires a paid subscription, a cloud account, or a card; the only managed resources are local random values and a local Docker container, plus (in HCP Terraform) a local value whose state lives remotely - never any billable cloud infrastructure.
Equivalent routes
When installing the Terraform CLI or Docker locally is impractical, use HashiCorp's free browser-readable certification tutorials and the Docker Get Started series, which walk the same init/plan/apply/destroy, import, state-inspection, and HCP Terraform exercises and reach the same written-transcript evidence with no local setup.
Every lab is command-line and text driven, so the whole program is keyboard-operable with plain-text Terraform output a screen reader can read linearly; the fixtures are plain HCL with labeled blocks, and the HCP Terraform UI is a keyboard-navigable, accessible web app.
In low-bandwidth conditions, run the local random-provider labs, which run entirely on your own machine after the one-time provider download, and record every command and HCL file in a local document; the documentation-only routes for the Docker and HCP Terraform domains avoid the heavier downloads and UIs entirely.
Safety baseline
Run every lab ONLY on the free Terraform CLI on your own machine with zero-cost local providers (hashicorp/random for the local labs, kreuzwerker/docker driving only your OWN local Docker daemon) or a free HCP Terraform account you own - never against a cloud account, a shared or employer backend, or infrastructure you do not own.
Every lab ends with terraform destroy; the Docker lab additionally cleans up any hand-made container (docker rm -f) and confirms docker ps is clear, and the HCP Terraform lab runs a remote destroy and deletes the workspace/organization if it was created only for the lab.
The only managed resources are local random values, a local Docker container, and (in HCP Terraform) a local value whose state lives remotely - so no lab ever deploys billable cloud infrastructure; if a learner later opts into a real cloud provider, they must use their OWN free-tier account and destroy afterward.
Never place real credentials, tokens, or personal data into a configuration, a terraform.tfvars file, an HCP Terraform variable, or a TF_LOG log file; treat the local state file as sensitive because it can hold values, and never commit a real state file.
For the HCP Terraform lab, use only a free account you create yourself with NO credit card and NO paid tier, and never a work, school, employer, or client organization.
Show your work
Module evidence and missed-check protocol
Module exit evidence
A labeled command transcript plus the HCL for each domain tied to its module: a full init/plan/apply/destroy workflow run with the plan symbols read (Domains 1 and 3); a version-pinned providers-and-variables config with the lock file inspected and a custom-validation config whose errors fired at plan time (Domains 2 and 4); a local module called twice with namespaced state and a state-inspection-and-moved-block record (Domains 5 and 6); and a Docker import-and-TF_LOG record plus an HCP Terraform remote-run record (Domains 7 and 8).
A plain-language explanation of the concept, the terraform command that demonstrated it, and the safety boundary the lab stayed inside (free CLI, local providers or a free no-card HCP Terraform account, everything destroyed), including for the new-in-004 custom conditions and the moved-block refactoring the specific behavior each produced.
All authored checks for the domain attempted, with each miss corrected against its cited source, plus a recorded confirmation that terraform destroy was run and nothing billable or lingering remained.
After a missed check
Identify whether the question tests IaC fundamentals, the core workflow, providers and versioning, the configuration language, modules, state management, maintenance, or HCP Terraform before reviewing the answer.
Write why the distractor was plausible and which specific mechanism distinguishes the correct answer - the workflow command's role, the version-constraint operator, the resource-versus-data-source or dependency rule, the custom-condition behavior, the module scope or versioning rule, the backend/locking/moved-block behavior, the import or TF_LOG detail, or the HCP Terraform workspace/governance point.
Because HashiCorp publishes no weights or passing score, do not weight your review by any imagined domain importance; instead change one detail - the constraint operator, the input value, the source path, the resource address, or the account type - and explain whether the correct answer changes, then re-run the relevant lab step if it is a behavior you can reproduce.
Completing this policy demonstrates current-objective Terraform Associate (004) coverage and hands-on Terraform practice inside RoleMath on the free CLI with local providers or a free no-card HCP Terraform account; it does not predict an exam score (HashiCorp publishes no passing score), confer professional infrastructure experience, or serve as a RoleMath credential. Treat your ability to run the workflow, read a plan, and explain each domain's behavior in your own words - not coverage alone - as the honest signal of readiness.
Integrated practice
Integrated Terraform Associate scenario spanning all eight domains on the free CLI and a free HCP Terraform account
Run one integrated, methodology-ordered scenario on the free Terraform CLI and a free HCP Terraform account that touches every Terraform Associate domain - write a small multi-file configuration using variables and a custom-validation guard, call a local module, run the full workflow, inspect and safely refactor state, import a resource, enable verbose logging, and connect the whole thing to HCP Terraform for a remote run - all deploying NO billable cloud infrastructure, then destroy everything, proving you can operate across fundamentals, the core workflow, providers, configuration, modules, state, maintenance, and HCP Terraform.
Workflow
In a directory you own, write a small multi-file configuration that uses the free hashicorp/random provider (pinned with a version constraint), a typed input variable guarded by a custom validation block (new in 004), and a local ./modules/naming module called at least once - confirming nothing reaches a cloud.
Run the full core workflow (Domains 1 and 3): terraform init, fmt, validate, plan (reading the create symbols), and apply, then confirm idempotence with a no-change re-plan.
Providers and configuration (Domains 2 and 4): inspect the pinned version in .terraform.lock.hcl, deliberately pass invalid input to see the validation block reject the plan with your custom message, then supply valid input.
Modules and state (Domains 5 and 6): confirm the module produced namespaced state, inspect state with state list / state show / show -json, rename a resource using a moved block so it is a state move rather than destroy-and-recreate, and run apply -refresh-only.
Maintenance (Domain 7): either import a hand-created local Docker container into management with a matching config, or (if not running Docker) inspect and reason about importing, and enable TF_LOG=DEBUG on a plan to read verbose provider logs.
HCP Terraform (Domain 8): connect the configuration to a FREE no-card HCP Terraform workspace with a cloud block, run terraform login and a REMOTE apply whose only resource is a local value (no cloud infrastructure), and tour the workspace's state versions, run history, and variables.
Write a short integrated run record: for each domain, the commands and HCL you used and the evidence (the workflow output, the pinned version, the validation rejection, the module namespaced state, the moved-block plan, the import or logging output, and the remote run), noting that no billable infrastructure was ever created.
Diff the current Exam Review objectives against what you practiced (confirm the 004 objective list and the new-in-004 custom conditions), flag any uncovered topic as an explicit gap, crosswalk every artifact to the eight domain IDs, then run terraform destroy everywhere (plus docker cleanup and a remote destroy) and confirm nothing billable or lingering remains.
Retained artifacts
A workflow-and-fundamentals record: the multi-file config, a full init/plan/apply run with the plan symbols read, and a no-change re-plan proving idempotence
A providers-and-configuration record: the pinned version from .terraform.lock.hcl and a custom validation block rejecting invalid input at plan time before creation
A modules-and-state record: a local module producing namespaced state, state inspected via list/show/-json, and a moved block making a rename a state move plus a refresh-only run
A maintenance record: a local Docker container imported into management (or a reasoned import walkthrough) and verbose TF_LOG=DEBUG output from a plan
An HCP Terraform record: a free no-card workspace connected via a cloud block, a remote apply of a local-only resource, and a tour of state versions and run history
The integrated run record with an eight-domain crosswalk, an objectives diff flagging any gaps, and a confirmation that terraform destroy was run everywhere and nothing billable or lingering remained
Review checklist
The scenario ran entirely on the free Terraform CLI with local providers and a free no-card HCP Terraform account the learner owns, with no billable cloud infrastructure ever deployed and no action taken against infrastructure or an organization the learner does not own.
Fundamentals and the core workflow are demonstrated with a multi-file config, a full init/plan/apply run whose plan symbols were read, and a no-change re-plan proving idempotence.
Providers and configuration are demonstrated with a pinned provider version inspected in the lock file and a custom validation block (new in 004) rejecting invalid input at plan time with a custom message.
Modules and state are demonstrated with a local module producing namespaced state, state inspected three ways, and a moved block making a rename a state move rather than destroy-and-recreate, plus a refresh-only run.
Maintenance is demonstrated with an imported local Docker container (or a reasoned import walkthrough) and verbose TF_LOG=DEBUG output from a plan.
HCP Terraform is demonstrated with a free no-card workspace connected via a cloud block, a remote apply whose only resource is a local value (no cloud infrastructure), and a tour of the workspace's state versions and run history.
The current Exam Review objectives were rechecked (the 004 objective list and the new-in-004 custom conditions) and any changed objective invalidates the affected mapping or review.
All eight current Terraform Associate domains map to at least one artifact; uncovered topics remain explicit gaps rather than implied completion, and terraform destroy was run everywhere (plus docker cleanup and a remote destroy) with nothing billable or lingering left behind.
The packet does not claim exam success or a passing score (HashiCorp publishes none), official HashiCorp approval or training beyond linked sources, professional infrastructure experience, or a RoleMath credential.
Safety boundary: Run the entire capstone ONLY on the free Terraform CLI with zero-cost local providers and a free no-card HCP Terraform account you own - never a cloud account, a shared or employer backend or organization, or infrastructure you do not own. The only managed resources are local random values, a local Docker container, and a local value whose state lives in your own free HCP Terraform workspace, so nothing is billable. Never place real credentials in a configuration, tfvars, HCP Terraform variable, or log file; run terraform destroy everywhere (plus docker cleanup and a remote destroy) when finished, and delete the HCP Terraform workspace/organization if created only for the lab.
Finish honestly
Completion, portfolio, and maintenance
Completion evidence
All eight current Terraform Associate (004) domain modules have been covered and checked against HashiCorp's official Exam Review objectives, including a recheck of the current objective list (and the new-in-004 custom conditions) before any exam scheduling.
Every domain lab has been run only on the free Terraform CLI with zero-cost local providers or a free no-card HCP Terraform account the learner owns - always ended with terraform destroy (plus docker cleanup and a remote destroy where relevant) - and its command transcript and HCL retained.
The core workflow, provider versioning, the new-in-004 custom conditions, module reuse, state inspection and moved-block refactoring, import and verbose logging, and the HCP Terraform remote run have each been practiced hands-on, not just read.
Every authored knowledge check has been attempted and each miss has a cited correction.
The HashiCorp objectives, the Terraform documentation, the free study path and tutorials, and any community walkthrough have been used within their current free-access terms, with any community resource (which may cover the previous 003 exam) reconciled to the official 004 objectives.
The integrated capstone passes its safety, fundamentals, workflow, providers/configuration, modules/state, maintenance, HCP Terraform, objectives-diff, and eight-domain-coverage review, with everything destroyed and nothing billable or lingering left behind.
The learner has recorded remaining objective gaps and a next Terraform-practice or exam-scheduling decision; completion is not represented as an exam result, a passing score, a credential, job readiness, or professional infrastructure experience.
Portfolio candidates
A sanitized workflow record: the multi-file HCL and a full init/plan/apply/destroy transcript with the plan symbols read, with any real identifiers removed
A providers-and-configuration record: the version-pinned provider block, the lock-file version, and a custom validation block rejecting invalid input at plan time
A modules record: a reusable local module and a root config calling it, with the module-namespaced state entries shown
A state record: state inspected via list/show/-json and a moved block making a rename a state move rather than destroy-and-recreate, plus a refresh-only run
A maintenance record: a local Docker container imported into management (or a reasoned import walkthrough) and verbose TF_LOG=DEBUG output
An HCP Terraform record: a free no-card workspace connected via a cloud block, a remote apply of a local-only resource, and a tour of state versions and run history (no secrets or tokens shown)
Present the packet as self-directed Terraform lab work done only on the free CLI with local providers or a free no-card HCP Terraform account you own. Do not call it production infrastructure work, official HashiCorp approval, professional infrastructure experience, or a RoleMath credential, do not claim a passing score (HashiCorp publishes none), and never publish a real credential, token, cloud account, or employer organization name.
Freshness controls
Objective source checked 2026-07-11. Recheck objectives every 30 days and resources every 90 days.
Stop and re-verify when
HashiCorp changes the Terraform Associate objectives, domain set, exam code (HCTA0-004), format, fee, validity window, delivery provider, or recommended experience, or begins publishing domain weights or a numeric passing score (which this program currently, correctly, does not assert).
Terraform version bump: the exam retargets a new Terraform version away from the 1.12-era scope, or an object, command, or behavior the labs rely on (for example a provider block, a version-constraint operator, a validation/precondition/postcondition block, a moved block, import, or the cloud block) changes across a release.
A tool or provider the labs use - the Terraform CLI, hashicorp/random, kreuzwerker/docker, Docker itself, or the public nginx image - changes URL, access, version, behavior, or reuse terms.
HCP Terraform changes its name again, its free tier, its no-credit-card signup, the cloud block interface, or the workspace/governance features the lab tours, or a browser tutorial alternative changes its free access.
A lab can no longer be run for free on the local CLI or a free no-card HCP Terraform account, or its destroy-everything, own-machine-only, or no-billable-infrastructure guarantees no longer hold.
A fundamentals, workflow, provider, configuration, module, state, maintenance, or HCP Terraform concept materially changes, or a topic (for example the new-in-004 custom conditions) is added to or removed from the objectives.
Any module, lab, check, phase, capstone step, account instruction, safety guardrail, or objectives diff fails technical, source, Terraform-domain, entry-level, safety, cost, privacy, accessibility, currency, or claims review.
HashiCorp publishes NO weights for the eight Terraform Associate (004) domains, so we cannot and do not sequence by weight - we sequence by how the ideas build on one another. We open with 'Terraform and infrastructure-as-code fundamentals' (Domain 1, HashiCorp's 'Infrastructure as Code with Terraform') because it is the vocabulary layer: what infrastructure as code is, why it beats click-ops (versioning, repeatability, review), and the fact that Terraform is provider-agnostic and works across multiple and hybrid clouds - the frame every later domain assumes. We then jump straight to 'Core Terraform CLI workflow' (Domain 3, HashiCorp's 'Core Terraform Workflow') second, out of numeric order, because the init -> validate -> plan -> apply -> destroy loop is the physical act of using Terraform, and doing that loop early makes every abstract concept afterward concrete - you have already watched Terraform build and tear something down before you study how providers or configuration language work. Third comes 'Provider installation versioning and multi-provider use' (Domain 2, HashiCorp's 'Terraform Fundamentals'): now that you have run the workflow, you learn where the plugins that actually do the work come from, how they are pinned to versions, and how state records what Terraform manages. Fourth is 'Terraform configuration language patterns' (Domain 4, HashiCorp's 'Terraform Configuration') - the deepest single domain, covering resources versus data sources, variables and outputs, complex types, expressions and functions, dependencies, sensitive values, and the custom validation and precondition/postcondition blocks that are NEW in 004. Fifth, 'Module sourcing scope usage and versioning' (Domain 5, 'Terraform Modules') builds directly on configuration by teaching you to package and reuse it. Sixth, 'Terraform state backends locking drift and refactoring' (Domain 6, 'Terraform State Management') goes deep on the state file you first met in Domain 2 - local versus remote backends, locking, drift, and safe refactoring with moved blocks. Seventh, 'Infrastructure maintenance with import state inspection and logging' (Domain 7, 'Maintain Infrastructure with Terraform') covers the day-two skills of importing existing objects, inspecting state, and reading verbose logs. We close with 'HCP Terraform workflow collaboration governance and integration' (Domain 8, 'HCP Terraform') because it layers team collaboration, remote runs, workspaces, and governance on top of everything you now understand about the core workflow and state. This is sequencing advice based on how the topics depend on one another, not a claim about the science of learning or about any topic being more heavily tested - HashiCorp publishes no weights; if a different order fits how you think, use it.
Study this first. HashiCorp publishes no weights, so this is not the 'lightest' domain - it is the conceptual foundation. It maps to HashiCorp's official 'Infrastructure as Code with Terraform' domain and gives you the vocabulary (what IaC is, why it wins, provider-agnostic multi-cloud) that every later domain assumes.
This is the 'what problem does Terraform solve and why' domain, and it maps to HashiCorp's official 004 domain titled 'Infrastructure as Code with Terraform'. HashiCorp publishes no weights for any Terraform Associate domain, so treat this not as a small warm-up but as the frame the whole exam is built on: the exam repeatedly asks you to explain what infrastructure as code is, what advantages it brings, and why Terraform's provider-agnostic design matters, and every one of those is a definition-and-reasoning question rather than a syntax question. For a career changer, this is the friendliest place to start because it is about ideas, not commands.
Infrastructure as code (IaC) means describing your infrastructure - servers, networks, DNS records, whatever a provider exposes - in declarative configuration files rather than clicking through a console or running ad-hoc scripts. The word 'declarative' is the key: you write down the desired end state, and Terraform figures out the actions needed to reach it, instead of you scripting each step imperatively. Because the configuration is just text files, it lives in version control, can be code-reviewed, can be diffed, and can be reproduced identically in another environment - the exam's official objective 1a is simply being able to explain this.
The advantages of IaC (official objective 1b) are worth being able to recite in your own words because the exam probes them directly. Repeatability: the same configuration produces the same infrastructure every time, killing the 'works on my environment' drift that manual setup causes. Versioning and collaboration: infrastructure changes go through the same pull-request, review, and history workflow as application code. Automation and speed: a whole environment can be stood up or torn down with one command. Auditability and self-documentation: the configuration files ARE the documentation of what exists. The through-line is that IaC turns infrastructure from a fragile, hand-tended artifact into a reviewable, reproducible asset.
Terraform's provider-agnostic, multi-cloud nature (official objective 1c) is a distinguishing point the exam cares about, and it is also why you can study for this exam without ever touching a paid cloud. Terraform is not tied to any single cloud: through providers it manages AWS, Azure, Google Cloud, Kubernetes, DNS, GitHub, Docker, and hundreds of other services with the same core workflow and the same configuration language. This lets one tool and one skill span a multi-cloud or hybrid-cloud estate, and it is service-agnostic - if a platform has a provider, Terraform can manage it. The practical exam takeaway is that Terraform is an orchestration layer over many providers, not a cloud of its own.
One concept introduced here that the rest of the exam leans on constantly is state. Terraform records what it has created in a state file, and that state is how Terraform knows the difference between what you have declared and what actually exists, so it can compute the minimal set of changes on the next run. You will study state's mechanics in depth in later domains (backends, locking, drift), but the fundamental idea - that Terraform maintains a mapping between your configuration and real-world objects - belongs here, because without it the plan/apply workflow would have nothing to compare against.
Study this domain by being able to explain, in your own words and to a non-technical listener, what IaC is, three concrete advantages it brings, and why Terraform's provider-agnostic design matters - because those are exactly the kinds of questions the exam asks. The lab below (shared with the Core Workflow domain) has you run your very first Terraform lifecycle with the free, local hashicorp/random provider so the words 'declarative', 'apply', and 'state' become something you have seen happen with no cloud account. As always, read the official Exam Review objective list for HashiCorp's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam objectives
HashiCorp Terraform Associate (004) Exam Review objectivesThe exam's own objective checklist - read its infrastructure-as-code fundamentals section directly rather than relying on any summary, including ours; it maps each objective to a documentation page. (captured 2026-07-11)
Official · Free official study path
HashiCorp Developer: Terraform Associate (004) study pathHashiCorp's own free, interactive, exam-mapped study path with runnable commands; the canonical place to learn the IaC fundamentals in depth (verify the free label before relying on it). (captured 2026-07-11)
Tf Assoc Fundamentals Workflow Lab
Run a full declarative Terraform lifecycle (init, plan, apply, destroy) with a free local provider on your own machine Read the state Terraform produces and prove idempotence by re-applying an unchanged configuration
Free tools
Your own machine with the Terraform CLI
A terminal
A text editor
Steps
Copy the fixture into an empty directory you own, then initialize, format, and validate the configuration - confirming the only provider is the local random provider.
Preview then create the resources, and read the state and outputs Terraform produces.
Re-apply to prove idempotence, then destroy everything so nothing persists.
What you should see
Confirm the capture shows init downloading only the random provider, an apply that created and output the random values, a second apply reporting no changes, and a destroy that emptied state - all with no cloud account.
Practice evidence maps to exam_domain_hashicorp_terraform_associate_01
Stay safe & legal: Run this only on your own machine in a throwaway directory you created; the hashicorp/random provider reaches no cloud and costs nothing, so there is no billable resource and no credential involved - if you later opt into a cloud provider, use your OWN free-tier account and run terraform destroy after. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 2 of 8 · domain 3 · 0% of the exam
Core Terraform CLI workflow
Study this second, right after the fundamentals. It maps to HashiCorp's official 'Core Terraform Workflow' domain. Running the init -> validate -> plan -> apply -> destroy loop early makes every abstract concept afterward concrete, because you have already watched Terraform build and tear something down.
This is the 'the everyday commands you actually run' domain, and it maps to HashiCorp's official 004 domain titled 'Core Terraform Workflow'. It is the physical act of using Terraform, and we study it second (right after fundamentals) on purpose: once you have run the workflow with your own hands, every later concept - providers, configuration, modules, state - lands on something concrete. The core workflow is a short, memorable loop, and the exam expects you to know each command's job and the order they run in.
The overall workflow (official objective 3a) is Write, Plan, Apply. You write configuration describing desired state, you run plan to preview the changes Terraform would make, and you run apply to make them. Around that core sit init at the start and destroy at the end. Being able to describe this loop - and to say what stage you are in when a given command runs - is a recurring exam skill, because many questions are really 'which command does X'.
The individual commands each have a precise role. terraform init (objective 3b) prepares a working directory: it downloads providers and modules and sets up the backend, and you run it first and whenever dependencies change. terraform validate (3c) checks that the configuration is syntactically valid and internally consistent, without touching any real infrastructure. terraform plan (3d) compares desired state (your configuration) against known state and shows the create/update/destroy actions it would take - the review step before anything changes. terraform apply (3e) executes that plan, prompting for approval unless you pass -auto-approve. terraform destroy (3f) removes everything the configuration manages. And terraform fmt (3g) rewrites configuration files into the canonical HashiCorp style so code stays consistent and diff-friendly. The exam tests knowing which of these to reach for in a described situation.
The plan output is worth reading carefully because the exam probes it. A plan annotates each resource with a symbol: '+' for create, '-' for destroy, '~' for update in place, and '-/+' for destroy-and-recreate (replacement), and it summarizes 'N to add, M to change, K to destroy'. Understanding that a change to certain attributes forces a replacement (destroy then create) rather than an in-place update is a common and important distinction - it is the difference between a safe edit and one that would tear down and rebuild a resource. Reading a plan accurately is arguably the single most valuable Terraform-in-practice skill this domain builds.
A few workflow habits the exam rewards: run fmt and validate before every plan so style and syntax problems surface early; treat plan as a mandatory review gate, not a formality; and remember that apply without a saved plan will itself compute a fresh plan and prompt for approval. You can save a plan ('terraform plan -out=tfplan') and apply exactly that saved plan later for change control. The mental model is that the workflow is a deliberate, reviewable pipeline from written intent to real change, with plan as the safety checkpoint.
Study this domain by running the full loop repeatedly until init/validate/plan/apply/destroy and reading a plan's +/-/~ symbols are automatic - because the exam asks 'which command' and 'what will this plan do' constantly. The lab below (shared with the fundamentals domain) walks the entire lifecycle with the free local random provider, and the Docker lifecycle lab later in this track repeats the loop against a real local container. As always, read the official Exam Review objective list for HashiCorp's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam objectives
HashiCorp Terraform Associate (004) Exam Review objectivesThe authoritative topic list for the core-workflow commands and the plan/apply lifecycle - read it directly rather than relying on any summary, including ours. (captured 2026-07-11)
Official · Official documentation
Terraform documentation: CLI commandsHashiCorp's authoritative reference for init, validate, plan, apply, destroy, fmt, and the plan output symbols this domain tests. (captured 2026-07-11)
Tf Assoc Core Workflow Lab
Run the full init/fmt/validate/plan/apply/destroy workflow and describe each command's role Read a plan's create, update-in-place, and replacement symbols and predict what apply will do
Free tools
Your own machine with the Terraform CLI
A terminal
A text editor
Steps
Copy the fixture into a directory you own, then initialize, format, and validate - noting that fmt and validate never touch real infrastructure.
Preview and read the plan, apply it, and inspect what was recorded, then re-plan unchanged to see idempotence.
Edit one attribute to force an update or replacement, read how the plan predicts it, apply, then destroy.
What you should see
Confirm the capture shows init/fmt/validate, a create plan with its summary, a no-change re-plan, an update-or-replacement plan after the edit, and a destroy that emptied state - all with the local random provider.
Practice evidence maps to exam_domain_hashicorp_terraform_associate_03
Stay safe & legal: Run this only on your own machine in a throwaway directory; the hashicorp/random provider reaches no cloud and costs nothing, so there is no billable resource and no credential - if you later opt into a cloud provider, use your OWN free-tier account and run terraform destroy after. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 3 of 8 · domain 2 · 0% of the exam
Provider installation versioning and multi-provider use
Study this third (after Domain 1 fundamentals and Domain 3 core workflow). It maps to HashiCorp's official 'Terraform Fundamentals' domain. Once you have run the workflow, this is where you learn where the plugins that do the work come from, how they are version-pinned, and how state records what Terraform manages.
This is the 'where do Terraform's plugins come from and how do you pin them' domain, and it maps to HashiCorp's official 004 domain titled 'Terraform Fundamentals'. Terraform itself is a small core; the actual work of talking to AWS, Azure, Docker, DNS, or a random-number generator is done by providers - plugins Terraform downloads and runs. This domain is about installing those providers, controlling exactly which versions you use, configuring more than one provider at once, and understanding the role of state, so it is where the machinery underneath the workflow becomes clear.
Provider installation and versioning (official objective 2a) is the domain's technical core. In the required_providers block inside a terraform{} block, you declare each provider's source (for example hashicorp/random) and a version constraint. On terraform init, Terraform reads those constraints, downloads matching plugins from the registry, and records the exact selected versions in a dependency lock file (.terraform.lock.hcl) that you commit to version control. Version constraints use operators - '= 3.6.0' pins exactly, '>= 3.0' sets a floor, and the pessimistic '~> 3.6' allows patch and minor updates within 3.x while forbidding a jump to 4.0 - and the exam expects you to read these correctly, because pinning is how you keep infrastructure reproducible and avoid a surprise breaking change.
How Terraform uses providers (official objective 2b) is the conceptual half. Each provider must be configured (often with a provider block giving it region, credentials, or endpoints), and every resource and data source belongs to exactly one provider - random_pet comes from the random provider, aws_instance from the aws provider. Terraform builds a dependency graph across all configured providers and walks it during plan and apply. The exam wants you to understand that providers are the boundary between Terraform's declarative core and the real APIs it drives, and that the provider is what translates your configuration into API calls.
Multi-provider configurations (official objective 2c) show up when one configuration manages resources across more than one platform or more than one instance of the same platform. You might configure the aws and cloudflare providers together to create a server and its DNS record, or configure two aws providers with different aliases to manage two regions. Provider aliases (the alias argument, referenced as provider = aws.west) let a single configuration hold multiple copies of one provider. The exam expects you to recognize that Terraform's provider-agnostic design means one configuration and one workflow can span multiple providers coherently.
State usage (official objective 2d) is introduced formally here even though its deep mechanics live in the State Management domain. State is Terraform's record of the real-world objects it manages and their attributes, and it is what lets Terraform map your configuration to reality and compute an accurate plan. You should be able to say why state exists (to track managed resources and their metadata so Terraform knows what to change), that it can hold sensitive values (which is why it must be protected), and that some commands - state list, show, output - read from it. The fundamentals-level point is that without state, Terraform would have no memory of what it built.
Study this domain by writing and reading version constraints until pessimistic '~>' and '>=' are obvious at a glance, and by configuring more than one provider in a single file, because the exam tests the plumbing here directly. The lab below (shared with the Configuration domain) has you declare the random provider with a pinned version, use typed variables and outputs, and reason about the dependency lock file - all locally and free. As always, read the official Exam Review objective list for HashiCorp's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam objectives
HashiCorp Terraform Associate (004) Exam Review objectivesThe authoritative topic list for this domain's provider and fundamentals coverage - read it directly rather than relying on any summary, including ours. (captured 2026-07-11)
Official · Official documentation
Terraform documentationHashiCorp's authoritative reference for provider blocks, version constraints, the dependency lock file, and provider aliases - the exact syntax this domain tests. (captured 2026-07-11)
Tf Assoc Providers Variables Lab
Declare and pin a provider version with a pessimistic constraint and inspect the dependency lock file Drive a configuration with typed variables, a CLI override, an auto-loaded tfvars file, and raw outputs on your own machine
Free tools
Your own machine with the Terraform CLI
A terminal
A text editor
Steps
Copy the fixture and its tfvars into a directory you own, initialize, and inspect the dependency lock file to see the exact provider version selected under the constraint.
Plan with defaults and with a CLI override, apply, then read outputs including a raw output to see how variables flow to outputs.
Use terraform console to evaluate a local and a variable, then destroy so nothing persists.
What you should see
Confirm the capture shows a concrete provider version in the lock file, a resource_prefix that changed with the environment override, a raw output value, and a destroy that emptied state - all with the local random provider only.
Practice evidence maps to exam_domain_hashicorp_terraform_associate_02
Stay safe & legal: Run this only on your own machine in a throwaway directory; the hashicorp/random provider reaches no cloud and costs nothing, so there is no billable resource and no credential - if you later opt into a cloud provider, use your OWN free-tier account and run terraform destroy after. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 4 of 8 · domain 4 · 0% of the exam
Terraform configuration language patterns
Study this fourth. It maps to HashiCorp's official 'Terraform Configuration' domain and is the deepest single domain: resources versus data sources, variables and outputs, complex types, expressions and functions, dependencies, sensitive values, and the custom validation and precondition/postcondition blocks that are NEW in 004.
This is the 'how you actually write configuration' domain, and it maps to HashiCorp's official 004 domain titled 'Terraform Configuration'. It is the broadest single domain, spanning the whole HashiCorp Configuration Language (HCL): the building blocks (resources and data sources), how you parameterize and expose values (variables and outputs), the type system, expressions and functions, how Terraform orders work (dependencies), how you protect secrets, and - new in 004 - custom conditions. Give this domain the most time; it is where syntax questions concentrate.
Resources versus data sources (official objective 4a) is the first distinction. A resource block declares something Terraform creates, updates, and destroys - it is managed infrastructure. A data source (a data block) reads information about something that already exists, without managing it - for example looking up an existing image or availability zone to feed into a resource. The exam expects you to tell them apart cleanly: resource = 'Terraform owns this', data = 'Terraform just reads this'.
References and dependencies (objectives 4b and 4f) are how a configuration wires together. When one resource's argument references another's attribute (for example using an id from resource A in resource B), Terraform builds an implicit dependency and orders the create/destroy accordingly - you rarely need to state dependencies by hand. When there is no attribute reference but an ordering still matters, depends_on declares an explicit dependency. Terraform assembles all of these into a dependency graph and walks it, which is why it can parallelize independent work and correctly sequence dependent work. Understanding implicit-versus-explicit dependencies is a recurring exam point.
Variables, outputs, complex types, and expressions/functions (objectives 4c, 4d, 4e) are the parameterization toolkit. Input variables make a configuration reusable (with a type, an optional default, and a description); output values expose results (of a root module or to a calling module). The type system spans primitives (string, number, bool) and complex types (list, set, map, object, tuple), and the exam expects you to recognize them. Expressions and built-in functions (for example join, lookup, length, for expressions, and conditional a ? b : c expressions) compute values so configuration is dynamic rather than hard-coded. The habit to build is reaching for a variable and an expression instead of pasting a literal in three places.
Custom conditions (objective 4g) are the flagship NEW-in-004 topic, so study them deliberately - they are the most likely place a 003-era resource will leave you unprepared. A variable validation block lets you reject bad input at plan time with a custom error message (for example forcing an environment variable to be one of dev/staging/prod). Precondition and postcondition blocks (inside a resource's lifecycle, or on outputs and data sources) let you assert invariants before or after Terraform acts, failing the run with a clear message if an assumption is violated. The point the exam tests is that these move a whole class of errors from 'discovered at apply, or in production' to 'caught at plan, with a readable message'. Sensitive data handling (objective 4h) rounds out the domain: marking a variable or output sensitive so its value is redacted in CLI output and plans, and understanding that secrets can still land in state (which is why state must be protected), plus the option of sourcing secrets from a secrets manager such as HashiCorp Vault rather than hard-coding them.
Study this domain by writing small configurations that exercise each construct - a data source feeding a resource, a for expression, a validation block that rejects bad input - because the exam asks about syntax and behavior directly. Two labs support this domain: the variables/outputs lab (shared with the Fundamentals-of-providers domain) for the parameterization toolkit, and the custom-validation lab below, which is dedicated to the NEW-in-004 conditions - you deliberately feed it bad input and read the error the validation and postcondition blocks produce, all locally and free. As always, read the official Exam Review objective list for HashiCorp's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam objectives
HashiCorp Terraform Associate (004) Exam Review objectivesThe authoritative topic list for this broadest domain, including the NEW-in-004 custom conditions - read it directly rather than relying on any summary, including ours. (captured 2026-07-11)
Official · Official documentation
Terraform documentation: configuration language and custom conditionsHashiCorp's authoritative reference for resources and data sources, variables and outputs, types, expressions and functions, dependencies, sensitive values, and validation/precondition/postcondition blocks. (captured 2026-07-11)
Tf Assoc Custom Conditions Lab
Guard an input variable with a validation block and read the custom error it produces at plan time Assert an invariant with a lifecycle postcondition and explain how custom conditions (new in 004) catch errors before apply
Free tools
Your own machine with the Terraform CLI
A terminal
A text editor
Steps
Copy the fixture into a directory you own, initialize, and read the two validation blocks and the postcondition so you know what each guards.
Deliberately feed invalid input and read the custom error messages the validation blocks produce at plan time.
Pass valid input to apply successfully (the postcondition passing silently), then destroy so nothing persists.
What you should see
Confirm the capture shows terraform plan rejecting invalid environment and name_length with the custom messages BEFORE creation, a successful apply with valid input, and a destroy that emptied state - all with the local random provider.
Practice evidence maps to exam_domain_hashicorp_terraform_associate_04
Stay safe & legal: Run this only on your own machine in a throwaway directory; the hashicorp/random provider reaches no cloud and costs nothing, so there is no billable resource and no credential - if you later opt into a cloud provider, use your OWN free-tier account and run terraform destroy after. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 5 of 8 · domain 5 · 0% of the exam
Module sourcing scope usage and versioning
Study this fifth, right after configuration. It maps to HashiCorp's official 'Terraform Modules' domain and builds directly on the configuration language: modules are how you package configuration so it can be reused, versioned, and shared.
This is the 'package and reuse your configuration' domain, and it maps to HashiCorp's official 004 domain titled 'Terraform Modules'. A module is just a directory of Terraform configuration files that can be called from another configuration - and in fact every configuration is a module (the root module). Modules are how teams avoid copy-pasting the same blocks across environments: you write a pattern once, then call it with different inputs. It follows directly from the Configuration domain, because a module is configuration wrapped for reuse.
Module sourcing (official objective 5a) is about where a module comes from. The source argument on a module block can point to a local path (./modules/naming), the public Terraform Registry (a short 'namespace/name/provider' address), a Git repository, or other supported sources. On terraform init, Terraform downloads or links the module so it is available. The exam expects you to recognize the common source types and to know that init is what fetches them, just as it fetches providers.
Module inputs, outputs, and variable scope (official objective 5b) is the conceptual heart. A module declares input variables (its parameters) and output values (what it returns to the caller). Crucially, a module's variables and resources are scoped to that module: the caller cannot reach inside to a module's internal resource directly - it can only pass inputs in and read outputs out. This encapsulation is the whole point: the module presents a clean interface and hides its internals. When you need a value a module computes, the module must expose it as an output, and the caller references it as module.NAME.OUTPUT.
Using modules (official objective 5c) is calling one. You write a module block, set its source, and supply values for its input variables, then reference its outputs elsewhere. The same module can be called multiple times with different inputs, and each call is a distinct instance with its own state namespace (module.web.* versus module.api.*) - so calling a naming module twice produces two independent sets of resources. count and for_each can be applied to a module block to instantiate it many times. The exam tests understanding that module reuse is how one well-written pattern serves many needs.
Module versioning (official objective 5d) matters for modules sourced from a registry or Git. Just as you pin provider versions, you pin module versions with a version argument on the module block (for registry modules) or a ref on a Git source, so that a module upgrade is a deliberate, reviewed change rather than a surprise. Local path modules are not versioned (they are whatever is on disk), which is a distinction the exam may probe. The reproducibility theme from the provider domain returns here: pinning module versions keeps your infrastructure predictable across runs and teammates.
Study this domain by writing a small local module and calling it more than once with different inputs, because seeing the same module produce distinct, namespaced state is what makes encapsulation and reuse click. The lab below has you run a local ./modules/naming module called twice (as 'web' and 'api'), inspect the module-namespaced state entries, and read how inputs flow in and outputs flow out - all locally and free with the random provider. As always, read the official Exam Review objective list for HashiCorp's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Terraform documentation: modulesHashiCorp's authoritative reference for module sources, inputs/outputs and scope, calling modules, and version pinning - the exact behavior this domain tests. (captured 2026-07-11)
Tf Assoc Local Module Lab
Source a local module and call it twice with different inputs on your own machine Inspect module-namespaced state and explain module input/output scope and versioning
Free tools
Your own machine with the Terraform CLI
A terminal
A text editor
Steps
Copy the fixture directory (including modules/naming) into a place you own and initialize, so Terraform links the local module.
Apply the configuration and inspect the module-namespaced state and the module-sourced outputs.
Confirm the module is reachable only through its inputs and outputs, then destroy so nothing persists.
What you should see
Confirm the capture shows init linking the local module, state entries namespaced under both module instances, outputs sourced from the module's own output, and a destroy that emptied state - all with the local random provider.
Practice evidence maps to exam_domain_hashicorp_terraform_associate_05
Stay safe & legal: Run this only on your own machine in a throwaway directory; the hashicorp/random provider reaches no cloud and costs nothing, so there is no billable resource and no credential - if you later opt into a cloud provider, use your OWN free-tier account and run terraform destroy after. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 6 of 8 · domain 6 · 0% of the exam
Terraform state backends locking drift and refactoring
Study this sixth. It maps to HashiCorp's official 'Terraform State Management' domain and goes deep on the state file you first met in the fundamentals: local versus remote backends, state locking, drift, and safe refactoring with moved blocks.
This is the 'how Terraform remembers and safely changes what it manages' domain, and it maps to HashiCorp's official 004 domain titled 'Terraform State Management'. You met state as a concept early; here you go deep. State is the file that maps your configuration to real objects, and everything about where it lives, who can change it at once, how it drifts from reality, and how you refactor it safely is tested. This is one of the most operationally important domains because state mistakes are how teams corrupt or lose track of infrastructure.
The local backend and where state lives (official objective 6a) is the starting point. By default Terraform uses the local backend, storing state in a terraform.tfstate file in your working directory. That is fine for solo learning but a problem for teams: the file can hold sensitive values, it is easy to lose, and two people cannot safely share it. Understanding that the default is local state - and its limitations - sets up why remote backends exist.
State locking (official objective 6b) protects state from concurrent corruption. When one apply is modifying state, Terraform can take a lock so a second apply cannot run at the same time and clobber it. Local state has no real locking across machines; remote backends that support locking (and HCP Terraform) provide it. The exam expects you to know that locking prevents two simultaneous operations from racing on the same state, and that a stuck lock can be force-unlocked deliberately when you are sure no other run is active.
Remote backends (official objective 6c) move state off your laptop to a shared, durable location. A backend block (or HCP Terraform's cloud block) configures where state is stored - a remote object store or HCP Terraform - so a team shares one authoritative state, benefits from locking, and keeps secrets out of local files. Migrating from local to a remote backend happens on terraform init, which offers to copy existing state to the new backend. The exam tests recognizing that remote backends are the answer to team collaboration and state durability, and that HCP Terraform is one such remote option.
Drift and safe refactoring (official objective 6d) are the day-two skills. Drift is when real infrastructure changes outside Terraform (someone edits a resource in a console), so state no longer matches reality; 'terraform plan' detects drift, and 'terraform apply -refresh-only' reconciles state with the real world without changing infrastructure. Refactoring means restructuring configuration - renaming a resource, or moving one into a module - without destroying and recreating the underlying object. The moved{} block is the modern, configuration-driven way to do this: you declare that a resource moved from one address to another, and Terraform updates state to match instead of planning a destroy-and-create. Understanding moved{} (and that a rename without it would otherwise force a replacement) is a valuable, exam-relevant skill.
Study this domain by inspecting state directly and by performing a rename that Terraform treats as a move rather than a replacement, because that is exactly the operational judgment the exam probes. The lab below has you apply a resource, inspect state with state list/show and show -json, then use a moved{} block so a rename is a state move (not destroy+recreate), and run apply -refresh-only - all locally and free with the random provider and the default local backend. As always, read the official Exam Review objective list for HashiCorp's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Terraform documentation: stateHashiCorp's authoritative reference for the state file, backends, locking, drift/refresh, and the moved block - the exact mechanics this domain tests. (captured 2026-07-11)
Tf Assoc State Refactor Lab
Inspect Terraform state with state list, state show, and show -json on your own machine Refactor a resource rename with a moved block so state moves instead of destroy-and-recreate, and run refresh-only
Free tools
Your own machine with the Terraform CLI
A terminal
A text editor
Steps
Copy the fixture into a directory you own, initialize and apply, then inspect state three ways.
Understand the moved block: copy the fixture to a scratch file, remove the moved block there, and plan it to observe the destroy-and-recreate a rename would otherwise force; do NOT apply the scratch version.
Run a refresh-only apply to reconcile state with reality without changing infrastructure, then destroy so nothing persists.
What you should see
Confirm the capture shows state list/show/-json output, a plan contrast showing the moved block avoids a destroy-and-recreate, a refresh-only run, and a destroy that emptied state - all with the local random provider and local backend.
Practice evidence maps to exam_domain_hashicorp_terraform_associate_06
Stay safe & legal: Run this only on your own machine in a throwaway directory using the default local backend; the hashicorp/random provider reaches no cloud and costs nothing, so there is no billable resource and no credential - if you later opt into a cloud provider or remote backend, use your OWN free-tier account and run terraform destroy after. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 7 of 8 · domain 7 · 0% of the exam
Infrastructure maintenance with import state inspection and logging
Study this seventh. It maps to HashiCorp's official 'Maintain Infrastructure with Terraform' domain - the day-two skills of bringing existing objects under management with import, inspecting state, and reading verbose logs to diagnose problems.
This is the 'operate and maintain what already exists' domain, and it maps to HashiCorp's official 004 domain titled 'Maintain Infrastructure with Terraform'. Where earlier domains built new infrastructure, this one is about the ongoing life of it: adopting resources that were created outside Terraform, inspecting the current state, and turning on verbose logging when something misbehaves. These are the skills a practitioner uses after the first apply, and the exam tests each directly.
Importing existing resources (official objective 7a) is bringing an object that already exists into Terraform management. The 'terraform import' command associates a real object (identified by its provider-specific ID) with a resource address in your configuration, writing it into state so Terraform manages it going forward. In Terraform 1.5+ you can also use an import block to declare imports in configuration and preview them in a plan. The critical exam point: import writes to state, but you must still write matching configuration for the resource - import does not generate your HCL for you (though newer workflows can help generate it). Import is how you avoid recreating infrastructure you already have.
State inspection at the CLI (official objective 7b) is your window into what Terraform manages. 'terraform state list' enumerates the resource addresses in state; 'terraform state show ADDRESS' prints a resource's tracked attributes; and 'terraform show' (optionally '-json') renders the whole state or a saved plan, with -json giving machine-readable output for tooling. There are also state-mutating subcommands (state mv, state rm) for advanced surgery, though modern refactoring prefers the moved block from the State Management domain. The exam expects you to know which inspection command answers 'what does Terraform think exists and what are its attributes'.
Verbose logging (official objective 7c) is how you diagnose a stubborn problem. Setting the TF_LOG environment variable (to TRACE, DEBUG, INFO, WARN, or ERROR) makes Terraform emit detailed logs of what it and its providers are doing - invaluable when a provider call fails mysteriously or a plan behaves unexpectedly. TF_LOG_PATH sends those logs to a file. TRACE is the most verbose. The exam expects you to know that TF_LOG turns on debug logging and roughly what the levels mean; you would not normally run with it on, but you reach for it when you need to see under the hood.
The unifying theme is that maintenance is about visibility and adoption: you import so Terraform can manage what predates it, you inspect state to understand the managed world, and you enable verbose logging to see why something went wrong. These are less about writing new configuration and more about operating an existing estate responsibly - and because import writes to state and logging can expose sensitive detail, they are also places to be careful.
Study this domain by importing a resource you created by hand and by turning on TF_LOG to watch Terraform work, because the exam asks what each command and variable does. The Docker lifecycle lab below (shared with the Core Workflow domain) is the natural home for this: you run a real local container, inspect its state, import a hand-created container into management, and run a plan with TF_LOG=DEBUG to read verbose provider logs - all against LOCAL Docker only, with zero cloud spend. As always, read the official Exam Review objective list for HashiCorp's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
HashiCorp Developer: Docker Get Started tutorialsHashiCorp's own free, fully local Docker tutorial series that runs the entire init-to-destroy lifecycle with no cloud account - the safe hands-on ground for import, state inspection, and logging practice. (captured 2026-07-11)
Tf Assoc Docker Import Logging Lab
Run and inspect a local Docker container managed by Terraform and import a hand-created container into state Enable verbose TF_LOG provider logging to diagnose a Terraform run on your own machine
Free tools
Your own machine with the Terraform CLI
Local Docker (Docker Desktop or Docker Engine)
A terminal
Steps
With Docker running and port 8000 free, copy the fixture into a directory you own, initialize, apply, and inspect the managed container in state.
Enable TF_LOG=DEBUG for a plan to read verbose provider logs, then unset it.
Destroy the managed container, create one by hand, import it into Terraform management with a matching config, confirm a no-change plan, then tear everything down.
What you should see
Confirm the capture shows a container tracked in state, verbose DEBUG logs from a TF_LOG plan, a hand-made container imported with a matching config and a no-change plan, and a teardown leaving no lab containers - all against local Docker only.
Practice evidence maps to exam_domain_hashicorp_terraform_associate_07
Stay safe & legal: This lab drives ONLY your own local Docker daemon on your own machine - no cloud provider and no credentials, so there is nothing billable; run only the lab's own containers, never import or manage a container or resource you do not own, and tear everything down with terraform destroy plus docker cleanup. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 8 of 8 · domain 8 · 0% of the exam
HCP Terraform workflow collaboration governance and integration
Study this last. It maps to HashiCorp's official 'HCP Terraform' domain, layering team collaboration, remote runs, workspaces and projects, and governance on top of everything you now understand about the core workflow and state. (HCP Terraform is the current name for what was 'Terraform Cloud'.)
This is the 'run Terraform as a team, at scale, with guardrails' domain, and it maps to HashiCorp's official 004 domain titled 'HCP Terraform'. It comes last because it layers collaboration, remote execution, and governance on top of the core workflow, state, and modules you now understand. HCP Terraform is HashiCorp's hosted platform - it is the current name for what used to be called 'Terraform Cloud', and 004 uses the HCP Terraform name throughout, so use it too. There is a free tier that needs an account but no credit card, which is exactly what you use to study this domain safely.
Creating and running infrastructure in HCP Terraform (official objective 8a) is the remote-execution story. Instead of running plan and apply on your laptop, HCP Terraform runs them remotely in a consistent, controlled environment. You connect your configuration to HCP Terraform with a cloud block in your terraform{} block (naming an organization and a workspace), authenticate with 'terraform login', and then 'terraform init' attaches the workspace and 'terraform apply' triggers a remote run you approve in the web UI. State is stored remotely and securely by default. The exam expects you to know that HCP Terraform executes runs remotely and stores state for you.
Collaboration and governance (official objective 8b) is why teams adopt it. HCP Terraform gives a shared run history, remote state with locking, and controlled variable storage (including sensitive variables kept out of your files). Governance features layer policy on top: policy-as-code (Sentinel or OPA) can enforce rules a plan must satisfy before it is allowed to apply, and role-based access controls who can do what. The exam wants you to recognize that HCP Terraform turns the solo workflow into a governed team workflow - approvals, policy checks, and an audit trail - rather than each person applying from their own machine with their own state.
Workspaces and projects (official objective 8c) are how HCP Terraform organizes work. A workspace is an isolated environment with its own state, variables, and run history - typically one per environment or component (for example a 'staging' and a 'prod' workspace). Projects group related workspaces for organization and access control. Note that HCP Terraform workspaces are a different concept from the CLI's 'terraform workspace' feature (multiple named states in one backend); the exam may test that distinction. The takeaway is that workspaces isolate state and configuration boundaries so teams can manage many environments cleanly.
Integration (official objective 8d) is how HCP Terraform fits a delivery pipeline. It can connect to version control so that a commit or pull request triggers a plan (VCS-driven runs), integrate with CI/CD, and expose an API and provider for automation. The private module registry lets an organization publish and version its own modules for internal reuse. The exam expects you to recognize that HCP Terraform is designed to slot into a git-centric, automated workflow rather than to be driven only by hand.
Study this domain by actually connecting a tiny configuration to a free HCP Terraform account and watching a run execute remotely, because seeing the remote run and the workspace UI is what makes collaboration and governance concrete. The lab below has you sign up for the free tier (no card), add a cloud block, run 'terraform login' and a remote apply of a local-only random resource (so NO cloud infrastructure is deployed), and tour the workspace's state versions, run history, variables, and settings. As always, read the official Exam Review objective list for HashiCorp's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
HashiCorp Terraform Associate (004) sample questionsHashiCorp's own small set of official-format sample questions across all eight domains, useful to check familiarity with the question style; a readiness check, not a coverage guarantee (the pool is small). (captured 2026-07-11)
Tf Assoc Hcp Terraform Lab
Connect a configuration to a free HCP Terraform account and run a remote apply whose only resource is a local value Tour an HCP Terraform workspace's state versions, run history, variables, and settings to see collaboration and governance
Free tools
Your own machine with the Terraform CLI
HCP Terraform (app.terraform.io) free tier
A web browser
Steps
Create a free HCP Terraform account and workspace (no card), copy the fixture into a directory you own, and edit the cloud block to your own organization and workspace name.
Authenticate, attach the remote workspace, and run a remote apply whose only resource is a local random value; approve it in the UI.
Tour the workspace UI (state versions, run history, variables, settings), then run a remote destroy and optionally delete the workspace/org.
What you should see
Confirm the evidence shows a free (no-card) HCP Terraform account, a cloud-block connection, a remotely-executed apply of a local-only resource, a tour of the workspace UI, and a clean remote destroy - with no cloud infrastructure deployed and no secrets shared.
Practice evidence maps to exam_domain_hashicorp_terraform_associate_08
Stay safe & legal: Use ONLY a free HCP Terraform account and organization you create yourself, never a work, school, employer, or client organization; the free tier needs an account but NO credit card, and the only managed resource is a LOCAL random value, so no cloud infrastructure, no cloud credential, and nothing billable is involved. Account required: yes; payment required: no; maximum designed cost: $0.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Before you book the exam
Work through the modules above, then get a personalized read on where you stand: the readiness check maps your background against these same published domains and suggests what to study first — no score, no pass prediction.
Exam format: A conceptual, provider-agnostic exam (not performance-based): a mix of multiple-choice, multiple-answer, and true/false questions delivered online-proctored through Certiverse. The exam code is HCTA0-004. Provider-specific cloud knowledge is not required to pass. Official HashiCorp Infrastructure Automation certifications page
Passing score: HashiCorp does not publish a numeric passing score for the Terraform Associate exam, so we do not state one - be wary of any source that quotes a specific percentage as official. Prepare to comfortably clear every objective on the Exam Review page rather than aiming at a number. Official HashiCorp Infrastructure Automation certifications page (no passing score published)
Version currency: The 004 exam (HCTA0-004) went live 2026-01-08 and the previous 003 exam retired 2026-01-07; 004 targets Terraform 1.12-era features, including the custom validation and precondition/postcondition conditions new to this version. Always diff the current Exam Review objectives before you schedule. Official HashiCorp Terraform Associate (004) Exam Review page
Recommended experience: Basic comfort at a command line is required; cloud familiarity helps but is not required, and no software-development background is needed. Because the exam is provider-agnostic, you can prepare entirely with free local providers. Official HashiCorp Terraform Associate (004) Exam Review page
A free, source-cited study companion built on HashiCorp's published Terraform Associate (004) Exam Review objective list, for independent study only. It is not official training, is not affiliated with or endorsed by HashiCorp, and is not a pass guarantee. Terraform Associate is a provider-agnostic, entry-level exam, and every hands-on lab here runs on the free Terraform CLI with zero-cost local providers (or a free HCP Terraform account that deploys no cloud infrastructure), always ending with terraform destroy. HashiCorp does not publish domain weights or a numeric passing score; verify the current objectives on the official Exam Review page before your exam.
Certification and vendor names are used only to identify the program this independent study companion refers to. RoleMath is not affiliated with, endorsed by, or sponsored by HashiCorp.