On this page
Intro
HashiCorp Certified: Terraform Associate (004) validates the basic skills of cloud engineers who use Terraform to define infrastructure as code. HashiCorp describes the audience as people with working knowledge of Terraform Community Edition and HCP Terraform, and it lists basic terminal skills and a basic understanding of on-premises and cloud architecture as prerequisites. The exam tests Terraform 1.12. CertMonk can help organize review alongside hands-on practice writing and running configurations. The details come from HashiCorp’s certification page.
Unlike a hands-on lab exam, this one is a multiple-choice test. Even so, the questions reward people who have run the commands, read the plan output and seen state change.
Exam at a glance
| Detail | Terraform Associate (004) |
|---|---|
| Exam code | Terraform Associate (004) |
| Questions | Count not stated on the reviewed pages |
| Time | 1 hour |
| Passing score | See the vendor’s exam page; the reviewed pages do not state it |
| Question types | Multiple choice, online proctored, in English |
| Price | Check the vendor’s site for current pricing |
| Retirement | Date for the previous version (003) not listed on the reviewed page; the credential is valid for 2 years |
Sources: HashiCorp certification page and exam content list, reviewed November 7, 2026.
Version update. The current exam is version 004, which tests Terraform 1.12 and includes HCP Terraform content. HashiCorp’s materials point to a section on the differences between the 003 and 004 exams. If a course or book was written for 003, compare it with the 004 content list and fill the gaps. The published wording for some configuration objectives, such as sensitive data and secrets management, has varied between HashiCorp pages, so rely on the content list when the two differ.
Exam domains and weights
HashiCorp’s reviewed pages list eight objective areas and do not publish a percentage weight for each. This guide leaves the weights out rather than guessing.
| Domain | Weight | In plain English |
|---|---|---|
| Infrastructure as Code (IaC) with Terraform | Not published | Why IaC, and how Terraform fits multi-cloud and hybrid work. |
| Terraform fundamentals | Not published | Providers, versions and how state is used. |
| Core Terraform workflow | Not published | Init, validate, plan, apply, destroy and formatting. |
| Terraform configuration | Not published | Resources, data, variables, outputs, expressions, dependencies, validation and sensitive data. |
| Terraform modules | Not published | Sourcing, using and versioning modules, and variable scope. |
| Terraform state management | Not published | Backends, locking, remote state and drift. |
| Maintain infrastructure with Terraform | Not published | Import, state inspection and logging. |
| HCP Terraform | Not published | Collaboration, governance, workspaces and projects. |
Use the exam content list as your checklist and check it for updates.
What each domain really tests
Infrastructure as Code (IaC) with Terraform
Start with the reasons. Be able to explain what infrastructure as code is, the advantages it brings, and how Terraform supports multiple clouds, hybrid environments and services beyond cloud providers. Write the explanation in your own words, because definition questions are easy to miss when the wording differs from what you memorized.
Terraform fundamentals
Learn what a provider does, how to install and constrain provider versions, and how to write a configuration that uses more than one provider. Then study state: what Terraform records, why it records it and how Terraform uses it to decide what to change.
Build a small configuration, run it and open the state file to see how the real world and your code are linked.
Core Terraform workflow
Know the workflow from initialization through validate, plan, apply and destroy, including formatting and style. For each command, write what it reads, what it changes and what output to expect. Run each one often enough that the plan output feels familiar.
Practice explaining a plan: what will be created, changed or destroyed, and why.
Terraform configuration
This area is broad. Cover resource and data blocks, attribute references, variables, outputs, complex types, expressions, built-in functions, dependencies, custom validation conditions and handling sensitive data, including secrets from external systems.
For each language feature, write a short example and predict the plan before running it. Comparing your prediction with the actual output builds the intuition that questions test. Keep a list of the objectives that mention lifecycle behavior and review them against the current content list.
Terraform modules
Learn how modules are sourced, how variables and outputs pass values in and out, how scope works and how versions are managed. Refactor a small configuration into a module, then call it twice with different inputs.
Terraform state management
Study the local backend and state locking, remote state configured through a backend block and how to detect and manage drift. Explain what can go wrong when two people run Terraform against the same state without locking.
Maintain infrastructure with Terraform
Practice importing existing infrastructure, inspecting state through the command line and turning on verbose logging to troubleshoot. For each task, write when you would use it and what it changes.
HCP Terraform
Cover how HCP Terraform supports collaboration and governance, how workspaces and projects organize work and how integrations connect to version control and other systems. The study guide for 004 also lists topics such as variable sets, teams, dynamic credentials, policy and change requests. Check the current content list for exactly which ones are in scope.
The topics above follow HashiCorp’s published objectives; the exercises are our learning approach.
A realistic six-week study plan
This plan assumes you can use a terminal and have seen cloud concepts. It is a suggested schedule, not a promise about readiness. Add time if infrastructure as code is new.
Week 1: concepts, providers and state
Install Terraform, read the objectives and write a first configuration. Inspect the state it creates.
Week 2: the core workflow
Run init, validate, plan, apply and destroy repeatedly. Predict each plan before you run it.
Week 3: configuration
Work through variables, outputs, expressions, functions, dependencies and validation. Add untimed practice and review every uncertain choice.
Week 4: modules and state management
Refactor into modules, configure a remote backend and explore locking and drift. Leave one session open for catch-up.
Week 5: maintaining infrastructure and HCP Terraform
Practice import, state inspection and logging. Then study HCP Terraform workspaces, projects and governance features.
Week 6: mixed review under time pressure
With a one-hour exam, practice pacing. Add timed sets, inspect your reasoning and spend remaining sessions on recurring gaps.
Make a deliberate readiness decision. Finishing six weeks is an organizational milestone, not proof of readiness.
Common mistakes and how to avoid them
- Reading without running. Predict and compare plan output in a real configuration.
- Skipping HCP Terraform. It is one of the eight objective areas.
- Studying version 003 material only. Compare older resources with the 004 content list.
- Confusing configuration and state. Be able to explain what each one records.
- Ignoring sensitive data topics. Know how secrets should and should not appear in configuration and state.
- Rushing into timed practice. Build clear reasoning untimed first, then use the clock to check pacing.
How to use practice questions well
After each practice item, explain why the chosen answer fits and why each alternative does not. Review wrong-answer explanations for the assumption that misled you, then try the matching command in a small configuration to confirm the behavior.
CertMonk includes explanations for every answer choice, randomized practice tests, timed and untimed modes, flip-card flashcards, study games and progress by exam domain. Use the domain view to choose follow-up work, and flashcards for brief review of commands and terms.
Keep a separate list of correct guesses and revisit them later without the answer choices in front of you. When you add timed practice, use the result to investigate your preparation rather than to predict an exam outcome.
Free practice questions
Use the free Terraform Associate samples below to explore the explanations and spot areas to review without a purchase.
A team manages its cloud networks by clicking through vendor consoles. Changes are hard to review before they happen, and the staging network never quite matches production. Which benefits would the team gain by defining this infrastructure in Terraform configuration? (Choose two.)
Choose 2.
- AEngineers no longer need to understand the cloud services they are configuring
- BChanges can be proposed and reviewed as code in version control before being applied
- CThe infrastructure can never drift from the configuration once it has been applied
- DProvider credentials are no longer needed to create or change the cloud resources
- EOne configuration can create consistent environments such as staging and production
Show the answer and explanation
Answer: B. Changes can be proposed and reviewed as code in version control before being applied and E. One configuration can create consistent environments such as staging and production
Correct. Configuration kept in version control can go through code review, and terraform plan shows the exact effect of a change before it is applied.
Correct. The same configuration, with different input values, produces environments built the same way, which removes the manual differences between them.
Why not the others
- A. Resource arguments map to each provider’s own services and settings, so engineers still need to understand them.
- C. Anyone with access can still change resources outside Terraform. IaC makes drift detectable in a plan; it does not make it impossible.
- D. Terraform calls the providers’ APIs, so it still needs credentials with permission to make the changes.
Takeaway: IaC makes infrastructure changes reviewable, versioned, and repeatable; it does not remove credentials, domain knowledge, or the possibility of manual drift.
A module uses language features introduced in Terraform 1.9. The team wants Terraform to refuse to run this configuration with an older CLI. Which setting does this?
- AA version constraint on the hashicorp/aws provider in required_providers
- BA comment at the top of main.tf stating the minimum version
- Crequired_version = ">= 1.9" in the terraform block
- DA variable named terraform_version that CI checks before the run
Show the answer and explanation
Answer: C. required_version = ">= 1.9" in the terraform block
Correct. When the CLI version does not satisfy required_version, Terraform stops with an error before doing any work.
Why not the others
- A. A provider constraint controls provider versions and has no effect on which Terraform CLI versions may run.
- B. A comment is documentation only, and Terraform ignores it.
- D. This depends on every run going through CI, and Terraform itself would not refuse to run locally.
Takeaway: The required_version setting in the terraform block makes Terraform refuse to run when the CLI version does not satisfy the constraint.
Source: terraform block: required_version — Terraform language documentation
A team uses Terraform CLI workspaces named dev and prod with one configuration and one S3 backend. Which two statements are accurate? (Choose two.)
Choose 2.
- AEach workspace keeps its own state for the same configuration
- BThe default workspace can be deleted once other workspaces exist
- CAll workspaces use the same configuration code and the same backend settings
- DWorkspaces isolate credentials, so dev engineers cannot read prod state
- ECreating a workspace copies the configuration so edits to dev never affect prod
Show the answer and explanation
Answer: A. Each workspace keeps its own state for the same configuration and C. All workspaces use the same configuration code and the same backend settings
Correct. Workspaces let one configuration manage separate sets of resources, each with its own state data.
Correct. Code and backend configuration are shared, which is why CLI workspaces are not a strong boundary between environments.
Why not the others
- B. The default workspace always exists and cannot be deleted.
- D. All workspaces share the same backend and credentials, so access to the backend means access to every workspace’s state.
- E. The configuration is not copied; a change to the shared code can affect every workspace on its next apply.
Takeaway: CLI workspaces give separate state per workspace but share code, backend and credentials, so they are not a security boundary between environments.
A networking team manages a shared VPC in its own Terraform configuration. An application configuration must place instances in that VPC’s subnets, looking up their IDs by tag each time it plans, without managing or changing the subnets. Which construct should the application configuration use?
- AA resource block for the subnets using the same tags as the existing ones
- BA locals block holding subnet IDs that were copied from the console
- CA data block, such as data "aws_subnets", filtered on the tag
- DAn import block for each subnet so that the configuration can read its attributes
Show the answer and explanation
Answer: C. A data block, such as data "aws_subnets", filtered on the tag
Correct. Data sources read information about existing objects, including ones managed elsewhere, without taking ownership of them.
Why not the others
- A. A resource block declares objects this configuration manages, so Terraform would try to create new subnets.
- B. Hard-coded IDs are not looked up at plan time and go stale if the networking team replaces a subnet.
- D. Importing brings the subnets under this configuration’s management, which conflicts with the networking team owning them.
Takeaway: Use data sources to read existing infrastructure you do not manage; resource and import blocks take ownership.
A module is sourced from a Git repository, and production must always use the code at tag v2.3.0. Which source address accomplishes that?
- Agit::https://git.example.com/net.git?ref=v2.3.0
- Bgit::https://git.example.com/net.git, with no extra arguments
- Cgit::https://git.example.com/net.git?version=2.3.0
- DA version = "2.3.0" argument added to the module block
Show the answer and explanation
Answer: A. git::https://git.example.com/net.git?ref=v2.3.0
Correct. The ref query argument selects a branch, tag or commit, so a tag pins the exact code that is installed.
Why not the others
- B. Without a ref, Terraform uses the repository’s default branch, which can change under production.
- C. The version argument is not part of Git source addresses, so it does not select a tag.
- D. The version argument works for registry modules and is not supported with Git sources.
Takeaway: Pin Git-sourced modules with ?ref= (tag, branch or commit); the version argument applies only to registry modules.
FAQ
Which version of the exam is current?
HashiCorp lists Terraform Associate (004), which tests Terraform 1.12. See the certification page.
How long is the exam?
HashiCorp lists a one-hour, multiple-choice exam that is online proctored. The reviewed pages do not state the number of questions.
Does it include HCP Terraform?
Yes. HCP Terraform is one of the eight objective areas in the published content list.
How long is the credential valid?
HashiCorp lists a validity of 2 years.
Do I need cloud experience?
HashiCorp lists basic terminal skills and a basic understanding of on-premises and cloud architecture as prerequisites.
How long should I study?
Use six weeks as a starting framework if you already use the command line. Add time where your notes show gaps.
Next step
Try free practice questions → https://app.certmonk.app/samples
