A company's in-house release orchestrator must start HCP Terraform runs. It communicates only over HTTP APIs, cannot run the Terraform CLI, and the configuration is assembled at release time rather than stored in a supported VCS repository. Which workflow fits?
Select an answer to reveal the explanation.
Short Explanation
When your tooling can't run the CLI and there's no repository to watch, you talk to HCP Terraform directly. Package the configuration, upload it as a new configuration version, and ask for a run. That's the API-driven workflow in a nutshell.
Full Explanation
In the API-driven workflow, HCP Terraform does not fetch configuration from version control. External tooling calls the configuration versions API to create a configuration version, uploads the configuration files as a .tar.gz archive, and then uses the runs API to queue a run with that configuration. This is designed for unsupported version control systems, generated configurations and custom orchestration, which matches an orchestrator that speaks HTTP and assembles code at release time. Run triggers connect workspaces to other workspaces in the organization, so a successful apply in a source workspace queues a run; they cannot be pointed at an external system. Connecting a VCS repository conflicts with the stated constraint, and the claim that runs can only start from VCS or the UI is false, since both the CLI-driven and API-driven workflows exist. Uploading a state version changes the recorded state; it does not supply configuration or start a plan. Exam caveat: the API-driven workflow still honours the workspace's apply settings, policies and permissions, and the API token used should belong to a team with only the access needed. Operational check: confirm the run appears in the workspace referencing the newly uploaded configuration version.