An HCP Terraform workspace using the VCS-driven workflow has a workspace Terraform variable region = "us-east-2". A developer commits region.auto.tfvars with region = "eu-west-1" to the tracked branch. No variable sets define region. Which value does the next run use?
Select an answer to reveal the explanation.
Short Explanation
In HCP Terraform, the workspace's own settings sit above the files in your repo. So the variable you set in the workspace beats the auto.tfvars file the developer committed. The trap is assuming that "what's in Git wins"; for variables, the workspace does.
Full Explanation
HCP Terraform documents a precedence list for conflicting variables. Priority variable sets come first, then command-line values in the CLI workflow, local TF_VAR_ environment variables in the CLI workflow, workspace-specific variables, the various non-priority variable sets, and only then *.auto.tfvars files followed by terraform.tfvars. The documentation states that variables in the HCP Terraform workspace and variables provided through the command line always overwrite variables with the same key from files ending in .auto.tfvars. The run therefore uses us-east-2. Saying the committed file wins reverses that order and would let any committer silently override workspace controls. HCP Terraform does not reject duplicates; it resolves them by precedence and marks overwritten values. Speculative plans and applies use the same variable resolution; a run never switches sources between plan types. Exam caveat: Terraform Enterprise currently ignores terraform.tfvars, so behaviour for that file differs between the two products. Operational check: open the run's plan and confirm the region value, then decide whether to delete the workspace variable or the committed file so the configuration has a single source of truth.