HashiCorp Terraform Associate (004) Practice Exam

What the HashiCorp Terraform Associate (004) exam covers

• Infrastructure as Code (IaC) with Terraform217 questions
• Terraform Fundamentals109 questions
• Core Terraform Workflow111 questions
• Terraform Configuration129 questions
• Terraform Modules110 questions
• Terraform State Management107 questions
• Maintain Infrastructure with Terraform108 questions
• HCP Terraform111 questions

Free HashiCorp Terraform Associate (004) sample questions

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

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?

   • ADefining and managing infrastructure through machine-readable configuration files that are versioned and 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 means describing desired infrastructure in declarative configuration files - such as Terraform's HCL .tf files - rather than provisioning resources by hand. These files can be stored in version control, peer-reviewed, and applied through commands like terraform apply so the same configuration produces the same result every time, replacing ad-hoc console clicking with a repeatable, automated, and documented workflow.

   Why the other options are wrong

   • BManually documenting every console click in a shared spreadsheet is still a manual process and does not let a tool provision the infrastructure, so it does not meet 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

   Which of the following BEST explains why Terraform is often described as cloud-agnostic, and how that compares to learning each provider's separate web console?

   • ATerraform uses one HCL workflow and providers to manage many platforms, instead of mastering a different console UI for each cloudCorrect
   • BTerraform can target only one cloud provider per configuration and cannot manage others at all
   • CTerraform translates every target cloud into AWS resources behind the scenes automatically
   • DEvery cloud console already shares one identical UI, so cloud-agnostic tooling adds nothing
   ✓ Correct answer: A

   Terraform Core communicates with cloud platforms through provider plugins downloaded during terraform init. Each provider, such as hashicorp/aws, hashicorp/azurerm, or hashicorp/google, translates HCL resource definitions into that platform's API calls. This means teams learn one language and one plan-apply workflow that applies across every supported provider, rather than navigating a distinct, frequently changing web console for each cloud. That consistency across platforms is the defining meaning of being cloud-agnostic in the context of Terraform.

   Why the other options are wrong

   • BTerraform can manage many providers in one configuration, which is what makes it cloud-agnostic.
   • CTerraform does not convert other clouds into AWS; each provider manages its own platform natively.
   • DEach cloud console differs; a single HCL workflow across them is exactly the benefit.
3. Question 3Infrastructure as Code (IaC) with Terraform

   Two engineers run terraform apply against the same remote state at nearly the same time. Which state feature prevents them from corrupting the state by writing simultaneously?

   • AState lockingCorrect
   • BState formatting
   • CState validation
   • DState templating
   ✓ Correct answer: A

   State locking ensures that while one operation is writing to state, no other operation can acquire the lock and write concurrently, preventing two simultaneous applies from overwriting each other's changes. Backends that support locking - such as S3 with a DynamoDB table or HCP Terraform - acquire the lock at the start of a write operation and release it when finished. This is essential for safe team collaboration on shared remote state.

   Why the other options are wrong

   • BState formatting is not a real Terraform feature; formatting applies to configuration source files via terraform fmt and has no bearing on concurrent write protection.
   • CState validation is not the mechanism that prevents concurrent writes; validation concerns configuration correctness rather than coordinating simultaneous operations.
   • DState templating is not a Terraform concept and does nothing to coordinate or serialize simultaneous writes to shared state.
4. Question 4Terraform Fundamentals

   You run `terraform apply` for the first time on a configuration containing a single `aws_instance.web` resource. Terraform reports "1 to add, 0 to change, 0 to destroy." What core lifecycle operation is Terraform performing for this resource?

   • ACreateCorrect
   • BRead
   • CUpdate
   • DDelete
   ✓ Correct answer: A

   When a resource exists in configuration but has no corresponding entry in state, Terraform plans a Create operation, shown as '1 to add' in plan output. Terraform calls the provider's create function, which provisions the real infrastructure and then records the resulting attributes in state. Subsequent runs compare that stored state to the configuration to decide whether further actions are needed.

   Why the other options are wrong

   • BRead is the refresh step Terraform performs to reconcile existing state with real infrastructure; it does not provision new resources and is not what '1 to add' represents.
   • CUpdate (shown as 'to change') applies in-place modifications to a resource that already exists in state, which is not the case for a brand-new resource.
   • DDelete (shown as 'to destroy') removes a resource that is in state but no longer desired in configuration, the opposite of adding a new one.
