During a production incident, one misconfigured security group rule is blocking traffic. The main branch also holds several merged but unapplied changes to other resources that have not been reviewed for release yet. The on-call engineer must correct only the broken rule right now. Which approach follows Terraform's guidance for this situation?
Select an answer to reveal the explanation.
Short Explanation
Think of -target as the fire extinguisher on the wall: you grab it in an emergency, not to cook dinner. It lets you fix the one broken rule now, but you've left the rest of the configuration out of step with reality. That's why the trap answers fail: making it routine, or walking away without a full plan afterwards.
Full Explanation
Resource targeting tells Terraform to plan only the addressed resource instances plus whatever they depend on. HashiCorp documents it for exceptional circumstances such as recovering from mistakes or working around limitations, which describes an incident fix on a branch that also carries unreleased changes. Because a targeted run skips everything else, the configuration and the real infrastructure can be left inconsistent, so the recovery is not complete until a normal, untargeted plan has been reviewed and the remaining changes are applied or deliberately held back. Building -target into the standard pipeline is explicitly discouraged: routine targeting hides drift and confuses how state relates to configuration; the recommended fix for very large configurations is to split them into smaller ones. Refresh-only mode never changes remote objects; it only updates state to match what already exists, so it cannot push a corrected rule. A targeted apply records only the targeted objects, not the other pending changes. Exam caveat: targeting is acceptable in recovery, never as a release strategy. Operational check: after the targeted apply, run a full terraform plan and confirm the only differences are the reviewed, intentionally pending changes.