Free HashiCorp Terraform-Associate-004 Practice Exam with Questions & Answers | Set: 3

Detailed Explanation:

Rationale for Correct Answer: Terraform supports detailed logging through the TF_LOG environment variable. Setting TF_LOG=TRACE enables the most verbose logging level, which includes detailed information about provider installation, plugin loading paths, and execution steps. This is the correct way to debug how Terraform is resolving and loading providers.

Analysis of Incorrect Options (Distractors):

A. TF_VAR_log=TRACE Incorrect because TF_VAR_ is used to pass input variables into Terraform, not to control logging.

B. TF_LOG_PATH Incorrect because this variable only specifies where logs are written, not the logging level itself. It must be used in combination with TF_LOG.

D. Set verbose logging for each provider in your Terraform configuration. Incorrect because Terraform does not support configuring provider-level logging directly in .tf files; logging is controlled globally via environment variables.

Key Concept: Using TF_LOG environment variable to enable Terraform debug and trace logging.

Terraform state maintains the binding between resource addresses in the configuration and the corresponding real-world infrastructure objects. With the local backend, those bindings are normally stored in terraform.tfstate. If that state file is deleted and cannot be recovered, Terraform no longer knows that the existing remote objects correspond to resources declared in the configuration. Consequently, the next terraform apply treats those configured resources as objects that need to be created. Terraform does not automatically discover previously created infrastructure and reconstruct the missing state mappings. Existing objects would need to be restored from a state backup or explicitly imported into Terraform state. Therefore, D is correct. In practice, creation might subsequently fail if the provider rejects duplicate names or identifiers, but Terraform ' s planned action is creation rather than automatic discovery or deletion.

================

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 Cloud provides features like remote state storage and a web-based user interface for managing your Terraform runs. While it offers robust infrastructure as code capabilities, automatic backups of configuration and state are not directly provided by Terraform Cloud; instead, the state is stored remotely and secured.

Rationale for Correct Answer:When multiple provider configurations are defined using an alias, Terraform requires the provider meta-argument inside the resource block to explicitly reference the aliased provider.In this case, the provider is defined as aws with alias = " west " , so resources targeting us-west-2 must specify:

provider = aws.west

This tells Terraform exactly which provider configuration to use.

Analysis of Incorrect Options (Distractors):

B. alias = aws.west: Incorrect — alias is only used inside the provider block, not in resources.

C. provider = west: Incorrect — Terraform requires the full provider name (aws.west), not just the alias.

D. alias = west: Incorrect — resources do not support an alias meta-argument.

Key Concept:Using aliased provider configurations and the provider meta-argument to deploy resources across multiple regions or accounts.

In Terraform Cloud, speculative plan runs are not automatically started when changes are merged or committed to the version control repository linked to a workspace. Instead, speculative plans are typically triggered as part of proposed changes in merge requests or pull requests to give an indication of what would happen if the changes were applied, without making any real changes to the infrastructure. Actual plan and apply operations in Terraform Cloud workspaces are usually triggered by specific events or configurations defined within the Terraform Cloud workspace settings.References = This behavior is part of how Terraform Cloud integrates with version control systems and is documented in Terraform Cloud ' s usage guidelines and best practices, especially in the context of VCS-driven workflows.

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.

Theversion argumentin a module ensures Terraform uses aspecific versionof a module, preventing unintended updates.

A (source)– Specifies the module source butdoes not control versioning.

B (count)– Controls how many instances of a resource/module exist,not updates.

D (lifecycle)– Controls how resources behavebut does not control module versioning.

Official Terraform Documentation Reference:

Module Version Constraints

This is a bad practice, as it exposes your credentials to anyone who can access your configuration files or state files. You should use environment variables, credential files, or other mechanisms to provide credentials to Terraform.

Rationale for Correct Answer: Terraform uses a declarative approach: you define the desired end state of infrastructure in configuration files that can be version-controlled and repeatedly applied. Terraform then computes an execution plan to reach that state. This is a key distinction from ad-hoc API calls or hand-written scripts that typically manage infrastructure in a more imperative and less state-aware way.

Analysis of Incorrect Options (Distractors):

B: Incorrect because Terraform is not “merely a wrapper.” It provides a workflow (state, diff/plan, dependency graph, drift detection) that fundamentally changes how infrastructure is managed.

C: Incorrect because Terraform does not replace provider APIs; providers still use the underlying cloud/service APIs.

D: Incorrect because Terraform is primarily declarative, not imperative scripting to force a specific order (ordering is derived from dependencies).

Key Concept: Declarative desired-state configuration, plan/apply workflow, and version-controlled IaC.