HashiCorp Terraform Associate (004) Question 50
Single answer3 Core Terraform workflowA team manages AWS infrastructure with Terraform. A developer updates several .tf files locally and wants to review exactly what Terraform will change before anyone applies it. The team also wants the reviewed plan to be the same plan that is later applied in CI, rather than recalculating changes at apply time. Which workflow best meets this requirement?
- A
Run terraform validate to see the pending infrastructure changes, then run terraform apply in CI.
- B
Run terraform plan -out=tfplan locally, review the proposed changes, commit the configuration changes, and have CI run terraform apply tfplan.
- C
Run terraform plan locally to review changes, then have CI run terraform apply without any plan file so it computes the latest changes again.
- D
Run terraform plan -out=tfplan locally, review the proposed changes, and then have CI run terraform apply tfplan using the same configuration and state context.
Show answer and explanation
Correct answer: D
Explanation
In the core Terraform workflow, terraform plan is used to create an execution plan by comparing the current state and real infrastructure with the desired configuration. When teams need approval gates or want to guarantee that the applied changes match exactly what was reviewed, they should save the plan with terraform plan -out=FILENAME and later apply that saved plan using terraform apply FILENAME. Running terraform apply without a saved plan causes Terraform to generate a new plan, which may differ from the reviewed one. terraform validate is useful earlier in the workflow for checking configuration validity, but it does not show infrastructure changes. This aligns with Terraform CLI best practices and HashiCorp documentation for plan and apply behavior.
- A. Incorrect.
Incorrect. terraform validate checks whether the configuration is syntactically valid and internally consistent, but it does not compare configuration to the current state or show a change plan. A common misconception is treating validate like a dry run of infrastructure changes; that is the role of terraform plan.
- B. Incorrect.
Incorrect. Saving a plan with terraform plan -out=tfplan is the right idea for applying the exact reviewed plan, but this option introduces a practical workflow problem: the binary plan file is tied to the specific configuration, state, variables, and environment context from when it was created. Committing and transporting a local plan file for CI use is not the normal or reliable workflow. The key requirement is that apply must use the same plan file in the same relevant execution context, not that the plan file should be committed to version control.
- C. Incorrect.
Incorrect. Reviewing terraform plan output locally is useful, but running terraform apply later without a saved plan causes Terraform to generate a new execution plan at apply time. That means the applied changes could differ from what was reviewed if the state, configuration, variables, or remote resources changed in the meantime. This fails the requirement to apply the same reviewed plan.
- D. Correct.
Correct. terraform plan -out=tfplan creates a saved execution plan file. Applying that exact file with terraform apply tfplan ensures Terraform executes the reviewed plan rather than recalculating a new one. This matches the core Terraform workflow when a team needs approval or review of planned changes before applying them. The saved plan must be used in the same appropriate execution context because it is based on the state, variable values, and configuration used at plan time.