HashiCorp Certified: Terraform Associate: study guide and free practice questions The ideas the Terraform Associate (004) exam tests, one page each: what HashiCorp's documentation says, the traps the questions set, and real practice questions to try. Every page links to the docs it was written from.
Topics Terraform state management Maintain infrastructure with Terraform 10 free practice questions Drawn from every domain. Pick an answer to see why each option is right or wrong.
Terraform is described as service-agnostic as well as cloud-agnostic. Which of the following does that mean it can manage? Right. In the game that’s Renown for your Infrastructure as Code (IaC) with Terraform building.
Not that one: D is right. In the game your Infrastructure as Code (IaC) with Terraform building would lose a little Renown, and this question would come back later.
Your answer A. Only resources that expose a Terraform-shaped APINo API is Terraform-shaped. The provider is the piece that adapts whatever the service offers. Your answer B. Only resources inside a single cloud providerSingle-cloud is what Terraform is contrasted against. A configuration can hold several providers at once. Your answer C. Only compute, storage and networking resourcesThat is the original scope and not the current one. Providers exist for source control, chat, identity and observability tools. The answer D. A DNS zone, a SaaS account and a monitoring alertA provider is an adapter over any API, so anything with one can be managed — DNS, identity, SaaS configuration, monitoring — not only compute and storage.
Terraform splits the work between its own core and the provider plugins. Which of the following is the provider's responsibility rather than core's? Right. In the game that’s Renown for your Terraform fundamentals building.
Not that one: A is right. In the game your Terraform fundamentals building would lose a little Renown, and this question would come back later.
The answer A. Making the API calls that create an objectCore parses the configuration, builds the graph, decides the order and manages state. The provider knows the remote API and makes the calls. Your answer B. Building the dependency graph from referencesThe graph is built by core from attribute references in the configuration. No provider is consulted to build it. Your answer C. Reading and writing the state fileState is core's, and where it lives is the backend's. A provider never sees the state file. Your answer D. Deciding the order resources are worked onOrdering falls out of the graph, so it is core's decision. The provider is told what to do and when.
A scheduled job runs terraform apply and nobody is at a terminal to answer a prompt. Which of the following lets it finish? Right. In the game that’s Renown for your Core Terraform workflow building.
Not that one: B is right. In the game your Core Terraform workflow building would lose a little Renown, and this question would come back later.
Your answer A. Pass -refresh=false to the apply-refresh=false changes what the plan is computed against and says nothing about approval.The answer B. Pass -auto-approve to the apply-auto-approve skips the interactive approval of the plan. It is the only one of these that removes the approval step; the others turn off unrelated behaviour.Your answer C. Pass -lock=false to the apply-lock=false skips taking the state lock. The run still asks whether to apply the plan.Your answer D. Pass -input=false to the apply-input=false stops Terraform prompting for variable values it is missing. It makes the run fail rather than hang on a missing variable, and the approval prompt still comes.
A data block's arguments reference an attribute of a resource the same configuration has not created yet. What happens when you plan it? Right. In the game that’s Renown for your Terraform configuration building.
Not that one: A is right. In the game your Terraform configuration building would lose a little Renown, and this question would come back later.
The answer A. During the apply, after the resource existsA data source is read during the plan when its arguments are known. When they depend on something not yet created, the read is deferred to the apply, and the plan shows the values as known after apply. Your answer B. During init, before the plan is computedinit installs providers, modules and the backend. No part of the configuration is evaluated then.Your answer C. During the plan, using the recorded stateThat is what happens when the arguments are already known. Here they are not, so there is nothing to query with yet. Your answer D. It is not read, and the plan failsUnknown values are ordinary during a plan. Terraform defers what it cannot yet resolve rather than failing.
Which of the following does HashiCorp recommend for arranging several modules in a configuration? Right. In the game that’s Renown for your Terraform modules building.
Not that one: C is right. In the game your Terraform modules building would lose a little Renown, and this question would come back later.
Your answer A. One module holding the whole configurationA single module containing everything is the configuration itself. Nothing in it can be reused or tested separately. Your answer B. One module per resource in the configurationA module per resource adds a layer of indirection with no abstraction. The caller still has to know everything the resource does. The answer C. A flat root calling single-purpose modulesModule composition means a flat root module calling several single-purpose modules, passing values between them. Deep nesting is what the guidance warns against. Your answer D. A deep tree of modules calling modulesEach level of nesting adds an interface a value must be threaded through, so a new argument becomes an edit at every level.
A configuration uses the local backend, and two people run apply from their own machines against the same infrastructure. Which of the following is true? Right. In the game that’s Renown for your Terraform state management building.
Not that one: C is right. In the game your Terraform state management building would lose a little Renown, and this question would come back later.
Your answer A. Each run refuses to start without a backendNo backend block means the local backend, not the absence of one. Both runs start happily. Your answer B. Each run shares one lock held by the providerNo provider is involved in locking. The lock belongs to whichever backend holds the state. The answer C. Each run locks a file the other cannot seeThe local backend locks with a system file lock on the state file, and each machine has its own copy. The locking works perfectly and protects nothing, because the two runs are not contending for the same file. Your answer D. Each run waits for the other's lock to clearThat is what a shared remote backend gives you. With two local state files there is nothing to wait for — each lock is uncontended.
Two resources are being created in an order nobody expects, and the configuration is large. Which of the following shows the ordering Terraform derived? Right. In the game that’s Renown for your Maintain infrastructure with Terraform building.
Not that one: A is right. In the game your Maintain infrastructure with Terraform building would lose a little Renown, and this question would come back later.
The answer A. terraform graphterraform graph emits the dependency graph in DOT format, which is the derived ordering itself rather than a guess about it.Your answer B. terraform showshow renders the contents of state or a plan. The relationships between resources are not part of that rendering.Your answer C. terraform state liststate list prints addresses. It says nothing about which depends on which.Your answer D. terraform providersterraform providers reports which providers the configuration and its modules need.
Long-lived cloud keys stored as workspace variables are to be removed, while runs keep their access. Which of the following replaces them? Right. In the game that’s Renown for your HCP Terraform building.
Not that one: A is right. In the game your HCP Terraform building would lose a little Renown, and this question would come back later.
The answer A. Dynamic provider credentialsDynamic provider credentials let a workspace authenticate with a short-lived OIDC token generated per run, so there is no stored key to leak or rotate. Your answer B. Sensitive workspace variablesMarking a variable sensitive stops it being displayed. The key is still stored, still long-lived, and still the thing you were asked to remove. Your answer C. An agent pool with the keysAn agent changes where the run executes. Whatever credentials it uses are still stored somewhere. Your answer D. A variable set holding the keysA variable set makes the keys easier to rotate by putting them in one place. They are still keys.
Some workloads run in a public cloud and some on a vSphere cluster on-premises. Which of the following describes managing both with Terraform? Right. In the game that’s Renown for your Infrastructure as Code (IaC) with Terraform building.
Not that one: A is right. In the game your Infrastructure as Code (IaC) with Terraform building would lose a little Renown, and this question would come back later.
The answer A. Both are reached through their own providersHybrid means exactly the same mechanism as multi-cloud: on-premises platforms such as vSphere, Nomad and Kubernetes publish providers, so one configuration and one workflow reach both. Your answer B. The on-premises half must be imported by handImporting is how an existing object is adopted, whichever platform it is on. It is not a limitation of on-premises platforms. Your answer C. The on-premises half needs a separate toolA second tool is the situation this removes. Both halves can sit in one configuration with a dependency between them. Your answer D. Only the public cloud half can be managedNothing about Terraform is public-cloud-specific. Core knows no platform at all; providers do.
A resource's recorded id is wrong and someone suggests opening the state file in an editor. Which of the following is the supported way to change it? Right. In the game that’s Renown for your Terraform fundamentals building.
Not that one: B is right. In the game your Terraform fundamentals building would lose a little Renown, and this question would come back later.
Your answer A. Deleting the state and applying againDeleting state makes Terraform forget every object it manages, and the next apply proposes to create all of them again. The answer B. The terraform state subcommandsterraform state exists so state is never hand-edited. A manual edit desynchronises the serial and lineage the backend uses to detect stale or foreign writes.Your answer C. An editor, then terraform initinit configures the backend and installs plugins. It does not inspect or repair state contents.Your answer D. An editor, then terraform validatevalidate checks the configuration for syntax and consistency. It never reads state, so it cannot tell you the edit was sound.
Certopolis is an independent study game. It is not affiliated with, endorsed by or sponsored by HashiCorp, and its questions are not the exams' questions. Exam names are trademarks of their owners.