All workspaces in the dev project need the same TF_VAR_region value and the same non-production credentials, including workspaces added later. Workspaces in the prod project must not receive these values. What should the platform team configure?
Select an answer to reveal the explanation.
Short Explanation
Think of a variable set as a care package you can address to a whole floor. Address it to the dev project and every dev workspace, new or old, gets one. Send it globally and prod gets the dev credentials too.
Full Explanation
Variable sets are reusable collections of Terraform and environment variables that HCP Terraform applies to multiple workspaces. A set can be owned by the organization or by a project, and a project-owned set can apply to the entire project, which covers all existing and future workspaces in it. That gives the dev workspaces a single source for TF_VAR_region and the non-production credentials, and managing the set needs only project-level permissions. A global variable set applies to every existing and future workspace in the organization, which would deliver dev credentials into prod and break the stated isolation. Copying workspace-specific variables into each workspace creates many unsynchronised copies that drift and depends on people remembering to add them to new workspaces. A priority global variable set has the same scope problem as a normal global set and, worse, overrides values set at more specific scopes, so prod workspaces could not even replace the values locally. Exam caveat: when sets of the same scope conflict, HCP Terraform resolves by lexical order of set names, and variables in a workspace still lose to priority sets; mark credentials as sensitive so they cannot be read back after saving. Operational check: open a dev workspace's Variables page and confirm the set is listed, then open a prod workspace and confirm it is absent.