Use Terraform outside the core workflow →hardMultiple ChoiceObjective-mapped

TF-004 Use Terraform outside the core workflow Practice Question

An organization uses Terraform Cloud with a VCS-backed workspace connected to a GitHub repository. They want to trigger a speculative plan without creating a run (i.e., without costing compute resources or being displayed in the workspace). Which approach is appropriate?

⚠ Common exam trap

Watch out — candidates often confuse 'speculative plans' with regular runs, assuming any plan triggered from a local CLI will create a run record, when in fact the remote backend distinguishes between speculative and non-speculative plans based on the command context.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Run 'terraform plan' from a local CLI configured with the same workspace and a remote backend.

Running 'terraform plan' from a local CLI configured with the same workspace and a remote backend triggers a speculative plan that is computed on Terraform Cloud but does not create a run record or consume run credits. This allows the user to preview changes without affecting the workspace's run history or incurring costs.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Push a new commit to the GitHub repository with a 'plan' label.
Why it's wrong here
Pushing a new commit to a GitHub repository linked to a VCS-backed Terraform Cloud workspace will automatically trigger a formal run in Terraform Cloud. This process initiates a plan and potentially an apply, which is recorded in the workspace's run history. While specific commit messages or labels can influence run behavior (e.g., skipping applies), the act of committing itself always creates a formal run, not a speculative plan that avoids a run record.
✗
Use the 'plan -out' flag with a special path to avoid creating a run.
Why it's wrong here
The `terraform plan -out` flag saves the generated execution plan to a local file, which can then be used for a subsequent `terraform apply`. This flag solely affects the local output of the plan and does not influence how Terraform interacts with a remote backend. If the CLI is configured for a remote backend, `terraform plan` will still initiate a remote plan operation within Terraform Cloud, regardless of whether the plan is saved locally.
✗
Use the Terraform Cloud API to queue a plan with 'auto-apply' disabled.
Why it's wrong here
Using the Terraform Cloud API to queue a plan, even with `auto-apply` explicitly disabled, still initiates a formal "run" within the Terraform Cloud environment. This API call is designed to programmatically control the run lifecycle, meaning the plan execution will be performed by Terraform Cloud's infrastructure and recorded in the workspace's run history. It is not a method for executing a speculative plan that avoids creating a formal run entry.
✓
Run 'terraform plan' from a local CLI configured with the same workspace and a remote backend.
Why this is correct
When the local Terraform CLI is configured with a remote backend (like Terraform Cloud) and targets a specific workspace, executing `terraform plan` by default performs the plan operation locally. It fetches the remote state and configuration but executes the planning logic on the local machine without initiating a formal "run" in Terraform Cloud's UI or run history. This allows for quick, iterative validation of changes without consuming Terraform Cloud run credits or cluttering the run history.

Go deeper

TF-004 Use Terraform outside the core workflow Practice Question

Why each option matters

Option-by-option breakdown

Related to this question