HashiCorp Terraform Associate (004) Practice Exam

What the HashiCorp Terraform Associate (004) exam covers

• Understand infrastructure as code (IaC) concepts105 questions
• Understand the purpose of Terraform (vs other IaC)105 questions
• Understand Terraform basics105 questions
• Use Terraform outside the core workflow105 questions
• Interact with Terraform modules105 questions
• Use the core Terraform workflow105 questions
• Implement and maintain state105 questions
• Read, generate, and modify configuration105 questions
• Understand HCP Terraform capabilities105 questions

Free HashiCorp Terraform Associate (004) sample questions

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

1. Question 1Understand infrastructure as code (IaC) concepts

   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 2Understand infrastructure as code (IaC) concepts

   A new engineer asks why the team keeps insisting that all infrastructure go through Terraform rather than letting people "just fix it in the portal." Which response BEST captures the IaC principle at stake?

   • APortal fixes are fine as long as someone writes them down in a wiki afterward
   • BIf the portal is the source of truth, the code becomes inaccurate; keeping the code as the single source of truth prevents drift and keeps environments reproducibleCorrect
   • CTerraform cannot detect any portal changes, so they are harmless
   • DPortal changes are faster, so they should always be preferred for production
   ✓ Correct answer: B

   IaC's correctness depends on the configuration being authoritative: every intended change is expressed in the .tf files and applied through terraform apply. When portal changes bypass this flow, the real infrastructure diverges from both the code and the state file, creating drift that Terraform will try to undo on the next plan, and that makes reliably rebuilding an identical environment impossible. Treating the configuration as the single source of truth is the discipline that delivers reproducibility, a trustworthy audit trail, and predictable plan output.

   Why the other options are wrong

   • APortal fixes documented in a wiki afterward still leave the authoritative configuration out of sync; wikis are not parsed or applied by Terraform and do not enforce correctness.
   • CClaiming Terraform cannot detect portal changes is false; terraform plan refreshes real resource attributes from the provider API and surfaces drift in its output.
   • DClaiming portal changes are faster and should always be preferred for production ignores the consistency, review, and reproducibility requirements that production environments most critically need.
3. Question 3Understand the purpose of Terraform (vs other IaC)

   On the Terraform Registry, what distinguishes a Partner-tier provider from a Community-tier provider?

   • APartner providers are maintained by a technology company and verified through HashiCorp's partner program, while Community providers are maintained by individual contributorsCorrect
   • BPartner providers are written in HCL, while Community providers are written in Go
   • CPartner providers cannot be used in production, while Community providers can
   • DPartner providers skip the terraform init download step
   ✓ Correct answer: A

   Terraform Registry tiers communicate who owns a provider's maintenance and support. A Partner-tier provider is published and maintained by a third-party technology company that participates in HashiCorp's Technology Partner Program, earning a verified badge that signals a formal partnership. A Community-tier provider is published by individual maintainers or organizations without that verification, so consumers should evaluate its support level themselves. The tier therefore describes maintenance ownership and verification status, not technical capability.

   Why the other options are wrong

   • BProvider implementation language is not what separates the tiers; all Terraform providers, whether Partner or Community, are written in Go and distributed as compiled binaries, while HCL is the configuration language users write, not the language providers are built in.
   • CProduction suitability is not determined by tier; any provider tier can be used in production, and the tier reflects who maintains and verifies the provider rather than imposing an environment restriction.
   • DThe terraform init download step is never skipped based on tier; init must install every provider regardless of whether it is Official, Partner, or Community, so no tier bypasses provider installation.
4. Question 4Understand Terraform basics

   What is the purpose of the `required_providers` block nested within the `terraform {}` block?

   • ATo set credentials such as region and access keys for each provider
   • BTo declare the source address and version constraints for each provider the module usesCorrect
   • CTo define where the Terraform state file is stored
   • DTo create the actual cloud resources
   ✓ Correct answer: B

   The `required_providers` block maps each provider's local name to its source registry address (for example `hashicorp/aws`) and an optional version constraint, telling Terraform which provider plugins to download during `terraform init`. This ensures consistent provider versions across runs and enables the dependency lock file to pin exact versions. It does not configure provider settings or credentials.

   Why the other options are wrong

   • ASetting credentials such as region and access keys is done in a separate `provider` block, not in `required_providers`, which only declares the source and version.
   • CDefining where state is stored is the job of the `backend` block nested in `terraform {}`, not `required_providers`.
   • DCreating cloud resources is done with `resource` blocks; `required_providers` only declares which provider plugins are needed, not the infrastructure itself.
5. Question 5Use Terraform outside the core workflowSelect all that apply

   Which two outcomes occur when you successfully run terraform apply -replace="aws_instance.web" against a healthy instance? (Choose TWO)

   • AThe existing instance is destroyed and a new instance is created in its placeCorrect
   • BThe plan output shows the resource action as replacement (destroy then create)Correct
   • CThe resource is removed from state but the real instance is left running
   • DThe provider configuration block for AWS is regenerated automatically
   ✓ Correct answer: A, B

   When terraform apply -replace is used, Terraform plans and executes a full replacement of the named instance: the existing object is destroyed and a new one is provisioned with the same configuration arguments. Before any action is taken, the plan output explicitly marks the resource with a replacement action - destroy then create, or create then destroy when create_before_destroy is set - so the operator can confirm the intended behavior.

   Why the other options are wrong

   • CThe resource is removed from state but the real instance is left running describes terraform state rm, not a replacement. The -replace option actually destroys and recreates the real infrastructure object.
   • DThe provider configuration block for AWS is author-managed HCL and is never automatically regenerated or modified by a replace operation.
