Free Practice Questions for HashiCorp Terraform-Associate-004 Exam

This is the command that does not cause Terraform to refresh its state, as it only lists the resources that are currently managed by Terraform in the state file. The other commands will refresh the state file before performing their operations, unless you use the -refresh=false flag.

From the Terraform Provider Requirements:

" > = 3.0 " means any versiongreater than or equal to 3.0— including 4.x and beyond.

A (wrong): Would need > = 3.0, < 4.0

C/D (wrong): > excludes 3.0 — not what’s written.

Detailed Explanation:

Rationale for Correct Answer:

C (tfe_outputs data source): This automates step #2 by allowing the example-compute workspace to read output values directly from the example-network workspace, eliminating manual copying of outputs into input variables. This aligns with Terraform objectives around using HCP Terraform capabilities to share data between workspaces safely and consistently.

E (Run trigger on example-compute): This automates step #3 by making example-compute automatically run (plan, and then apply depending on settings) after HCP Terraform successfully applies changes in example-network. Run triggers are specifically designed to orchestrate workspace dependencies so downstream infrastructure reacts to upstream changes.

Analysis of Incorrect Options (Distractors):

A: Incorrect. Health checks are not used to orchestrate cross-workspace plans/applies. They are for monitoring run status/health signals, not dependency automation.

B: Incorrect for the same reason as A—health checks don’t trigger downstream runs based on upstream applies.

D: Incorrect. The run trigger should be configured on the downstream workspace (example-compute) so it is triggered by upstream changes. Configuring it “on the network workspace” is the wrong direction for this dependency flow in typical HCP Terraform orchestration.

Key Concept:Automating dependencies between HCP Terraform workspaces using:

Cross-workspace output consumption (tfe_outputs) and

Run triggers to automatically start downstream runs after upstream applies.

Terraform state files are not automatically encrypted by default. Sensitive values are stored in plaintext within the state file. However, you can protect the state file by using remote backends that support encryption, such as AWS S3 with server-side encryption enabled or Terraform Cloud, which offers encrypted state storage.

The terraform validate command is used to check for syntax errors and internal consistency within Terraform configurations, such as whether all required arguments are specified. It does not check for indentation styles, missing variable values (as variables might not be defined at validation time), or state file consistency with the current infrastructure. Therefore, none of the provided options are correct in the context of what terraform validate reports.References = Terraform ' s official documentation details the purpose and function of the terraform validate command, specifying that it focuses on syntaxand consistency checks within Terraform configurations themselves, not on external factors like the state file or infrastructure state. Direct references from the HashiCorp Terraform Associate (003) study materials to this specific detail were not found in the provided files.

The " version " attribute is optional when referencing a module from the Terraform Registry. If not specified, the latest version will be used, but it is often recommended to specify a version to ensure consistency across environments.

This is the kind of configuration block that will create an infrastructure object with settings specified within the block. The other options are not used for creating infrastructure objects, but for configuring providers, accessing state data, or querying data sources.

Sentinel is a policy-as-code framework that integrates with Terraform Cloud to enforce security, compliance, and governance rules. You can enforce rules such as approved AMIs and ensure security best practices. Policies are written in the Sentinel language, not HCL.

Rationale for Correct Answer: depends_on explicitly adds a dependency edge in Terraform’s graph. By adding depends_on = [azurerm_role_assignment.kv_access] to the web app resource, you force Terraform to create the role assignment first, even if Terraform can’t infer the dependency from attribute references.

Analysis of Incorrect Options (Distractors):

B: create_before_destroy is a lifecycle setting relevant to replacement behavior, not initial create ordering between independent resources.

C: File/block order does not control creation order; Terraform uses its dependency graph.

D: count controls quantity, not ordering.

Key Concept: Dependency graph and explicit dependencies via depends_on.

The correct answer is D because marking a Terraform variable as sensitive does not, by itself, keep the value out of Terraform configuration files. The sensitive argument only changes how Terraform displays the value in CLI output, plans, and logs. It does not supply the value from outside the configuration, and it does not prevent sensitive values from being stored in state when those values are used by resources or outputs. Passing values through environment variables, command-line -var arguments, or secure external credential files can help avoid hardcoding secrets directly in .tf files. In Terraform workflows, sensitive values should be kept out of version-controlled configuration and handled through secure runtime mechanisms such as environment variables, HCP Terraform sensitive variables, or Vault.