Two hundred HCP Terraform workspaces must move from Terraform 1.13 to 1.15 in controlled batches, and every change has to be reviewable and repeatable. Clicking through each workspace's settings page is not acceptable. What should the platform team do?
Select an answer to reveal the explanation.
Short Explanation
Two hundred clicks is a recipe for a typo. Put the version in code with the tfe provider, or script the API, and you roll it out in batches you can review and repeat.
Full Explanation
Each workspace's Terraform version is a setting that can be managed programmatically. The tfe provider's tfe_workspace resource has a terraform_version argument that accepts an exact version or a constraint, and the Update a Workspace API endpoint can change the same setting. Managing it as code means each batch is a reviewed pull request, for example changing the value for one group of workspaces in a for_each map, applied from a management workspace, with history showing exactly when each group moved. The API is suitable for scripted, idempotent changes driven from a pipeline. Changing required_version in configuration only constrains which versions may run; it does not alter the workspace setting, so runs would simply fail until the setting is changed. HCP Terraform does not read a TF_VERSION environment variable to select its binary, so a variable set cannot change the version. terraform init -upgrade updates providers and modules within their constraints and does not change the workspace's Terraform version, which remote runs take from the workspace setting rather than from anyone's laptop. Exam caveat: batch upgrades should start with non-production workspaces and check each batch's plans before moving on. Operational check: after applying a batch, query the explorer's Terraform versions view and confirm exactly the intended workspaces report 1.15.