TL;DR: Approve only after confirming the plan is fresh (CI-generated from the exact reviewed commit and inputs against refreshed state), then read it in blast-radius order: deletes, replaces, creations, in-place updates, and finally the changes that are missing. If you cannot explain every line, including the absent ones, you are not ready to approve.
How to approach it
Present an ordered checklist rather than vibes, and open with the trust question: where was this plan generated and against what state. The interviewer is checking whether your approval means anything or is a rubber stamp.
A strong answer
First establish the plan is real. A plan worth approving comes from CI, built from the exact reviewed commit, with state refresh enabled. A plan captured on a laptop six hours ago describes a world that no longer exists, and -refresh=false plans hide drift by construction. If the artifact cannot answer "reviewed commit and inputs, refreshed state, generated when", stop there.
Bind approval to execution. Save the plan with -out, record its digest, environment and reviewed inputs, and apply that exact protected artifact. If code, inputs or state invalidate it, re-plan and re-approve; a fresh unreviewed plan is not the artifact that received approval. Saved plans contain sensitive data.
Then read it in blast-radius order. Deletions first: each one is a question ("who uses this?"), and a delete you cannot explain is a page waiting to happen. Replacements next, the -/+ lines with their forces replacement reason: opening that reason chain tells you which attribute triggered it, typically something immutable like an availability zone or AMI. Creations third, checking naming, tags, and cost-bearing sizes. In-place updates last, moving slowly over security-sensitive fields.
Then interrogate the absences. An expected change missing from the plan is the classic wrong-directory or wrong-workspace symptom, and it is how staging edits reach production under a tired reviewer who read only the summary line. Summary counts exist for triage speed, not approval: "Plan: 2 to add, 1 to change" is where reading starts, never where it ends.
Security-bearing lines get slower eyes: IAM policy attachments, security group rules mentioning 0.0.0.0/0, deletion_protection flipping off, public IP assignment, key policy edits. Many teams automate this layer by running conftest or Checkov rules against plan JSON, which catches predictable violations and leaves the human judging intent. Automation raises the floor; it does not read the plan for you.
Two refusal cases worth naming out loud: plans built with -target, which apply a slice of the graph and quietly leave the rest pending, and plans whose inputs came from unreviewed -var flags instead of the tfvars in the pull request, which makes the approved artifact unreproducible.
What interviewers probe next
"A provider upgrade shows 300 resources as replaced. Approve?" Never wholesale. Read the provider changelog for schema changes, trial the bump on one disposable stack, and look for the attribute fix that collapses the mass replacement.
"Apply failed halfway. Now what?" State sits behind or ahead of reality depending where it stopped: re-plan carefully, import anything created but unrecorded, then continue. Do not blindly re-apply.
"Fifty merges a week: how does review scale?" Tiered approvals. Policy-checked low-risk stacks need one reviewer; identity-touching or data-bearing stacks need two; the plan artifact attached to the PR is the record of exactly what was approved.
Common mistakes
Approving from the summary counts without reading a single diff line.
Treating a replacement as cosmetic because "it comes back up", while the elastic IP, local volumes, or DNS records pointing at the old object die with it.
Approving a plan generated before the last merge landed, so the applied code was reviewed by nobody.
Sources: Saved-plan apply.