A monorepo holds envs/dev, envs/stage, envs/prod and a shared modules directory. The VCS-backed prod workspace currently plans on every commit to any file. It should plan only when files under envs/prod or modules change. How should the workspace be configured?
Select an answer to reveal the explanation.
Short Explanation
Point the workspace at its own folder, then tell it which folders you care about. Working directory plus path-based triggers means a dev tweak doesn't wake up prod, but a shared module change still does.
Full Explanation
In a VCS-backed workspace, the Terraform working directory tells HCP Terraform where in the repository to execute runs, which is required when one repository holds several configurations. The Automatic Run Triggering setting then decides which commits start runs. Choosing Only trigger runs when files in specified paths change and adding trigger patterns such as /envs/prod/**/ and /modules/*/* makes the workspace plan only when its own directory or the shared modules change; trigger prefixes are an alternative, and both also govern speculative plans on pull requests. Always trigger runs is the setting that causes the current behaviour, and HashiCorp recommends against it for true monorepos. A .terraformignore file controls which files a CLI-driven run uploads; it does not influence which VCS commits trigger runs. Tag-based triggering starts runs only when a matching git tag is published and ignores ordinary commits to envs/prod, which is a different release model from the one described. A run trigger queues prod after successful applies in other workspaces, so prod would run on dev and stage changes rather than on its own files. Exam caveat: if the VCS provider does not return a list of changed files, or the list is too large, HCP Terraform triggers runs on all attached workspaces. Operational check: push a commit that changes only envs/dev and confirm the prod workspace queues nothing.