5. Question 5Maintain Infrastructure with Terraform

   Which lifecycle argument lets you declaratively force a resource to be replaced whenever another referenced resource or attribute changes, as an in-configuration alternative to manual -replace?

   • Areplace_triggered_byCorrect
   • Bforce_replace
   • Crecreate_on_change
   • Dtaint_when
   ✓ Correct answer: A

   The replace_triggered_by lifecycle argument, available since Terraform 1.2, accepts a list of references to other resources or their attributes; when any referenced value changes, Terraform plans a replacement of the resource declaring it. This provides a declarative, version-controlled way to express recreation dependencies directly in configuration, complementing the imperative -replace CLI flag used for ad-hoc recreation.

   Why the other options are wrong

   • Bforce_replace is not a real Terraform lifecycle argument; no such attribute exists in the lifecycle block.
   • Crecreate_on_change is not a valid lifecycle argument in Terraform; this name does not appear in the Terraform language specification.
   • Dtaint_when does not exist as a Terraform configuration argument; there is no lifecycle attribute that conditionally applies a taint based on a condition.
6. Question 6Terraform Modules

   You are designing a module that provisions an application stack. Rather than configuring the AWS provider inside the module, the module only declares a required_providers block. Why is this the preferred design for a shared module?

   • Arequired_providers blocks are mandatory, while provider configuration is forbidden in any module
   • BIt lets the consuming root module own provider configuration, keeping the shared module portable and removableCorrect
   • CIt allows the module to run without any provider being configured at all
   • Drequired_providers automatically supplies credentials so the root module needs none
   ✓ Correct answer: B

   Declaring only a required_providers block expresses the module's version and source requirements for a provider without binding it to specific credentials, regions, or aliases. The actual provider configuration is left to the root module, which can configure it once and pass it down, making the shared module portable across accounts and environments. This separation is the recommended pattern for reusable modules and allows the module to be cleanly removed without leaving orphaned provider blocks.

   Why the other options are wrong

   • AThe claim that provider configuration is forbidden in any module is too strong - it is strongly discouraged in shared modules but technically allowed and seen in some legacy configurations or aliased provider patterns.
   • CThe claim that the module can run with no provider configured anywhere is false - some provider configuration must exist, typically supplied by the root module, for authentication and API access to succeed.
   • DThe claim that required_providers automatically supplies credentials is false - required_providers only constrains provider source and version and carries no authentication details whatsoever.
7. Question 7Core Terraform Workflow

   You run `terraform apply` (no saved plan). Which sequence best describes the default behavior?

   • ARefresh state, compute a plan, prompt for approval, then applyCorrect
   • BApply immediately without refreshing or prompting
   • CCompute a plan and apply it without refreshing state
   • DPrompt for approval first, then refresh and compute the plan
   ✓ Correct answer: A

   When terraform apply is run without a saved plan file, it performs an implicit plan: it first refreshes state by querying real infrastructure, computes the changes required to reconcile the configuration with actual state, presents the resulting plan, and waits for the operator to type 'yes' before making any modifications. Only after confirmation does Terraform execute the actions. This default behavior can be bypassed with -auto-approve and the refresh can be skipped with -refresh=false.

   Why the other options are wrong

   • BApply immediately without refreshing or prompting is wrong because Terraform always refreshes state and presents a confirmation prompt by default when no -auto-approve or -refresh=false flag is provided.
   • CCompute a plan and apply it without refreshing state is wrong because the refresh step runs before plan computation by default and must be explicitly disabled with -refresh=false.
   • DPrompt for approval first, then refresh and compute the plan reverses the actual sequence; Terraform must compute the plan before there is anything meaningful to present for approval.
