HashiCorp Terraform Associate (003) Practice Test
Frequently asked questions
How many HashiCorp Terraform Associate (003) practice questions are here?+
A full bank of original HashiCorp Terraform Associate (003) practice questions across the official content areas, weighted like the real exam, with explanations. Free, no signup.
What is the HashiCorp Terraform Associate (003) exam like?+
A multiple-choice exam, 60 minutes, and you need 70%% to pass. Practice by topic here, then take the full timed mock exam to gauge readiness.
Are these the real exam questions?+
No. Every question is 100% original, written from public primary sources with explanations. We never copy real exam questions or paid prep material.
Can I study in Chinese or Spanish?+
PrepPass practice is in English, 中文 and Español. The official exam is in English — switch the question language to English any time to rehearse the exact terminology you'll see on test day.
Sample practice questions
A few real questions from this free bank, with full explanations. Use the practice tool above for the whole set.
- 1. IaC Concepts & Terraform Purpose
Which statement best describes the core value of Infrastructure as Code (IaC) as practiced with Terraform?
- a.It replaces the need for any cloud provider accounts
- b.It defines infrastructure in machine-readable configuration files that can be versioned, reviewed, and reused
- c.It only works for on-premises virtual machines
- d.It guarantees infrastructure can never be changed after creation
Answer: b
Explanation: IaC expresses infrastructure as declarative configuration files that live in version control, enabling code review, repeatability, and collaboration. Terraform still requires provider credentials, works across many cloud and on-prem providers, and infrastructure can absolutely be changed by editing configuration and re-applying.
- 2. IaC Concepts & Terraform Purpose
Which of the following is a benefit that Terraform provides as a cloud-agnostic, multi-cloud provisioning tool?
- a.A single workflow and configuration language can manage resources across many providers
- b.It removes the need to learn any provider-specific resource attributes
- c.It can only manage a single provider per organization
- d.It automatically makes all clouds behave identically
Answer: a
Explanation: Terraform uses one consistent workflow (write, plan, apply) and one configuration language (HCL) to manage resources across many providers such as AWS, Azure, GCP, and Kubernetes. You still work with provider-specific resource types and attributes, and each cloud keeps its own semantics; Terraform unifies the workflow, not the clouds.
- 3. Core Workflow & CLI
What is the correct order of the core Terraform workflow when starting a new configuration?
- a.apply, then plan, then init
- b.init, then plan, then apply
- c.plan, then init, then destroy
- d.validate, then apply, then init
Answer: b
Explanation: The core workflow is init (initialize the working directory and download providers), plan (preview the changes Terraform will make), then apply (execute those changes). Running init first is required because plan and apply depend on the installed providers and backend configuration.
- 4. Core Workflow & CLI
Why is running terraform plan before terraform apply considered a best practice?
- a.It shows a preview of the actions Terraform will take so you can review them before making changes
- b.It is the only way to download provider plugins
- c.It permanently locks the configuration from further edits
- d.It uploads your credentials to HashiCorp
Answer: a
Explanation: terraform plan produces an execution plan describing what will be created, updated, or destroyed, letting you review the impact before applying. This preview reduces the risk of unexpected changes. Provider downloads happen during init, and plan does not lock files or transmit credentials to HashiCorp.
- 5. Core Workflow & CLI
A teammate wants to verify that a configuration is syntactically valid and internally consistent without contacting any provider APIs. Which command fits best?
- a.terraform apply
- b.terraform validate
- c.terraform import
- d.terraform state rm
Answer: b
Explanation: terraform validate checks that the configuration is syntactically valid and internally consistent, using only local files, without reaching out to provider APIs or refreshing state. apply makes changes, import brings existing resources under management, and state rm edits state, none of which is a lightweight local validation.
- 6. State Management
Which practice is recommended for storing Terraform state when a team collaborates on the same infrastructure?
- a.Commit terraform.tfstate to a public Git repository
- b.Use a remote backend such as Terraform Cloud or an object store with locking
- c.Email the state file to teammates after each apply
- d.Delete state after every apply to keep things clean
Answer: b
Explanation: Teams should keep state in a remote backend (for example Terraform Cloud, S3 with DynamoDB locking, or similar) that provides shared access, locking, and often encryption. Committing state to version control risks leaking secrets and causes conflicts, and deleting state would lose the mapping Terraform needs to manage resources.
- 7. State Management
What does terraform state rm do to a resource?
- a.It removes the resource from Terraform state without destroying the real infrastructure
- b.It deletes the real resource in the cloud provider
- c.It renames the resource in the configuration file
- d.It refreshes the resource's attributes from the provider
Answer: a
Explanation: terraform state rm removes a resource's entry from state so Terraform stops tracking it, while the actual cloud object continues to exist. It does not touch real infrastructure. To also delete the real resource you would use destroy, and to update tracked attributes you would refresh.
- 8. Modules & Configuration
You want to pass a value into a module and receive a computed value back out. Which pair of constructs do you use?
- a.provisioners for input and locals for output
- b.input variables for values passed in and outputs for values returned
- c.data sources for input and providers for output
- d.backends for input and workspaces for output
Answer: b
Explanation: Input variables (variable blocks) define the values a module accepts, and output values (output blocks) expose results from the module to its caller. Locals are internal helpers, data sources read existing information, and providers configure plugins, none of which serve as the module's public input/output interface.
- 9. Modules & Configuration
You need to create several nearly identical resources that differ by a value from a list. Which meta-argument iterates over a collection to create one resource instance per element with a stable key?
- a.depends_on
- b.provider
- c.lifecycle
- d.for_each
Answer: d
Explanation: for_each creates one instance per element of a map or set, keying instances by their map key or set value, which keeps instances stable when the collection changes. count also creates multiple instances but keys by numeric index, which can cause churn. depends_on, provider, and lifecycle serve other purposes.
- 10. Providers & Terraform Cloud
In Terraform, what is the role of a provider?
- a.It stores the remote state file
- b.It defines reusable groups of resources
- c.It is a plugin that lets Terraform interact with a specific API, such as a cloud platform or SaaS
- d.It formats configuration to canonical style
Answer: c
Explanation: A provider is a plugin that understands a particular API (AWS, Azure, GitHub, Kubernetes, and many others) and exposes its resource and data source types to Terraform. Providers are declared and their versions constrained so runs are reproducible. State storage is a backend concern, and reusable resource groups are modules.