HashiCorp Terraform Associate 004 Practice Exam
HashiCorp Certified: Terraform Associate (004)
The HashiCorp Certified: Terraform Associate (004) certification validates foundational Terraform knowledge for cloud engineers, tested on Terraform 1.12. The exam covers eight objective areas: Infrastructure as Code with Terraform, Terraform fundamentals, the core Terraform workflow, Terraform configuration, Terraform modules, Terraform state management, maintaining infrastructure with Terraform, and HCP Terraform. HashiCorp publishes no domain weights. This practice exam mirrors its style with single-answer, multiple-answer and true or false questions, many built around short HCL configuration snippets.
600 questions in the bank
Question bank updated : questions, answers, explanations and chapters.
Certification Overview
- Exam name: Terraform Associate 004
- Vendor: HashiCorp
- Exam code: 004
- Duration: 60 minutes
- Total questions: about 57
- Our practice exam pass mark: 70%
Who Should Take This Exam?
Cloud Engineer, DevOps Engineer, Infrastructure Engineer, Site Reliability Engineer, Platform Engineer, Cloud Architect, Systems Administrator, Solutions Architect
Prerequisites
No formal prerequisite. HashiCorp lists basic terminal skills and an understanding of on-premises and cloud architecture; professional experience is recommended, or practice in a personal demo setup.
Topics Covered
- Infrastructure as Code (IaC) with Terraform
- Terraform fundamentals
- Core Terraform workflow
- Terraform configuration
- Terraform modules
- Terraform state management
- Maintain infrastructure with Terraform
- HCP Terraform
Question Types
- Multiple Choice (Single Answer)
- Multiple Choice (Multiple Answers)
- True / False
Terraform Associate 004 Practice Questions
Our question bank contains 600+ practice questions for this certification. Sample questions from each exam chapter. Expand a question to see the answer choices. With full access, you get unlimited practice exams with randomized questions from our full question bank.
Infrastructure as Code (IaC) with Terraform
How does Terraform manage resources on several different platforms from a single workflow?
- A. By using workspaces that map to each platform
- B. By using providers that call each platform's API Correct answer
- C. By using backends that connect to each platform's API
- D. By using a separate Terraform binary for each platform
Option B is correct because providers are plugins that translate resource blocks into API calls for a specific platform, so one workflow can manage AWS, Azure, Kubernetes and more together. Workspaces separate state, backends only store state, and Terraform ships as a single binary.
What is infrastructure as code?
- A. Documenting servers in a wiki after they are built
- B. Defining infrastructure in machine-readable files Correct answer
- C. Installing agents that monitor running servers
- D. Provisioning resources by hand in a web console
Option B is correct because infrastructure as code means describing infrastructure in machine-readable files that tools read and apply, so it can be versioned and repeated. Documenting servers in a wiki, installing monitoring agents and clicking through a web console are manual or observational practices, not code that defines the infrastructure.
Terraform configuration can be written in JSON syntax in files that end in .tf.json.
- A. True Correct answer
- B. False
True. Terraform reads its configuration from files ending in .tf, written in HCL, and also from files ending in .tf.json, which hold the same constructs in JSON syntax. The JSON form is mostly used for configuration generated by other programs, and both forms can be mixed in one directory.
Terraform fundamentals
Consider the following configuration snippet: terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.4" } } } Which AWS provider versions can terraform init install?
- A. 5.4.x patch releases
- B. Any release from 5.4 upward, including 6.x
- C. Exactly version 5.4.0
- D. Any 5.x release from 5.4 onward, but not 6.0 Correct answer
Option D is correct because ~> 5.4 is the pessimistic constraint operator: it allows the rightmost component to increase, so it means >= 5.4 and < 6.0. That admits 5.4.x and later 5.x releases such as 5.31.0, but never 6.0. Option A would need ~> 5.4.0, and option C would need = 5.4.0.
What is the main purpose of the Terraform state file?
- A. To cache the configuration of downloaded modules
- B. To store the plan output that terraform apply runs later
- C. To list the provider versions locked for the working directory
- D. To map configuration resources to real infrastructure objects Correct answer
Option D is correct because the state file records which real infrastructure object each resource in the configuration manages, along with its attributes, so Terraform can plan changes. Module downloads live in .terraform, provider versions are recorded in .terraform.lock.hcl, and a saved plan is a separate file.
After a second terraform apply with the default local backend, which two files in the working directory hold state data? Pick the 2 correct responses below
- A. terraform.tfvars
- B. terraform.tfstate.backup Correct answer
- C. .terraform.lock.hcl
- D. terraform.tfstate Correct answer
- E. tfplan
Options B and D are correct because after a second apply the local backend keeps the current state in terraform.tfstate and the previous version in terraform.tfstate.backup. terraform.tfvars holds input values, .terraform.lock.hcl holds provider checksums, and tfplan is a saved plan, so none of them hold state.
Core Terraform workflow
After running terraform plan -out=tfplan and reviewing the result, which command applies exactly the reviewed changes?
- A. terraform apply -var-file=tfplan
- B. terraform apply -target=tfplan
- C. terraform apply -auto-approve
- D. terraform apply tfplan Correct answer
Option D is correct because terraform apply tfplan takes the saved plan file as its argument and applies exactly those reviewed changes without re-planning. A plan file is not a variable file or a target address, and -auto-approve only skips the prompt on a fresh plan.
A team raises the upper bound of a provider version constraint in required_providers. Which command downloads the newest version the constraint allows and updates the dependency lock file?
- A. terraform init -reconfigure
- B. terraform get -update
- C. terraform providers mirror
- D. terraform init -upgrade Correct answer
Option D is correct because terraform init -upgrade ignores the versions pinned in the lock file, selects the newest versions that match the constraints and rewrites .terraform.lock.hcl. -reconfigure only reinitializes the backend, terraform get -update refreshes modules, and providers mirror copies providers to a directory.
In the core Terraform workflow, which two commands change real infrastructure? Pick the 2 correct responses below
- A. terraform apply Correct answer
- B. terraform validate
- C. terraform plan
- D. terraform fmt
- E. terraform destroy Correct answer
Options A and E are correct because terraform apply and terraform destroy are the commands that create, change or remove real infrastructure and update state. terraform plan only previews changes, terraform validate only checks configuration syntax and consistency, and terraform fmt only rewrites file formatting.
Terraform configuration
Consider the following configuration snippet: variable "instance_count" { type = number default = 2 } The working directory contains terraform.tfvars with instance_count = 3 and prod.auto.tfvars with instance_count = 6, and the shell has TF_VAR_instance_count=4 exported. What value does var.instance_count have after terraform apply runs with no other arguments?
- A. 2
- B. 3
- C. 4
- D. 6 Correct answer
Option D is correct because Terraform loads variable values in order of increasing precedence: defaults, environment variables (TF_VAR_), terraform.tfvars, then *.auto.tfvars files, then -var and -var-file on the command line. With no command-line values, the auto.tfvars value of 6 wins over 4 from the environment and 3 from terraform.tfvars.
An EC2 instance runs a boot script that writes to an S3 bucket, but none of the instance's arguments reference the bucket resource aws_s3_bucket.logs. Which addition makes Terraform create the bucket first?
- A. lifecycle { prevent_destroy = true } in the bucket block
- B. lifecycle { create_before_destroy = true } in the instance block
- C. depends_on = [aws_instance.app] in the bucket block
- D. depends_on = [aws_s3_bucket.logs] in the instance block Correct answer
Option D is correct because depends_on in the instance block creates an explicit dependency, so Terraform creates the bucket before the instance, even though no argument references it. Option A is wrong because prevent_destroy only blocks deletion of the bucket and has no effect on creation order. Option B is wrong because create_before_destroy only changes the order when a resource is replaced, not the order of the first creation. Option C is wrong because it reverses the dependency, making the bucket wait for the instance.
Which two statements about handling sensitive values in Terraform are correct? Pick the 2 correct responses below
- A. Marking a variable sensitive encrypts its value in the state file
- B. Marking a variable sensitive hides its value in plan and apply output Correct answer
- C. Values from sensitive variables used in resources are still stored in the state file Correct answer
- D. Marking an output sensitive keeps it out of the state file
- E. Sensitive variables are removed from the plan before it is saved
Options B and C are correct because marking a variable sensitive only redacts it from plan and apply output; the real value is still written to the state file in plain text, so state storage must be protected. Sensitive does not encrypt state (A), an output marked sensitive is still stored in state (D), and the plan still carries the values needed to apply (E).
Terraform modules
A module block uses a local path as its source and also sets version = "~> 2.0". What happens when you run terraform init?
- A. Terraform checks the version against a version file in the directory
- B. The version is ignored and the local directory is used as is
- C. Terraform fetches the newest 2.x module from the public registry
- D. Initialization fails, since local path modules cannot take a version constraint Correct answer
Option D is correct because the version argument is only valid for modules from a registry. Using it with a local path source is a configuration error, and terraform init fails with a message that a version constraint cannot be applied to a module with a relative local path. Local modules are used directly from the directory and are not versioned.
Which source address identifies a module published in the public Terraform Registry?
- A. hashicorp/consul/aws Correct answer
- B. ./modules/consul
- C. s3::https://s3.amazonaws.com/mods/consul.zip
- D. github.com/hashicorp/consul
Option A is correct because public Terraform Registry modules use the <NAMESPACE>/<NAME>/<PROVIDER> form, so hashicorp/consul/aws needs no hostname or prefix. Option B is a local path, option C is an S3 archive address, and option D is a GitHub shorthand, none of which point at the registry.
Terraform state management
Consider the following configuration snippet: terraform { backend "s3" { bucket = var.state_bucket key = "app/terraform.tfstate" region = "eu-west-2" } } terraform init reports that variables may not be used here. Which change fixes this while keeping the bucket name configurable?
- A. Export TF_VAR_state_bucket before running terraform init
- B. Define state_bucket with a default value in its variable block
- C. Replace var.state_bucket with a local value named local.state_bucket
- D. Omit bucket and pass it with terraform init -backend-config Correct answer
Option D is correct because backend blocks are processed before variables or locals are evaluated, so neither var. nor local. references are allowed. A partial configuration omits bucket in the block and supplies it at init time with -backend-config="bucket=..." or a file, which keeps the name configurable. Environment variables, defaults and locals do not make var.state_bucket usable here.
A working directory has no backend block in any .tf file. Where does terraform apply write the state of the default workspace?
- A. terraform.tfstate in the user's home directory
- B. terraform.tfstate in the working directory Correct answer
- C. terraform.tfstate.d/default/terraform.tfstate
- D. terraform.tfstate inside the .terraform directory
Option B is correct because with no backend block Terraform uses the local backend with its defaults, which writes terraform.tfstate in the working directory for the default workspace. The home directory is never used. The .terraform directory holds provider plugins and the backend settings cache, not the state. terraform.tfstate.d/ is used only for non-default workspaces.
Maintain infrastructure with Terraform
Consider the following configuration snippet: import { to = aws_s3_bucket.logs id = "corp-logs-bucket" } How does this differ from running terraform import aws_s3_bucket.logs corp-logs-bucket?
- A. The block is previewed in plan, while the command changes state at once Correct answer
- B. The block requires a remote backend, while the command needs a local one
- C. The block runs after the next terraform refresh completes
- D. The block writes a matching resource block to a .tf file on every plan
Option A is correct because an import block is declarative: terraform plan shows the import and terraform apply performs it, so it can be reviewed first and is repeatable in a pipeline. The terraform import command writes to state immediately with no plan preview. Neither needs a particular backend, and the block does not wait for a refresh. A resource block is only generated once, with plan -generate-config-out.
A terraform plan shows the resources that an import block will bring into state before anything is applied.
- A. True Correct answer
- B. False
True. A terraform plan previews each import block as an "import" action, so you see which objects will be brought into state before anything is applied. Nothing is written to the state until a later apply is approved.
HCP Terraform
Which statement describes a workspace in HCP Terraform?
- A. Each one is a saved run that teammates can approve for later
- B. Each one is a private registry namespace that stores module versions
- C. Each one is a named state slice that shares variables with all other workspaces
- D. Each one has its own state, variables, and access permissions Correct answer
Option D is correct because in HCP Terraform a workspace is the unit of work that holds its own state, variables and access permissions for one collection of infrastructure. A run is a separate object, a private registry stores modules and providers, and workspaces do not automatically share variables (variable sets must be attached on purpose).
Unless the organization default is changed, a new HCP Terraform workspace uses the remote execution mode.
- A. True Correct answer
- B. False
True. Unless the organization default execution mode is changed, a new workspace uses remote execution, so plans and applies run on HCP Terraform. Agent and local execution have to be chosen on purpose at the workspace or organization level.
Free Study Guide
Read the free HashiCorp Terraform Associate 004 study guide: every exam topic explained in plain English, with diagrams, exam tips and the mistakes to avoid.
Practice with realistic mock exams to prepare for your HashiCorp certification.