CertKeen
HashiCorpBeta · expanding bank

Terraform Associate (004) Practice Exam

Practice questions for the HashiCorp Certified: Terraform Associate (004) exam, which tests Terraform 1.12 and HCP Terraform: infrastructure as code concepts and multi-cloud workflows; providers, version constraints, the dependency lock file, provider aliases and the plugin architecture; the core workflow with init, validate, plan, apply, destroy and fmt; resources and data sources, cross-resource references, variables and outputs, complex types, expressions and functions, dependencies and lifecycle rules, custom conditions and check blocks, sensitive data, Vault, ephemeral resources and write-only arguments; module sources, inputs and outputs, scope and versioning; local and remote backends, state locking, remote state and drift; import, moved and removed blocks, state inspection commands and TF_LOG logging; and HCP Terraform workspaces and projects, VCS- and CLI-driven runs, variable sets, Sentinel policies and run tasks. Every question includes a written explanation.

100 questions · 12 free preview

$19 · lifetime access
Try free sample

Studying more than one? every exam for $79

Free sample questions

  1. Sample · question 1 · Skipping refresh during plan

    Plans at Ashby Cartography take a long time because Terraform reads hundreds of objects from the provider API before planning. An engineer wants a quick plan that relies only on the current state, accepting that drift will not be detected. Which option does this?

    • A.terraform plan -refresh=falsecorrect
    • B.terraform plan -refresh-only
    • C.terraform plan -lock=false
    • D.terraform plan -compact-warnings

    Why: By default, plan first refreshes state by reading remote objects; -refresh=false skips that step, which is faster but can miss changes made outside Terraform. A refresh-only plan does the opposite, focusing only on syncing state with remote objects. Disabling locking or compacting warnings does not skip the refresh.

    Open this question on its own page →
  2. Sample · question 2 · Local state backup file

    After an apply with the local backend, an engineer at Pellow Farms notices a file named terraform.tfstate.backup next to terraform.tfstate. What does it contain?

    • A.An encrypted copy of the current state for disaster recovery
    • B.A list of provider versions selected during init
    • C.The previous version of the state, written before Terraform saved the latest statecorrect
    • D.The saved plan from the most recent apply

    Why: With the local backend, Terraform keeps a backup of the prior state in terraform.tfstate.backup each time it writes new state. It is not encrypted. Provider selections are recorded in .terraform.lock.hcl, and saved plans exist only when created with plan -out.

    Open this question on its own page →
  3. Sample · question 3 · Default CLI workspace cannot be deleted

    An engineer at Tresco Mobile runs terraform workspace delete default to clean up a working directory. What happens?

    • A.Terraform deletes the default workspace and its state
    • B.Terraform renames the default workspace to the next workspace in alphabetical order
    • C.Terraform deletes every workspace except default
    • D.Terraform refuses, because the default workspace always exists and cannot be deletedcorrect

    Why: Every initialized working directory has a workspace named default, which cannot be deleted. Other workspaces can be deleted with terraform workspace delete, normally after switching away from them. Terraform never renames workspaces or deletes other workspaces as a side effect.

    Open this question on its own page →
  4. Sample · question 4 · Local execution mode in HCP Terraform

    Wyvern Tools wants to run Terraform on its own build servers but keep state in an HCP Terraform workspace. Which workspace execution mode fits?

    • A.Remote, where every plan and apply runs on HCP Terraform's workers
    • B.Speculative, where runs cannot apply changes
    • C.Agent mode without any agent pool configured
    • D.Local, where operations run on the machine that starts them and HCP Terraform stores statecorrect

    Why: With local execution mode, plans and applies run on the user's or CI machine, and HCP Terraform is used to store and synchronize state. Remote execution runs operations on HCP Terraform's infrastructure. Speculative is a type of plan, not an execution mode, and agent mode requires an agent pool.

    Open this question on its own page →
  5. Sample · question 5 · Self-hosted agents for private networks

    Infrastructure at Moravia Grain sits in a private data center that HCP Terraform's hosted workers cannot reach. The team still wants runs managed by HCP Terraform. What should they use?

    • A.HCP Terraform agents installed inside the private network, with the workspace set to agent execution modecorrect
    • B.Local execution mode with the state stored in the data center
    • C.A public IP address on every private server
    • D.The terraform_remote_state data source pointing at the data center

    Why: HCP Terraform agents run inside the private network and make outbound connections to HCP Terraform to pick up work, so runs can reach private infrastructure without opening inbound access. Local execution moves runs off HCP Terraform entirely. Exposing servers publicly is a security risk, and remote state data sources only read outputs.

    Open this question on its own page →
  6. Sample · question 6 · Run triggers between workspaces

    At Calloway Retail, an application workspace reads networking outputs from a network workspace in HCP Terraform. The team wants the application workspace to queue a run automatically after each successful apply in the network workspace. Which feature does this?

    • A.A Sentinel policy that references both workspaces
    • B.A variable set shared by both workspaces
    • C.A run trigger on the application workspace with the network workspace as its sourcecorrect
    • D.A run task attached to the network workspace's post-plan stage

    Why: Run triggers connect workspaces so that a successful apply in a source workspace queues a run in the dependent workspace. Sentinel policies evaluate runs rather than starting them. Variable sets share variable values, and run tasks call external services during a run instead of starting runs elsewhere.

    Open this question on its own page →
  7. Sample · question 7 · Health assessments for drift detection

    Nightjar Logistics wants HCP Terraform to check its workspaces on a schedule and alert the team when real infrastructure no longer matches state, without anyone starting a plan. Which feature provides this?

    • A.Speculative plans on pull requests
    • B.Health assessments with drift detectioncorrect
    • C.The dependency lock file
    • D.Cost estimation

    Why: Once enabled for a workspace or organization, HCP Terraform health assessments run automatically in the background and include drift detection, which reports when real infrastructure has changed outside Terraform, as well as continuous validation of checks and conditions. Speculative plans on pull requests run only when a pull request is opened or updated. The lock file pins provider versions, and cost estimation shows the cost impact of a planned run.

    Open this question on its own page →
  8. Sample · question 8 · Dynamic provider credentials with OIDC

    Security policy at Kittering Bank forbids storing long-lived cloud access keys in HCP Terraform workspace variables. Which HCP Terraform capability lets runs authenticate to the cloud provider without static keys?

    • A.Sensitive environment variables that store the access keys
    • B.The cloud block's token argument
    • C.Dynamic provider credentials, which use workload identity tokens to obtain short-lived credentials for each runcorrect
    • D.Marking the provider block as sensitive

    Why: Dynamic provider credentials use OpenID Connect workload identity tokens issued by HCP Terraform, which the cloud provider exchanges for temporary credentials scoped to each run. Sensitive variables still store long-lived keys, only hidden. The cloud block's token authenticates the CLI to HCP Terraform, not to a cloud provider, and provider blocks have no sensitive setting.

    Open this question on its own page →
  9. Sample · question 9 · terraform_data triggers_replace argument

    Marrow Games wants a terraform_data resource, used to run a setup step, to be replaced whenever var.schema_version changes. Which argument achieves this?

    • A.triggers_replace = var.schema_versioncorrect
    • B.input = var.schema_version
    • C.depends_on = [var.schema_version]
    • D.lifecycle { ignore_changes = [var.schema_version] }

    Why: terraform_data's triggers_replace argument holds a value that, when changed, causes the resource to be replaced. The input argument is stored and returned as output, but changing it does not force replacement. depends_on expects resource or module references, and ignore_changes takes the resource's own attributes, not variables.

    Open this question on its own page →
  10. Sample · question 10 · Provisioners as a last resort

    An engineer at Gorsedd Media plans to use a remote-exec provisioner on every virtual machine to install packages after creation. What is HashiCorp's guidance?

    • A.Provisioners are the recommended way to configure every resource
    • B.Provisioners are a last resort; prefer options such as provider-supported user data, cloud-init or prebuilt machine imagescorrect
    • C.Provisioners run before the resource is created
    • D.Provisioners are tracked in state so Terraform reruns them when the script changes

    Why: HashiCorp describes provisioners as a last resort, because Terraform cannot model their actions in a plan; built-in mechanisms such as user data, cloud-init or images built with tools like Packer are preferred. Creation-time provisioners run after the resource is created. Terraform does not rerun them when a script changes unless the resource is replaced.

    Open this question on its own page →
  11. Sample · question 11 · Running tests with terraform test

    Oakhaven Software wants to write automated tests for a module that run a plan with sample input values and assert on the results. Which feature does Terraform provide for this?

    • A.terraform validate -test, which reads assertions from variables.tf
    • B.terraform test, which runs files ending in .tftest.hcl containing run blocks with assert conditionscorrect
    • C.terraform console -batch, which compares outputs with expected values
    • D.terraform fmt -check, which verifies module outputs

    Why: The terraform test command discovers test files ending in .tftest.hcl and executes their run blocks, each of which can run a plan or apply and evaluate assert conditions. validate has no test mode, console is an interactive expression evaluator, and fmt -check only checks formatting.

    Open this question on its own page →
  12. Sample · question 12 · Lock file hashes for multiple platforms

    Engineers at Tolliver Labs use macOS laptops, while CI runs on Linux. CI fails checksum verification for providers recorded in the lock file from a laptop. Which command records provider checksums for both platforms?

    • A.terraform init -platform=all
    • B.terraform fmt -recursive
    • C.terraform state replace-provider
    • D.terraform providers lock -platform=darwin_arm64 -platform=linux_amd64correct

    Why: terraform providers lock can fetch provider packages for several platforms with repeated -platform options and record all their checksums in the lock file. init has no platform option of this kind. fmt formats files, and state replace-provider changes provider addresses in state.

    Open this question on its own page →

Like the sample?

Other practice exams