In HCP Terraform, an app workspace reads values produced by a network workspace. Whenever the network workspace successfully applies a change, the app workspace should automatically queue a new run so it picks up the new values. Which feature provides this?
Select an answer to reveal the explanation.
Short Explanation
Run triggers are the 'when you're done, tap me on the shoulder' feature. The app workspace subscribes to the network workspace, and every successful apply there queues a fresh app run. Sharing state just opens the door; it doesn't ring the bell.
Full Explanation
Run triggers connect a workspace to one or more source workspaces in the same organization. When a run in a source workspace applies successfully, HCP Terraform automatically queues a run in the connected workspace, which is designed for workspaces that rely on information or infrastructure produced by others. Configuring the network workspace as a source in the app workspace's run triggers makes the app re-plan with the latest values after every successful network apply. Remote state sharing only grants permission for another workspace to read state during its own runs; it never starts a run. Run tasks call external services during a run's stages to perform checks and report results; they do not apply other workspaces. Pointing the app's VCS connection at the network repository would queue app runs when network code is committed, before the network change has been applied, so the app would read stale values, and it would also run the app with the wrong configuration source. Exam caveat: runs queued by run triggers are not auto-applied unless the workspace is set to allow that, so a person may still need to confirm them. Operational check: apply a change in the network workspace and confirm a new run appears in the app workspace citing the run trigger as its source.