HashiCorp Terraform Associate (004) Practice Exam

What the HashiCorp Terraform Associate (004) exam covers

• Infrastructure as Code (IaC) with Terraform174 questions
• Terraform Fundamentals134 questions
• Core Terraform Workflow114 questions
• Terraform Configuration139 questions
• Terraform Modules113 questions
• Terraform State Management125 questions
• Maintain Infrastructure with Terraform112 questions
• HCP Terraform126 questions

Free 004 practice test questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 1,037.

1. Question 1Infrastructure as Code (IaC) with Terraform

   A team currently provisions servers by clicking through the cloud provider's web console and following a wiki runbook. They want to adopt Infrastructure as Code with Terraform. Which BEST describes what "Infrastructure as Code" means in this context?

   • AManaging infrastructure through versioned configuration files applied automaticallyCorrect
   • BManually documenting every console click in a shared spreadsheet for audit purposes
   • CGranting developers direct SSH access to production servers to make changes faster
   • DPurchasing physical hardware in bulk to reduce per-unit provisioning cost
   ✓ Correct answer: A

   Infrastructure as Code replaces the click-through/wiki workflow with declarative HCL configuration stored in .tf files: the team writes what infrastructure should exist, commits it to version control for peer review, and runs `terraform init` and `terraform apply` to provision it automatically and reproducibly. This differs from option B, which still requires a human to perform and document every console action - the process remains manual and error-prone even though a record exists. True IaC removes the human-driven step entirely by letting the tool read the configuration and reconcile real infrastructure to match it, which is what makes deployments consistent, auditable, and repeatable across environments.

   Why the other options are wrong

   • BManually documenting console clicks in a spreadsheet is still a manual process; no tool provisions the infrastructure from it, so it fails the definition of IaC.
   • CGranting developers direct SSH access to make changes faster increases configuration drift and manual intervention, which is the opposite of the IaC goal.
   • DPurchasing physical hardware in bulk is a procurement strategy and has nothing to do with codifying infrastructure provisioning.
2. Question 2Infrastructure as Code (IaC) with Terraform

   A team standardizes a network module so that every project gets the same subnet layout. Which IaC benefit does packaging this configuration as a reusable module primarily demonstrate over manual per-project console setup?

   • AReusability and standardization of infrastructure patterns across projectsCorrect
   • BAutomatic discounting of network egress charges
   • CPermanent prevention of any future configuration change
   • DElimination of the need for any state tracking
   ✓ Correct answer: A

   Writing the subnet layout once as a Terraform module, and calling it from every project's configuration with a module block, means each team consumes the exact same reviewed, correctly structured networking pattern by supplying only a handful of inputs, rather than each project's engineers re-deriving and re-implementing the same subnet math and security posture from scratch in the console. This encodes an organizational standard into a single reusable, versioned artifact, ensures consistency across every consuming project, and sharply reduces the chance of a misconfigured or divergent network showing up in just one project. Module reuse is the primary mechanism by which IaC scales a good infrastructure pattern across an organization in a way manual, per-project console setup simply cannot replicate reliably.

   Why the other options are wrong

   • BAutomatic discounting of network egress charges is not something a module or Terraform provides; cloud pricing is set entirely by the provider and is unaffected by how the resources were provisioned.
   • CPermanent prevention of any future configuration change is false; a module is edited and re-applied like any other Terraform code whenever requirements legitimately evolve.
   • DEliminating the need for state tracking is incorrect; Terraform still records every resource a module creates in the calling configuration's state so it can detect drift and plan future changes.
3. Question 3Maintain Infrastructure with Terraform

   After importing an existing VM with terraform import azurerm_virtual_machine.legacy /subscriptions/.../vm1, what has Terraform actually done?

   • AIt recorded the existing resource in state and bound it to the configuration address so future plans manage itCorrect
   • BIt generated a complete HCL configuration block for the VM and wrote it to a file automatically
   • CIt destroyed the existing VM and recreated an identical one under Terraform's control
   • DIt copied the VM's full disk image contents into the Terraform state file
   ✓ Correct answer: A

   `terraform import azurerm_virtual_machine.legacy /subscriptions/.../vm1` writes a new entry into state that binds the configuration address `azurerm_virtual_machine.legacy` to the VM's real provider-assigned ID, so Terraform now recognizes that block as managing the already-existing machine - it demonstrates state's role as the address-to-object mapping. It does not generate matching HCL for you, so a configuration block must still be authored by hand; it never destroys or recreates the VM, since import only teaches state about an object that already exists; and state records identifiers and attributes, never a disk image.

   Why the other options are wrong

   • Bimport binds an existing object into state but does not author the HCL for you.
   • Cimport brings the resource under management without destroying or recreating it.
   • DState records identifiers and attributes, not the VM's disk image.
