The networking repository uses main for ongoing work and a release branch for approved changes. The dev workspace should run on merges to main, while the prod workspace, connected to the same repository, must run only on changes to the release branch. What should be configured?
Select an answer to reveal the explanation.
Short Explanation
Each VCS-backed workspace can listen to a different branch. Tune prod to release and dev to main, and you get two workspaces on one repo that never hear each other's music.
Full Explanation
Every VCS-backed workspace has a VCS branch setting that designates which branch HCP Terraform uses when the workspace triggers runs from commits. If the setting is blank, the repository's default branch is used. Connecting both workspaces to the same repository and setting prod's branch to release, while dev uses main, means merges to main run only in dev and merges to release run only in prod. Promotion then becomes a merge from main to release, which goes through the repository's own review controls. A run trigger from dev to prod queues a prod run after every successful dev apply, which is the opposite of the requirement: prod would follow main. Automatic speculative plans only control plans on pull requests; disabling them does not change which branch's commits trigger real runs. required_version is a Terraform version constraint in the terraform block and has nothing to do with Git branches. Exam caveat: if a workspace is configured to trigger runs when a git tag is published, tags trigger runs regardless of the branch setting, so tag-based and branch-based setups should not be mixed by accident. Operational check: merge a trivial change to main and confirm only dev queues a run, then merge it into release and confirm prod queues a run.