6. Question 6Interact with Terraform modules

   A child module declares variable "subnet_ids" { type = list(string) }. You want to pass the ids output (a list) from another module. Which argument is correct?

   • Asubnet_ids = module.network.idsCorrect
   • Bsubnet_ids = [module.network.ids]
   • Csubnet_ids = module.network.ids.*
   • Dsubnet_ids = list(module.network.ids)
   ✓ Correct answer: A

   When a module output is already a list of strings and the receiving variable is typed list(string), you assign the output directly without any wrapping or conversion. Terraform passes the list value as-is, and the types match. This is the idiomatic and correct approach for forwarding a list output from one module to the input of another.

   Why the other options are wrong

   • BWrapping the output as [module.network.ids] creates a list whose single element is itself a list, yielding list(list(string)). This does not satisfy the list(string) type constraint and causes a type mismatch error.
   • CThere is no list() conversion function used in this way in HCL. The value is already a list of strings, so no conversion is needed; direct assignment is the correct approach.
   • DThe expression module.network.ids.* uses an incomplete legacy splat form. Even the corrected module.network.ids[*] would return the same list and is unnecessary here; the bare .* syntax is not valid in this context.
7. Question 7Use the core Terraform workflow

   You only want terraform init to install and lock providers without contacting or configuring any backend, for example to populate the lock file in CI. Which flag accomplishes this?

   • Aterraform init -backend=falseCorrect
   • Bterraform init -reconfigure
   • Cterraform init -input=false
   • Dterraform init -lock=false
   ✓ Correct answer: A

   Passing -backend=false to terraform init instructs it to skip backend initialization entirely while still downloading and locking provider plugins and installing modules. This is useful in CI pipelines where you want to populate or validate .terraform.lock.hcl without having backend credentials available, or where remote state configuration is not needed for the current step. Provider installation proceeds normally so subsequent configuration validation can be performed.

   Why the other options are wrong

   • Bterraform init -reconfigure actively reconfigures the backend with the current settings rather than skipping backend initialization, and still contacts and configures the backend.
   • Cterraform init -input=false disables interactive prompts during initialization, causing it to fail rather than prompt when required values are missing, but it still initializes the backend.
   • Dterraform init -lock=false disables state locking during operations and has no relationship to skipping backend initialization.
8. Question 8Implement and maintain stateSelect all that apply

   Which two of the following are valid ways to associate runs with an HCP Terraform workspace using the cloud block? (Choose TWO)

   • ASpecify a tags attribute under workspaces to match workspaces by tagCorrect
   • BSpecify a name attribute under workspaces to bind to a single workspaceCorrect
   • CSpecify a path attribute pointing to a local state file
   • DSpecify a dynamodb_table attribute for workspace selection
   ✓ Correct answer: A, B

   Inside a cloud block, the nested workspaces argument accepts either name or tags, but not both. The name option binds the configuration to exactly one named HCP Terraform workspace, making it ideal for single-environment use. The tags option matches all workspaces in the organization that carry the specified tags, enabling a single configuration to work with multiple workspaces that are then selected via terraform workspace commands. Both are first-class, officially supported mechanisms for associating CLI runs with HCP Terraform workspaces.

   Why the other options are wrong

   • CSpecify a path attribute pointing to a local state file is a configuration option for the local backend only; the cloud block has no path attribute and does not reference state files on disk.
   • DSpecify a dynamodb_table attribute for workspace selection belongs to the S3 backend and is used for enabling DynamoDB-based locking; it is not a valid attribute in the cloud block and has no role in workspace association.
9. Question 9Read, generate, and modify configuration

   You run terraform output -json. What does the command produce?

   • AA JSON object of all root module output values, including those marked sensitiveCorrect
   • BA JSON copy of the entire state file
   • CA JSON list of all declared input variables
   • DNothing, because outputs cannot be serialized to JSON
   ✓ Correct answer: A

   The terraform output -json command emits a machine-readable JSON object containing every root module output, with each entry including the value, its type, and a boolean sensitive flag. Because -json is intended for programmatic consumption by scripts and pipelines, it includes the actual values of sensitive outputs rather than redacting them, so the resulting JSON must be handled with care to avoid leaking secrets.

   Why the other options are wrong

   • Bterraform output -json does not dump the full state file; it returns only the declared output values, not the complete resource state.
   • Cterraform output -json reports output values, not input variables; outputs and variables are distinct constructs and this command only surfaces outputs.
   • DOutputs are fully serializable to JSON; the -json flag exists precisely to provide output values in a structured, machine-readable format.
10. Question 10Understand HCP Terraform capabilities

    An organization needs Terraform runs to access on-premises infrastructure that is not reachable from HCP Terraform's public workers. Which execution mode supports this requirement?

    • ALocal execution mode
    • BRemote execution mode
    • CAgent execution modeCorrect
    • DSpeculative execution mode
    ✓ Correct answer: C

    Agent execution mode dispatches HCP Terraform runs to a self-hosted HCP Terraform agent installed inside your private network. The agent polls HCP Terraform for queued runs and executes plan and apply operations from within your network, giving runs direct access to private, on-premises, or otherwise isolated infrastructure that HCP Terraform's public shared workers cannot reach. The run workflow, UI, and state storage all remain within HCP Terraform - only the compute location changes.

    Why the other options are wrong

    • ALocal execution mode runs Terraform on the user's own machine on demand and does not provide a persistent, network-resident execution environment for the workspace.
    • BRemote execution mode uses HCP Terraform's shared public worker infrastructure, which by definition cannot access private endpoints inside a customer's network.
    • DThere is no 'speculative execution mode' in HCP Terraform; speculative refers to plan-only run types, not a category of where runs execute.

HashiCorp Terraform Associate (004) practice exam FAQ