002 · Domain 4: CI/CD and Automation Workflows · 10% of the exam
Task 4.1: Manage CI/CD pipeline functionality
Terraform in a pipeline: plan on pull request, apply the saved plan after approval, exit codes, non-interactive flags, and comments and artifacts that reviewers read.
Study it
Terraform pipelines: plan on pull request, apply the saved plan
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 1
A pipeline runs terraform plan -out=tfplan on a Windows build agent and stores only the tfplan file as an artifact. The apply job runs later in a Linux container, restores tfplan into a fresh checkout, runs terraform init -upgrade and then terraform apply tfplan, which fails. Which change makes the two-step workflow reliable?
AConvert the plan with terraform show -json and pass the JSON file to terraform apply in the Linux job
BRun both jobs on the same OS and architecture, archive the whole working directory with .terraform, and restore it at the same absolute path
CKeep both platforms and run terraform init -reconfigure in the Linux job before it applies tfplan
DKeep init -upgrade in the apply job to fetch the same providers the plan used
Show the answer and why
AConvert the plan with terraform show -json and pass the JSON file to terraform apply in the Linux job
Incorrect
The JSON representation is for inspection and tooling; terraform apply accepts only the saved plan file.
BRun both jobs on the same OS and architecture, archive the whole working directory with .terraform, and restore it at the same absolute path
Correct
A plan must be applied on the same OS and architecture, can contain absolute paths, and needs the identical Terraform and provider plugins that created it.
CKeep both platforms and run terraform init -reconfigure in the Linux job before it applies tfplan
Incorrect
Reinitializing does not change the rule that a plan must be applied on the same operating system and CPU architecture where it was created.
DKeep init -upgrade in the apply job to fetch the same providers the plan used
Incorrect
-upgrade can select newer provider versions, and Terraform errors if plugins change between creating and applying a plan.
A saved plan is tied to the environment that produced it. Archive the full working directory after plan, restore it at the same path on the same platform, and do not upgrade Terraform or providers in between.
A release pipeline plans on merge, waits for a human approval, then applies. Twice last month the apply job changed things nobody had reviewed. Which two practices make sure the apply executes exactly the plan that was approved? (Choose TWO.)
AAllow only one outstanding plan per state at a time; approve or dismiss it before the next plan
BAfter approval, run terraform apply -auto-approve in the apply job against the merged commit
CApply the speculative plan produced for the pull request once the pull request is merged
DRun the apply with -lock=false to keep a plan waiting in the pipeline from blocking the approved one
EPass the saved plan file from the approved plan step to the apply step as a pipeline artifact
Show the answer and why
AAllow only one outstanding plan per state at a time; approve or dismiss it before the next plan
Correct
HashiCorp recommends a single outstanding plan; applying one plan invalidates others made against the same state.
BAfter approval, run terraform apply -auto-approve in the apply job against the merged commit
Incorrect
Without a plan file, apply creates a fresh plan that nobody reviewed and applies it without asking.
CApply the speculative plan produced for the pull request once the pull request is merged
Incorrect
That plan was computed for the pull request before the merge, so it is not the plan the release approver reviewed.
DRun the apply with -lock=false to keep a plan waiting in the pipeline from blocking the approved one
Incorrect
Disabling locking allows concurrent writers and does nothing to tie the apply to the approved plan.
EPass the saved plan file from the approved plan step to the apply step as a pipeline artifact
Correct
Applying the saved plan performs exactly the reviewed operations, and passing the file counts as the approval.
An approval only means something if the apply executes the approved plan. Connect the steps through the saved plan artifact and keep one outstanding plan at a time so it cannot go stale behind another apply.
Developers keep copying the "run terraform apply" hints from pipeline logs and running commands by hand. Which setting makes Terraform play down those suggestions in automated runs?
ATF_INPUT=0 in the job environment
BTF_LOG=ERROR for every pipeline step
C-compact-warnings added to every single command
DTF_IN_AUTOMATION, set to any non-empty value
Show the answer and why
ATF_INPUT=0 in the job environment
Incorrect
That disables prompts; it does not change the hints in the output.
BTF_LOG=ERROR for every pipeline step
Incorrect
TF_LOG controls the debug log, not normal command output.
C-compact-warnings added to every single command
Incorrect
That shortens warnings only.
DTF_IN_AUTOMATION, set to any non-empty value
Correct
With it set, Terraform makes minor output adjustments to de-emphasize specific commands to run next.
Automation tools hide which commands actually run, so hints aimed at a human at a terminal can mislead or tempt people to bypass the pipeline.
A pipeline applies a saved plan and then marks the environment as converged. For one plan, terraform show -json reported "complete": false. What should the pipeline expect after applying it?
AThe apply fails, as the plan could not be fully created
BAt least one more plan and apply round before it converges
CNothing more; complete only reports on missing root output values
DTerraform reverts the apply unless another plan follows
Show the answer and why
AThe apply fails, as the plan could not be fully created
Incorrect
A plan whose creation failed is reported with errored; an incomplete plan can still be applied.
BAt least one more plan and apply round before it converges
Correct
An incomplete plan is expected to require at least one additional plan and apply round to achieve convergence.
CNothing more; complete only reports on missing root output values
Incorrect
complete describes whether applying the plan reaches the desired state, not output values.
DTerraform reverts the apply unless another plan follows
Incorrect
Terraform does not roll back an apply; the remaining changes come in a later run.
Wrapping automation should loop on the complete flag rather than infer convergence from other fields, whose exact meaning may change in later Terraform versions.
A public repository's pipeline runs terraform plan for every pull request and passes a cloud credential as an environment variable. What risk does HashiCorp's automation guide warn about?
AAny contributor able to propose a change could read it
BThe plan writes the credential into the dependency lock file
CTerraform does not read environment variables during plans
DThe credential expires after the first plan
Show the answer and why
AAny contributor able to propose a change could read it
Correct
Sensitive data passed through variables or environment variables can be discovered by anyone able to submit a pull request.
BThe plan writes the credential into the dependency lock file
Incorrect
The lock file holds provider selections and checksums only.
CTerraform does not read environment variables during plans
Incorrect
Terraform reads environment variables for plans as well.
DThe credential expires after the first plan
Incorrect
Credential lifetime depends on the issuer, not on Terraform.
Limit secrets on pull request pipelines, especially for contributions from outside the organization.
A pipeline uses an HCP Terraform workspace with remote execution and no VCS link. It wants to plan locally with -out, then upload the file for the remote apply. What does the CLI-driven run documentation recommend instead?
AUploading the file with terraform apply tfplan
BUploading the file as a configuration version through the API
CA speculative run reviewed first, then apply -auto-approve
DSwitching the workspace to agent mode to accept the file
Show the answer and why
AUploading the file with terraform apply tfplan
Incorrect
Locally executed saved plans cannot be applied in a remote workspace.
BUploading the file as a configuration version through the API
Incorrect
Configuration versions hold configuration files, not plans.
CA speculative run reviewed first, then apply -auto-approve
Correct
HCP Terraform does not support uploading saved plans for remote execution; the recommended pattern is a speculative plan followed by an auto-approved apply.
DSwitching the workspace to agent mode to accept the file
Incorrect
Agent execution is still remote execution.
Remote saved plans made with plan -out in the workspace itself are a different feature and apply only in that same workspace.