HashiCorp Terraform Associate (004) Question 49
Single answer3 Core Terraform workflowA platform team stores its Terraform configuration in Git and uses a remote backend for state. A developer updates a module version in the root configuration and wants to review the exact infrastructure changes before applying them in production. The team also wants the reviewed plan to be the same one that gets applied later in the deployment step. Which approach best satisfies this requirement in the core Terraform workflow?
- A
Run
terraform validateto confirm the configuration, then runterraform applyduring deployment because Terraform will recalculate the same changes. - B
Run
terraform plan -out=prod.tfplanafter initializing, review the proposed changes, and later runterraform apply prod.tfplanin the deployment step. - C
Run
terraform fmtand commit the formatted files, then runterraform applyin production because formatting ensures the plan will not change. - D
Run
terraform refreshto update the state file, review the refreshed state, and then runterraform applywithout creating a saved plan file.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to generate and save a plan with terraform plan -out=prod.tfplan, review that plan, and later apply the same file with terraform apply prod.tfplan. This is a core Terraform workflow practice when teams want stronger control between planning and applying, especially in CI/CD pipelines or production approval processes. terraform validate and terraform fmt are useful workflow commands, but they do not replace planning. A key distinction is that terraform apply without a saved plan file creates a fresh plan at execution time, so it may not exactly match what was previously reviewed. HashiCorp documentation for the Terraform workflow and command references describes using saved plan files to ensure the reviewed execution plan is the one actually applied.
- A. Incorrect.
terraform validatechecks whether the configuration is syntactically valid and internally consistent, but it does not produce an execution plan to review or guarantee that a later apply uses the exact same set of actions. If you runterraform applywithout a saved plan file, Terraform generates a new plan at apply time, which could differ if the environment or state changed. - B. Correct.
This is correct. In the standard Terraform workflow, you run
terraform initas needed, thenterraform plan -out=...to create a saved execution plan. That plan can be reviewed and then applied later withterraform apply <planfile>. Using a saved plan file ensures the apply step executes the reviewed plan rather than recalculating a new one at deployment time. - C. Incorrect.
terraform fmtonly rewrites configuration files into Terraform's canonical style. It improves readability and consistency but has no effect on whether infrastructure changes are reviewed or whether the exact reviewed plan is applied later. - D. Incorrect.
terraform refreshis not the right solution here. Refresh-related behavior is about reconciling state with real infrastructure, not about preserving a reviewed execution plan for later application. Reviewing state is also not the same as reviewing proposed changes. Applying without a saved plan would cause Terraform to create a new plan at apply time.