4. Question 4Terraform Fundamentals

   You remove an `aws_s3_bucket` resource block entirely from your configuration and run `terraform apply`. The bucket is still recorded in state. What action does Terraform take?

   • AIt plans to destroy the bucket: it is in state but not in configurationCorrect
   • BIt ignores the resource because it is no longer in configuration
   • CIt updates the bucket in place to a default configuration
   • DIt imports the bucket again to keep it managed
   ✓ Correct answer: A

   Terraform's fundamental model is to reconcile real infrastructure to match configuration, so when the aws_s3_bucket resource block is deleted from the .tf files but the bucket remains in state, Terraform concludes it is no longer desired and plans a Delete, shown as "1 to destroy." On apply, the provider's delete function removes the real bucket and Terraform then drops the entry from state entirely. If the intent was only to stop managing the bucket without deleting it, the correct approach is terraform state rm or a removed block with destroy = false, not simply deleting the resource block and applying.

   Why the other options are wrong

   • BIgnoring the resource would leave it running as orphaned, unmanaged infrastructure, which directly contradicts Terraform's core model of reconciling real infrastructure to match declared configuration.
   • CUpdating in place to a default configuration is impossible once the resource block is deleted, since there is no remaining configuration describing any desired attributes to update toward.
   • DRe-importing the bucket does not happen automatically during a normal apply; import is always an explicit, separate user action, never a fallback when a block is removed.
5. Question 5Maintain Infrastructure with Terraform

   Inside terraform console you type the expression length(["a", "b", "c"]). What is returned?

   • A3Correct
   • B["a", "b", "c"]
   • CAn error because functions cannot be used in console
   • D"abc"
   ✓ Correct answer: A

   Inside terraform console, the built-in length function returns the number of elements in a collection, so length(["a", "b", "c"]) evaluates to the integer 3, since the list holds exactly three string elements; the console evaluates expressions and function calls interactively and simply prints their computed result, making it an excellent place to verify function behavior before embedding an expression in real configuration. Option B would only be the result if the console echoed the original list back unchanged rather than reducing it to a count, option C is false since evaluating built-in functions is one of console's core uses, and option D would require a join or concatenation function instead of length.

   Why the other options are wrong

   • BThis would only occur if the console simply echoed the original list back; length reduces a collection to a count, not the original elements.
   • CThis is false; evaluating built-in functions like length interactively is one of the primary purposes of terraform console.
   • DThis result would require a string join or concatenation function; length counts elements in a collection rather than combining their string content.
6. Question 6Terraform Modules

   You pin a module with version = ">= 2.1.0, < 3.0.0". What is the practical effect of this constraint?

   • AOnly exactly version 2.1.0 is permitted
   • BAny 2.x version at or above 2.1.0 is permitted, but no 3.x versionCorrect
   • CAny version greater than 2.1.0 including 3.x is permitted
   • DThe newest version is always selected regardless of the bounds
   ✓ Correct answer: B

   The combined constraint >= 2.1.0, < 3.0.0 requires both conditions to hold simultaneously, so Terraform accepts any release from 2.1.0 up through the last available 2.x patch while excluding every 3.x release outright, and it always resolves to the newest version that still satisfies both clauses. Exactly version 2.1.0 alone would instead require the equality operator =, not a combined range; any version greater than 2.1.0 including 3.x directly contradicts the explicit upper bound the constraint sets to exclude the next major line; and Terraform does not simply grab the newest version regardless of bounds - it always respects every specified constraint clause before selecting a candidate.

   Why the other options are wrong

   • AOnly exactly version 2.1.0 would require the equality operator = 2.1.0, not a range combining >= and < operators.
   • CAny version greater than 2.1.0 including 3.x contradicts the explicit < 3.0.0 upper bound, which is designed to exclude the next major version line.
   • DThe newest version is always selected regardless of the bounds is false; Terraform respects every specified constraint and picks the newest version that still falls within the allowed range.
7. Question 7Core Terraform Workflow

   Running 'terraform plan -destroy' generates a speculative plan showing what would be destroyed without actually deleting any infrastructure.

   • ATrueCorrect
   • BFalse
   ✓ Correct answer: A

   The statement is true. terraform plan -destroy produces a plan whose only proposed action is deleting every resource currently in state, and it displays the complete list of resources marked for destruction so a team can review exactly what would be torn down; because it is a plan rather than an apply, nothing is actually removed, making it a safe way to preview a destructive operation before committing to it. This step lets teams catch unexpected dependencies or protected resources before real deletion occurs, and the resulting plan can also be saved with -out for a later, exact apply.

   Why the other options are wrong

   • BFalse is incorrect. terraform plan -destroy produces a plan whose only proposed action is deleting resources in state; nothing is actually removed since it is a plan, not an apply.
