HashiCorp Terraform Associate (004) Question 53
Single answer3a Describe the Terraform workflowA platform engineer updates several Terraform configuration files to add a new AWS security group rule and rename a resource block for an existing IAM role. Before making any changes in production, the engineer wants to review what Terraform will do, confirm whether the rename will cause recreation, and then apply exactly that reviewed set of changes. Which workflow best meets this requirement?
- A
Run
terraform validate, thenterraform applydirectly in production because Terraform automatically shows the execution plan before applying. - B
Run
terraform plan -out=prod.tfplanto generate and review the execution plan, then runterraform apply prod.tfplanafter approval. - C
Run
terraform fmt, thenterraform refresh, and finallyterraform applyso Terraform uses the refreshed state as the approved change set. - D
Run
terraform initagain after editing the files, thenterraform destroyandterraform applyso renamed resources are recreated in a controlled way.
Show answer and explanation
Correct answer: B
Explanation
In the Terraform workflow, common steps include writing or updating configuration, initializing the working directory with terraform init, reviewing proposed changes with terraform plan, and making changes with terraform apply. When a team needs an approval process, saving a plan with terraform plan -out=FILE is important because Terraform can later apply that exact plan using terraform apply FILE. This avoids recalculating changes at apply time and supports controlled change management. HashiCorp documentation describes the plan phase as the step where Terraform determines what actions are required to reach the desired state, and the apply phase as executing those actions. In this scenario, the engineer specifically wants to review the impact of a rename and then apply exactly what was reviewed, so using a saved plan file is the best match to Terraform best practices.
- A. Incorrect.
terraform validatechecks whether the configuration is syntactically valid and internally consistent, but it does not create an approved execution plan artifact. Runningterraform applydirectly will generate a plan at apply time, but that is not the same as reviewing a plan in advance and then applying that exact reviewed plan. This option misses the requirement to apply exactly the reviewed set of changes. - B. Correct.
This is correct.
terraform plan -out=prod.tfplancreates an execution plan file that can be reviewed before any infrastructure changes are made. If the team approves that plan,terraform apply prod.tfplanapplies exactly the saved plan rather than recalculating changes. This is the recommended workflow when you need a review-and-approve step and want to ensure the applied changes match what was reviewed. - C. Incorrect.
terraform fmtstandardizes formatting, which is useful but unrelated to approving infrastructure changes.terraform refreshupdates state to match remote objects, but it does not create an approved execution plan for later application. Applying after a refresh still causes Terraform to calculate a new plan at apply time, so it does not satisfy the requirement to apply the exact reviewed changes. - D. Incorrect.
terraform initis used to initialize the working directory, download providers, and configure the backend; it is not required after every configuration edit unless initialization needs to change. More importantly,terraform destroyis not an appropriate or necessary step for reviewing and safely applying a change. Renaming a resource block may cause Terraform to see it as a different resource unless state is moved, but destroying and recreating everything is not part of the normal Terraform workflow for this scenario.