The data-platform project in HCP Terraform contains fifty workspaces that all deploy to one AWS account using the same IAM role through dynamic provider credentials. Workspaces added to the project later must pick up the settings automatically, and workspaces in other projects must not receive them. What is the most maintainable approach?

Variable sets let one group of variables apply to many workspaces, and a project-scoped set applies to every current and future workspace in the chosen project while staying invisible to workspaces elsewhere. Dynamic provider credentials are driven by environment variables, so placing TFC_AWS_PROVIDER_AUTH and TFC_AWS_RUN_ROLE_ARN in that set enables the same role for all fifty workspaces with one change point. A global variable set would apply to every workspace in the organization, which violates the requirement that other projects must not receive the settings and broadens who can assume the role. Passing the values as Terraform input variables misunderstands the mechanism: HCP Terraform reads these as environment variables before the run to request the identity token and configure the provider, so a module input does not enable the feature. A script that copies variables into each existing workspace works once, but workspaces added later miss the settings and every future change has to be re-run across fifty copies. Exam caveat: a workspace variable with the same key still overrides a non-priority variable set, so check for leftovers. Operational check: create a new workspace in the project, confirm the variable set appears on its Variables page, and run a plan that assumes the role.