8. Question 8Terraform State Management

   When you use terraform_remote_state to read another configuration's outputs, which values are accessible to the consumer?

   • AOnly the root module output values defined in the source configurationCorrect
   • BEvery resource attribute stored in the source state
   • COnly resources tagged with expose = true
   • DOnly outputs that are marked sensitive
   ✓ Correct answer: A

   Even though a source state file physically stores every resource attribute, terraform_remote_state surfaces only the values the source module explicitly published as root-level outputs, reached through data.terraform_remote_state.<name>.outputs.<name>. Attributes that were never promoted to an output remain unreachable to the consumer, so the source configuration must deliberately declare an output block for anything it intends to share. This boundary lets teams control their integration surface by choosing what to output, rather than accidentally exposing every internal resource attribute stored in state, and it applies uniformly whether or not an output is marked sensitive.

   Why the other options are wrong

   • BEvery resource attribute stored in the source state is not accessible through terraform_remote_state; although the state file physically contains all attributes, only values explicitly declared as root module outputs are surfaced to a consumer.
   • COnly resources tagged with expose = true is wrong because no expose attribute or tag exists in Terraform to govern remote state visibility; declaring output blocks is the sole mechanism for sharing values.
   • DOnly outputs that are marked sensitive is incorrect because both sensitive and non-sensitive outputs are accessible; sensitivity affects how a value is displayed in the consumer, not whether it can be read.
9. Question 9Terraform Configuration

   You want to protect a production database resource so that terraform destroy or any plan that would delete it fails. Which lifecycle argument accomplishes this?

   • Acreate_before_destroy = true
   • Bprevent_destroy = trueCorrect
   • Cignore_changes = [name]
   • Dforce_destroy = false
   ✓ Correct answer: B

   Setting prevent_destroy = true inside a resource's lifecycle block causes Terraform to reject, with an error, any plan or apply that would destroy that resource, whether triggered by terraform destroy or by a configuration change that would otherwise force replacement, and it stops the operation before any changes are actually applied. This makes it the right guard for a production database the scenario wants protected from accidental deletion; to eventually remove the resource intentionally, the setting itself must first be deleted or set to false in configuration. Option A's create_before_destroy only changes replacement ordering and still permits destruction, offering no protection at all. Option C's ignore_changes = [name] only suppresses drift detection on the name attribute and does nothing to block deletion. Option D's force_destroy is a provider-specific argument, seen on resources like S3 buckets, not a lifecycle meta-argument that blocks destruction broadly.

   Why the other options are wrong

   • Acreate_before_destroy only reorders replacement operations, provisioning the new resource before removing the old one; it still permits destruction and offers no protection against it.
   • Cignore_changes = [name] only suppresses drift detection on the name attribute; it has no effect on whether the resource itself can be destroyed.
   • Dforce_destroy is a provider-specific argument, seen on resources like S3 buckets, controlling whether non-empty resources can be force-removed; it is not a lifecycle meta-argument blocking all destruction.
10. Question 10HCP Terraform

    A configuration uses the cloud block shown below. What does this block tell Terraform to do with state? terraform { cloud { organization = "acme" workspaces { name = "prod-api" } } }

    • AManage state remotely in the 'prod-api' workspace of the 'acme' organizationCorrect
    • BWrite state to a local file named acme/prod-api.tfstate in the working directory
    • CDisable state tracking entirely and reconstruct resources from their tags
    • DPush state to an Amazon S3 bucket named acme-prod-api using the s3 backend
    ✓ Correct answer: A

    The cloud block integrates a Terraform configuration with HCP Terraform, directing state storage, locking, and run management to the specified organization and workspace. With organization = "acme" and workspaces { name = "prod-api" }, running terraform init binds the configuration to that specific workspace where state is stored remotely, versioned, and encrypted. The cloud block is the modern replacement for a backend "remote" block when targeting HCP Terraform. If a local backend was previously in use, running terraform init after adding this block also detects the existing local state and prompts to migrate it into the new HCP Terraform workspace, and the block's hostname argument is optional, defaulting to app.terraform.io when omitted.

    Why the other options are wrong

    • BA cloud block stores state remotely in HCP Terraform, not in a local file on disk.
    • CThe cloud block configures remote state storage; it never disables state tracking.
    • DState goes to the named HCP Terraform workspace, not to an S3 bucket, which would require an s3 backend.

Who this HashiCorp Terraform Associate (004) practice exam is for

This practice set is for anyone preparing for the HashiCorp Terraform Associate (004) exam at the intermediate level - from first-time candidates building a foundation to experienced HashiCorp practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this HashiCorp Terraform Associate (004) practice exam

1. Start with the free sample questions above to gauge your current baseline.
2. Read the full explanation on every question, including why each wrong option is wrong.
3. Track your weak domains and focus your study where you are losing the most marks.
4. Once you are scoring consistently well, take a timed, full-length mock exam.
5. Use your readiness score to decide when you are ready to book the real HashiCorp Terraform Associate (004) exam.

Related HashiCorp resources

• HashiCorp Terraform Associate (004) study guideKey concepts
• HashiCorp practice examsAll HashiCorp
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• HashiCorp Terraform Authoring and Operations Advanced practice examRelated
• HashiCorp Vault Associate (003) practice examRelated
• HashiCorp Vault Operations Advanced practice examRelated

HashiCorp Terraform Associate (004) practice exam FAQ