8. Question 8Terraform State Management

   Why is enabling versioning on the S3 bucket used for Terraform state recommended even though DynamoDB provides locking?

   • AVersioning fully replaces DynamoDB locking, so the lock table becomes unnecessary
   • BVersioning lets you recover a previous state version if state is accidentally corrupted or overwrittenCorrect
   • CVersioning is a prerequisite that DynamoDB locking requires in order to function
   • DVersioning accelerates lock acquisition by caching recent state versions
   ✓ Correct answer: B

   DynamoDB locking and S3 versioning solve different problems. Locking prevents concurrent writes, while bucket versioning preserves prior copies of the state object so you can roll back if a state file becomes corrupted, is mistakenly overwritten, or contains a bad change. Enabling both gives you safe concurrency plus a recovery path, which is why the combination is commonly recommended for production state.

   Why the other options are wrong

   • AVersioning protects against corruption but does nothing to prevent concurrent writes, so DynamoDB locking is still required.
   • CDynamoDB locking operates independently of S3 versioning and does not depend on versioning being enabled.
   • DVersioning is a recovery feature for the state object and has no effect on how quickly locks are acquired.
9. Question 9Terraform Configuration

   You want to set an attribute to "premium" when var.tier equals "prod" and "standard" otherwise. Which expression uses the conditional operator correctly?

   • Avar.tier == "prod" ? "premium" : "standard"Correct
   • Bif var.tier == "prod" then "premium" else "standard"
   • Cvar.tier == "prod" ? "premium"
   • Dcoalesce(var.tier == "prod", "premium", "standard")
   ✓ Correct answer: A

   Terraform uses the ternary conditional operator with the syntax condition ? true_value : false_value. When var.tier equals "prod" the expression evaluates to "premium"; for any other value it returns "standard". Both result values must be present and should be convertible to a common type for the operator to work correctly.

   Why the other options are wrong

   • BThe if/then/else form is not valid HCL; Terraform expressions do not support an if keyword for inline conditionals inside attribute values.
   • CThe expression var.tier == "prod" ? "premium" is incomplete because the conditional operator requires both a true result and a false result separated by a colon.
   • Dcoalesce(var.tier == "prod", "premium", "standard") misuses coalesce, which selects the first non-null/non-empty value and would error on a boolean first argument rather than acting as a conditional.
10. Question 10HCP Terraform

    In HCP Terraform, a Sentinel policy is assigned the enforcement level "advisory". What happens when this policy fails during a run?

    • AThe run is immediately canceled and cannot be applied
    • BThe run is paused until an organization owner manually overrides the failure
    • CA warning is logged but the run can still proceed to applyCorrect
    • DThe plan phase is skipped entirely and the apply runs without checks
    ✓ Correct answer: C

    Sentinel defines three enforcement levels: advisory, soft-mandatory, and hard-mandatory. Advisory is the least restrictive level. When an advisory policy fails, the failure is recorded in the policy check results as a warning but the run is not stopped and the apply can proceed normally. Advisory enforcement is commonly used to surface recommendations, track compliance metrics, or test new policy logic before promoting it to a stricter enforcement level.

    Why the other options are wrong

    • AImmediately canceling the run with no possibility of override corresponds to a hard-mandatory policy failure, not advisory, which is the most permissive enforcement level.
    • BPausing the run until a user with override permissions manually approves continuing describes the soft-mandatory enforcement level, where the failure blocks the run but can be overridden.
    • DAdvisory enforcement does not skip the plan phase - all three enforcement levels run after a completed plan, and the policy check result for advisory is purely informational without altering the run workflow.

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
• HashiCorp Vault Associate (003) practice examRelated

HashiCorp Terraform Associate (004) practice exam FAQ