The HashiCorp Certified: Terraform Associate is not a memorisation exam in the way a vocabulary quiz is. It checks whether you understand how Terraform thinks about infrastructure: that you describe a desired end state in configuration, that Terraform compares that desired state with a recorded state and the real world, and that it then plans and makes only the changes needed to reconcile them. Almost every concept on the exam, from the core workflow to state to modules, is a different angle on that one idea. This guide is a full, self-study course. It walks through each objective area in depth, explains the reasoning behind the commands rather than just listing them, shows where state and modules actually bite, and then turns all of it into a week-by-week plan with a final-preparation routine. It is original teaching material and study guidance only. It contains no exam questions of any kind, and you should always confirm the current version and objectives against HashiCorp’s own certification page before you book.
Chapter 1: Exam overview and how to use this guide
What the Terraform Associate measures
The exam validates that you can use Terraform competently for everyday infrastructure as code: write configuration, run the core workflow, manage state safely, reuse code with modules, and work with HashiCorp’s managed platform, HCP Terraform. It is deliberately pitched at the entry-to-intermediate level. It does not ask you to design a large platform or write advanced custom providers; it asks whether you understand the building blocks well enough to use them without causing damage. The single most useful planning fact is that HashiCorp publishes the objective areas but does not publish a percentage weight for each one, so you cannot safely skip a topic on the assumption it is lightly tested. Treat all eight objective areas as fair game, and give state extra attention because it underpins so much of the rest.
The format is around 57 questions in 60 minutes, a mix of multiple choice, multiple response, and true/false items, delivered online-proctored. Because the sitting is short, pace matters: roughly a minute per question means you cannot afford to agonise. HashiCorp reports the result as pass or fail and does not publish a fixed numeric passing score on its certification page, so the sensible target is simple competence across every objective rather than chasing a specific percentage. The credential is valid for two years, after which you recertify against whatever version is current.
Why version 004 matters
This is important enough to state plainly: the current exam is Terraform Associate 004, which replaced 003 in January 2026. Studying the wrong version is the most avoidable mistake you can make, because the objectives shifted. Version 004 aligns with newer Terraform releases and treats HCP Terraform as a first-class topic in its own right. The product formerly called Terraform Cloud was renamed HCP Terraform, and that name is used throughout the current objectives, so if your study notes still say “Terraform Cloud” they are out of date in vocabulary even where the underlying ideas are unchanged. The 004 objectives also lean harder into real production concerns: managing resource drift, handling sensitive data and secrets (the configuration objective references Vault for this), validating configuration with custom conditions, and working with complex types and expressions. None of that should intimidate you, but it tells you where to spend time.
How to use this course
Read the chapters in order at least once. Chapter 2 builds the mental model that every later chapter depends on, and the state chapter in particular will only make sense once the core workflow is clear. Treat the bold concept names as a checklist: by the end you should be able to explain each in a sentence and, just as importantly, do it at a terminal. The thread running through the whole guide is that Terraform is best learned by running it, so wherever a concept is easy to misread, a short worked illustration appears to make it concrete. These illustrations are teaching examples, not exam items. The final three chapters convert the content into a schedule, a final-preparation routine, and a description of exam day.
Chapter 2: Infrastructure as code and Terraform fundamentals
This chapter covers the first two objective areas together, because they form a single foundation: what infrastructure as code is, why Terraform in particular, and the fundamental pieces (providers and state) that everything else builds on.
What infrastructure as code actually is
Infrastructure as code (IaC) means describing your infrastructure, the servers, networks, databases, and the rest, in configuration files rather than creating it by hand in a web console. The configuration is the source of truth, so it can be committed to version control, reviewed in a pull request, and reproduced exactly in another environment. The exam wants you to be able to articulate the advantages of this clearly: it makes infrastructure versioned (you can see what changed and roll back), repeatable (the same configuration produces the same result), reviewable (changes go through the same process as application code), and consistent (you eliminate the subtle drift that creeps in when humans click through consoles differently each time). A useful way to hold the idea: IaC turns “I think someone set up the staging database like production, probably” into a file you can read.
Terraform’s flavour of IaC is declarative. You describe the end state you want, not the step-by-step commands to get there, and Terraform works out the actions. This contrasts with an imperative approach, where you script each step yourself. The practical consequence, and a favourite theme of the exam, is that you can run the same configuration repeatedly and Terraform will only make changes when reality differs from your declared desired state. That property is called idempotency, and it is why re-applying an unchanged configuration is safe.
Why Terraform, and the provider model
Terraform’s defining strength is that it is provider-agnostic. A provider is a plugin that teaches Terraform how to talk to a particular platform’s API, AWS, Azure, Google Cloud, Kubernetes, and hundreds of others, and you can use several providers in one configuration. This is what people mean when they say Terraform supports multi-cloud and hybrid workflows: the same tool and the same language manage resources across different platforms, so you learn one workflow instead of one per cloud. The 004 objectives explicitly call out explaining multi-cloud, hybrid-cloud, and service-agnostic workflows, so be ready to say why a single declarative tool across providers is valuable, not just that Terraform can do it.
Providers are not bundled into Terraform; they are downloaded when you initialise a working directory, and you can and should pin their versions so a configuration behaves the same tomorrow as today. As a teaching example of why the provider model matters: if your project provisions an AWS database and a Cloudflare DNS record, one configuration with the AWS and Cloudflare providers manages both, and a single apply keeps them in step, which is exactly the kind of cross-platform consistency IaC promises.
State, introduced
The fundamentals objective also asks you to explain how Terraform uses and manages state, and it is worth meeting the idea here even though Chapter 5 treats it in full. State is Terraform’s record of the real-world resources it manages: a mapping between the resources described in your configuration and the actual objects that exist in your cloud account. Terraform needs this record because the cloud’s API does not, by itself, tell Terraform “you created this exact server last week.” When you run a plan, Terraform compares three things: your configuration (desired), the state file (what it believes it last created), and the real infrastructure (what is actually there). Holding that three-way comparison in your head is the key to understanding almost every state question on the exam.
Chapter 3: The core Terraform workflow
The core workflow is the spine of Terraform and of the exam. The objective frames it as a sequence of commands, but the deeper point is the discipline it enforces: you always preview before you change, and you always let the tool make the change rather than editing infrastructure by hand.
Write, then initialise
The workflow begins with write: you author configuration in HCL (HashiCorp Configuration Language), describing the resources you want. Before Terraform can do anything with that configuration, you run terraform init. This initialises the working directory: it reads which providers your configuration needs, downloads them, sets up the backend where state will live, and installs any modules you reference. A common point of confusion the exam probes is that init is the command that brings in providers and modules, so if you add a new provider or module to your configuration, you run init again. Two supporting commands belong here too: terraform fmt rewrites your files to the canonical style so formatting is consistent, and terraform validate checks that the configuration is internally valid (correct syntax, sane references) without contacting any real infrastructure. The 004 objectives list both formatting and validation explicitly, so do not treat them as optional niceties.
Plan: preview before you change
terraform plan is the safety step that defines Terraform’s culture. It compares your desired configuration against the current state and the real world, then shows you exactly what it intends to do: which resources it will add, change, or destroy, without touching anything yet. Reading a plan correctly is a genuine exam skill. The crucial distinction to internalise is between plan (preview, no changes) and apply (actually make the changes); confusing the two is one of the most common errors. A second subtlety worth knowing: some changes can be made in place, while others force Terraform to destroy and recreate a resource because the underlying API does not allow that attribute to change on a live object. The plan tells you which is happening, and noticing a “must be replaced” in a plan is what stops you from accidentally tearing down a database you meant to tweak.
Apply and destroy
terraform apply carries out the actions from the plan, creating, updating, or deleting real resources to match your configuration, and then updates the state file to reflect what now exists. By default it shows the plan again and asks for confirmation, which is a deliberate guardrail. terraform destroy is the inverse: it removes the infrastructure Terraform manages, again showing you what it will delete and asking for confirmation. The mental model to carry through the exam is a loop: you change the configuration, plan to see the consequences, apply to enact them, and the state file is kept in step at each apply so it always reflects reality. As a teaching example of the rhythm: to add a tag to a server you edit the configuration, run plan and see a single in-place change, run apply and confirm, and the state now records the new tag, no console clicking, and a reviewable history of exactly what changed.
Chapter 4: Reading, writing, and modifying configuration
This is the largest configuration-focused objective and, in 004, a noticeably richer one. It covers HCL itself, the building blocks (resources, data sources, variables, outputs), the glue (references, expressions, functions, dependencies), and the newer emphases on complex types, custom validation, and handling secrets.
Resources versus data sources
The two foundational block types are easy to confuse and frequently tested. A resource block describes a piece of infrastructure that Terraform creates and manages, a virtual machine, a storage bucket, a DNS record. A data source block reads existing information from a provider without creating or managing anything; you use it to look up something that already exists, such as the ID of an image or a network you did not create in this configuration. The one-line test that resolves most questions: if Terraform is responsible for the object’s lifecycle (it made it, it can change it, it can destroy it), that is a resource; if Terraform is only fetching details about something it does not own, that is a data source.
Variables, outputs, and references
Input variables parameterise a configuration so the same code can be reused with different values, an instance size, a region, a name. Output values expose results after an apply, such as a server’s IP address or a database connection string, so other configurations or a human can consume them. Between resources, you create references: when one resource’s argument points at another resource’s attribute, Terraform reads that as a relationship. References are not just for convenience; they are how Terraform infers order, which the next section explains. The 004 objectives also ask you to work with complex types (lists, maps, and objects, not just single strings and numbers) and to write dynamic configuration using expressions and functions, so be comfortable building a value out of a function call or iterating over a collection, rather than only hard-coding literals.
Built-in functions, dependencies, and ordering
Terraform provides built-in functions for manipulating strings, numbers, and collections (for example, joining a list into a string or looking a value up in a map). You cannot define your own functions, so the exam expects familiarity with the idea and the common categories rather than memorising every function. Dependencies determine the order in which Terraform creates, changes, or destroys resources. Most dependencies are implicit: because resource B references an attribute of resource A, Terraform knows A must exist first and orders them automatically. Occasionally you need an explicit dependency, declared with depends_on, when one resource relies on another but does not reference it directly. The principle to carry into the exam is that you should let Terraform infer order from references wherever possible and reach for depends_on only when there is a real dependency the references do not express.
Custom conditions and handling secrets
Two 004 emphases round this out. Custom conditions let you validate configuration, for example asserting that an input variable falls within an allowed range, so that a bad value fails fast with a clear message instead of producing a broken apply. And the objective explicitly covers managing sensitive data and secrets, including using Vault, because hard-coding passwords or keys into configuration (where they would land in state and version control) is exactly the production hazard the exam wants you to avoid. You do not need Vault expertise, but you should understand why secrets need careful handling in Terraform: state can contain sensitive values, so it must be treated as sensitive itself, a point that connects directly to the state chapter.
Chapter 5: Terraform state management
State is the topic most worth mastering, both because it underpins everything Terraform does and because it is consistently the area learners misunderstand. Give this chapter, and the hands-on practice behind it, more time than any other.
What state is and why it exists
As introduced in Chapter 2, state is Terraform’s record of the real resources it manages, stored by default in a file called terraform.tfstate. Its job is to map your configuration to reality so Terraform can tell what already exists, what has changed, and what it needs to do. Without state, Terraform would have no memory of the specific objects it created and could not reliably plan incremental changes. This is why the state file is precious: deleting or corrupting it does not delete your infrastructure, but it can leave Terraform unable to recognise resources it previously managed. The exam expects you to treat state as a critical, sensitive artefact, partly because it can contain sensitive values from your resources.
Local versus remote backends
A backend determines where state is stored and, in some cases, where operations run. The default is the local backend, which keeps state in a file on your machine, fine for learning, but unworkable for a team, because two people cannot safely share a file on one laptop. A remote backend stores state in a shared location (cloud object storage, or HCP Terraform) so a whole team works against one authoritative state. The 004 objectives specifically ask you to describe the local backend and to configure remote state using a backend block, so understand both ends: why local is the starting point and why teams move to remote. The migration itself is a recognised operation, Terraform can move existing state into a new backend when you reconfigure it.
State locking and drift
Two further state concepts are heavily tested. State locking prevents two operations from modifying the same state at the same time; without it, two simultaneous applies could corrupt the state or make conflicting changes. Remote backends that support locking acquire a lock for the duration of an operation and release it afterwards, which is one of the main reasons teams use remote state. Resource drift is the situation where the real infrastructure has changed outside Terraform, someone edited a setting in the console, so reality no longer matches the state. Terraform detects drift during a plan (it refreshes its view of the real world and shows you the difference) and proposes to bring things back in line with your configuration. Understanding drift is understanding the three-way comparison from Chapter 2 in action: configuration says one thing, state recorded another, the real world now shows a third, and the plan reconciles them. As a teaching example: if a colleague manually changes a server’s instance type in the cloud console, your next plan will surface that drift and offer to revert it to whatever your configuration declares, which is precisely why manual changes to Terraform-managed resources are discouraged.
Chapter 6: Modules, and maintaining infrastructure
This chapter combines two objective areas that are about working at scale and over time: packaging configuration into reusable modules, and the commands you use to maintain infrastructure once it exists.
What a module is and why you use one
A module is a reusable, parameterised group of resources, configuration you can call from elsewhere, passing in input variables and reading back output values. Every Terraform configuration is technically a module (the top level is the “root module”), but the exam’s interest is in writing and consuming child modules to avoid repeating yourself. The benefit is the same as functions in programming: you define a sensible unit once (say, “a web server with its security group and disk”) and reuse it across environments with different inputs, instead of copying blocks of HCL. The 004 objectives ask you to explain module sourcing, understand variable scope within modules, use modules in configuration, and manage module versions.
Sources, scope, and versioning
Module sources tell Terraform where to find a module: the local filesystem, a Git repository, or a registry. The Terraform Registry (the public registry) is a large source of official and community modules, and you can pull a vetted module instead of writing one. Variable scope is a point worth being precise about: a child module does not automatically see the root module’s variables: values must be passed in explicitly as inputs, and results must be exposed explicitly as outputs. This deliberate boundary is what makes modules reusable and predictable. Versioning matters because modules change: when you source a module from a registry you should pin it to a specific version, so an upstream update does not silently alter your infrastructure on the next init. As a teaching example of the workflow: you find a network module in the public registry, pin it to a known version, pass in your address ranges as inputs, and read the resulting network IDs from its outputs, reusing tested code rather than authoring it from scratch.
Maintaining infrastructure over time
The “maintain infrastructure” objective is about the operations you perform on existing, managed infrastructure. The headline command is terraform import, which brings an existing, unmanaged resource under Terraform’s management by recording it in state, useful when something was created by hand and you now want Terraform to own it. Note carefully what import does and does not do: it records the resource in state, but you still need configuration that matches it, so import is the bridge from “exists in the cloud but not in Terraform” to “fully managed.” The objective also covers using the CLI to inspect state (listing and examining the resources Terraform tracks) and knowing when to enable verbose logging to diagnose a problem. The mindset the exam rewards across all of this is that you make changes through Terraform and its commands, not by editing state by hand or changing infrastructure behind Terraform’s back.
Chapter 7: HCP Terraform
HCP Terraform is a dedicated objective area in 004, reflecting how teams run Terraform in practice rather than from individual laptops. Treat it as core material, not an afterthought, and use the current name (HCP Terraform), not the retired one (Terraform Cloud).
What HCP Terraform is for
HCP Terraform is HashiCorp’s managed platform for running Terraform collaboratively. Where a solo learner runs plan and apply locally with state in a file, a team using HCP Terraform gets a shared, managed home for the whole workflow: remote runs (plans and applies execute in HCP Terraform rather than on someone’s machine), shared and secured state with locking handled for you, and a place to store variables (including secrets) centrally. The reason this exists is everything Chapter 5 hinted at: as soon as more than one person manages the same infrastructure, you need shared state, locking, consistent execution, and an audit trail, and HCP Terraform provides those as a service.
Workspaces, projects, collaboration, and governance
The 004 objectives ask you to organise and use workspaces and projects, describe collaboration and governance features, and configure HCP Terraform integration. A workspace in HCP Terraform represents a distinct collection of infrastructure with its own state and variables, often one per environment or component; projects group related workspaces so larger teams can organise and control them. (Be aware that the word “workspace” also describes a CLI feature for keeping multiple states from one configuration; the exam context tells you which sense is meant, and the HCP Terraform sense is the richer, collaboration-oriented one.) On the governance side, HCP Terraform can enforce policy and control who can do what, so an organisation can require that changes meet defined rules before they are applied, and manage variables and access centrally. You do not need to operate every feature, but you should be able to explain what HCP Terraform adds over running Terraform alone: shared state and locking, remote execution, central variable and secret management, collaboration, and policy-based governance.
Chapter 8: Study plan and timeline
With the concepts understood, the remaining work is pacing them and, above all, making sure the hands-on practice and the state material do not get squeezed out. Three things drive the plan: confirming the version, running the workflow yourself rather than only reading, and giving state disproportionate attention.
Confirm the version, then learn by doing
Before anything else, confirm on HashiCorp’s certification page that you are studying 004, and read the current objectives there, since they change between versions and 004 differs meaningfully from 003. Then commit to learning by doing. Install Terraform, and for each objective area run the real commands rather than only reading about them. The exam rewards the recognition that comes from having typed init, plan, and apply dozens of times, and that recognition is almost impossible to fake from notes alone. Use any major cloud’s free tier; because Terraform is provider-agnostic, the specific cloud barely matters, so pick the one you are most comfortable with and practise the workflow against it.
A four-week default, and how to flex it
A balanced plan for someone with some cloud experience runs about four weeks part-time. Week one covers IaC concepts and Terraform fundamentals (providers, init), ending with your first real init. Week two drills the core workflow, write, plan, apply, destroy, against a free-tier cloud, and works through reading and modifying configuration: variables, outputs, complex types, functions, and dependencies. Week three is the heavy one: study state carefully (local versus remote, locking, backends, drift), then modules (sources, scope, versioning, the public registry), using a registry module in a real configuration. Week four covers HCP Terraform and the maintenance commands (import, inspecting state, workspaces), then full-length timed practice. If you use Terraform daily, compress this to a roughly two-week pass that skims concepts and concentrates on state, modules, and HCP Terraform; if you are newer to the cloud, stretch it to six weeks and spend the extra time getting hands-on with a provider and the basic workflow before the objectives. To turn whichever timeline you choose into dated weeks for your own start date, use the free study-plan generator.
Where to spend the extra hours
Because HashiCorp does not publish objective weights, you cannot study to a percentage, but two areas reliably repay extra time. State is the most tested and most misunderstood: be sure you can explain local versus remote backends, why locking exists, and how drift is detected and reconciled, and that you have actually configured a remote backend rather than only read about one. The plan-versus-apply distinction and reading a plan correctly underpin a surprising number of questions, so practise until you can look at a plan’s add/change/destroy summary and predict what will happen. If you are weighing this credential against a cloud-specific certification, remember it is designed to complement one (AWS, Azure, or GCP), not replace it, so many people pair it with a cloud associate cert rather than choosing between them.
Chapter 9: Final preparation, exam day, and format
Final preparation
In the last few days, shift from learning new material to timed practice and consolidation. Sit full-length, timed practice tests to get used to the 60-minute pace, roughly a minute a question, and review the reasoning behind every miss, especially on state and modules, rather than only noting the right answer. The goal is to be comfortably competent across all eight objective areas on fresh material before you book, with no objective you are quietly avoiding. Do your final review against the current (004) objectives, and resist the temptation of sites that leak or sell stolen test content: they breach HashiCorp’s certification policy and copyright, they do not teach you the workflow, and they will not prepare you for scenario-style questions that ask you to reason about a plan or a piece of HCL.
Recertification and how the credential fits
The certification is valid for two years, after which you recertify by passing whatever version is current at that time, so note your expiry and plan to refresh against the then-current objectives. In a career, the Terraform Associate rarely stands alone: it supplements DevOps, platform, cloud, and site-reliability roles where infrastructure as code is part of the job, and it pairs naturally with a cloud certification. If you want to go further afterwards, HashiCorp offers a more advanced, hands-on Terraform authoring and operations professional exam.
Exam day and format
On the day, expect around 57 questions in 60 minutes, a mix of multiple choice, multiple response, and true/false, delivered online-proctored, so prepare your environment and identification in advance. Pace yourself against the clock so the short sitting does not run away from you; with roughly a minute per question, flag anything you are unsure of and move on rather than stalling. Apply the reasoning you built over the weeks of study: ask whether a question is really about the three-way comparison between configuration, state, and reality; remember that plan previews and apply changes; and recall that Terraform is provider-agnostic, so the exam is about the tool, not any one cloud. Having practised the real workflow and timed yourself, the format will feel familiar rather than pressured, which is exactly the advantage the hands-on weeks were meant to build.