TERRAFORM-004 Practice Questions: HCP Terraform Domain

In HCP Terraform, the recommended way to provide sensitive credentials is via workspace environment variables (e.g., `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`) or sensitive Terraform variables, marked as sensitive in the UI. This keeps secrets out of version control. B) commits secrets to VCS, which is insecure. C) hard-codes credentials in configuration, which is also insecure and not masked by `terraform fmt`. D) putting secrets as variable defaults in configuration still exposes them in VCS and is not a best practice.

The correct way to provide a required variable for an HCP Terraform workspace, without changing the configuration, is to set it as a workspace variable (and mark it sensitive for secrets) in the HCP Terraform UI or via API (A). B: Committing secrets in `terraform.tfvars` is insecure and modifies the repo. C: Local applies with different backends do not automatically update HCP Terraform state and can cause drift. D: Adding a default in the configuration requires modifying the repo, which the scenario explicitly wants to avoid.

Two HCP Terraform workspaces managing the same resources will cause conflicts and drift. The correct approach is to consolidate management into a single workspace by migrating state (using HCP Terraform’s state migration tools) from the old CLI-driven workspace to the new VCS-driven one, then decommissioning the original workspace (B). Option A is risky; human error can easily lead to concurrent or conflicting changes. Option C is incorrect and dangerous; disabling locking increases the risk of corruption and is not how coordination works. Option D changes resource identities and would cause Terraform to destroy and recreate resources rather than safely consolidating state.

With a VCS-connected HCP Terraform workspace, runs are typically remote operations: HCP Terraform executes `plan` and `apply` in its own environment, using a shared remote state. This centralizes execution, improves collaboration, and ensures consistent runs. A) is incorrect because state is not stored locally; it is stored remotely in HCP Terraform. C) is incorrect because HCP Terraform supports state locking to prevent concurrent conflicting changes. D) is incorrect because HCP Terraform runs are triggered directly by VCS events; GitHub Actions may be used additionally but is not required or enforced by HCP Terraform.

To migrate from a local backend to HCP Terraform, you configure the `remote` backend (or `cloud` block) to point to your HCP Terraform workspace, then run `terraform init`. Terraform will detect the existing local state and prompt you to migrate it to the remote backend (C). Deleting the local state (A) loses the mapping between configuration and real resources, causing Terraform to try to recreate everything. Manually uploading JSON from `terraform state pull` (B) is not the documented migration workflow. `terraform apply -replace=*` (D) would force recreation of all resources, which is risky and unnecessary for a backend migration.

HCP Terraform variable sets are designed to define variables once and reuse them across multiple workspaces. Option B is correct: create a variable set with shared variables (including sensitive ones like credentials) and attach it to the relevant workspaces. A is possible but duplicates configuration and increases risk of drift. C is discouraged because committing credentials or shared environment data into version control is insecure and inflexible. D hard-codes values in configuration, making them harder to manage and change across environments and not leveraging HCP Terraform’s variable management.

Using `lifecycle { prevent_destroy = true }` on critical resources prevents them from being destroyed by any Terraform run (including `terraform destroy`) while still allowing normal updates. This is a configuration-level safeguard appropriate for production. B: Disabling the workspace blocks all runs, not just destroy, and is not a practical workflow. C: Moving to a local backend removes the benefits of HCP Terraform and does not inherently prevent destroy; it just moves it elsewhere. D: Speculative plans only show changes and never apply them, which would block all updates, not just destroy.

Speculative plans in HCP Terraform allow you to test changes (often from a feature branch) without affecting state or applying infrastructure changes (C). They run in the same remote environment and keep state consistent. A and D: Local applies with a different backend create separate state and can cause drift; they are not appropriate when you want to keep state centralized in HCP Terraform. B: Toggling remote execution and running locally undermines the benefits of remote operations and can introduce inconsistencies.

To move an existing local project to HCP Terraform using remote operations, you configure the HCP Terraform backend in your configuration and re-run `terraform init`, which will migrate state to the remote backend. Option A correctly describes: (1) creating a workspace, (2) using CLI-driven workflow, and (3) adding the backend block and reinitializing. B is incorrect because continuing to run `terraform apply` locally with a local backend does not use HCP Terraform remote operations. C is incorrect because VCS-driven runs are not required; also deleting `.terraform` is not the key step. D is incorrect because you do not need to re-write resources or re-import everything; state migration is handled by `terraform init` with the new backend.

In a VCS-driven workspace, HCP Terraform performs remote operations automatically when changes are pushed. You can still require human review by configuring the workspace to use a manual apply workflow, where plans are generated automatically but must be explicitly confirmed in the UI or via API before apply. A: Disabling VCS integration removes the main benefit of remote, VCS-triggered runs. B: Correct; this is the standard pattern for reviewing plans in HCP Terraform. C: HCP Terraform does not accept uploaded local plan files for apply; it generates its own plans. D: Running local applies with `-auto-approve` would bypass HCP Terraform’s remote runs and is not aligned with using VCS-driven workspaces.