A project-scoped variable set defines the Terraform variable allowed_regions, and one workspace in that project also defines allowed_regions as a workspace variable with a different value. The governance team wants the variable set's value to win in every workspace in the project. What should they do?
Select an answer to reveal the explanation.
Short Explanation
By default the workspace gets the last word, like a local manager overruling the head-office memo you sent. Flip the variable set to priority and head office wins, overriding the same key set at the workspace. Making it global or sensitive changes who sees it, not who wins.
Full Explanation
In HCP Terraform, workspace-specific variables always overwrite variables from non-priority variable sets that share the same key, which is why the workspace's value currently wins. Marking a variable set as priority reverses that relationship: its values take precedence over any variable with the same key set at a more specific scope, including workspace variables and, in the CLI workflow, command-line values. Leaving the set unchanged keeps the current behaviour, because non-priority sets sit below workspace variables in the precedence order. Converting to a global set makes things worse for this case: non-priority global sets are the lowest of the variable-set levels and also apply to every workspace in the organization. The sensitive flag only hides the value after saving; it does not change precedence. Exam caveat: a priority variable set guarantees the value but not its use; a workspace's configuration could stop referencing the variable or hardcode a value, so HashiCorp recommends policy as code for strict enforcement. Operational check: open the workspace's Variables page and confirm the workspace value is marked as overwritten, then run a plan and verify the variable set's regions are used.