Before a Terraform change that opens a new peering path for emergency services merges, a second city engineer must examine the diff. What source-control practice is this?
Select an answer to reveal the explanation.
Short Explanation
Two pairs of eyes beat one hurried merge—especially when the change is a network peering for 911 systems. Code review is the seatbelt: catch the bad route, secret, or typo before it hits main. Force-pushing solo is how outages get a head start.
Full Explanation
Requiring a second city engineer to examine the Terraform diff that opens a new peering path for emergency services before it merges is code review as a quality and security gate before merge. Peer review catches incorrect routes, overly broad CIDRs, accidental secrets, and policy violations before they reach the protected main line that civic automation deploys from. Deleting the remote repository after every successful apply destroys collaboration, CI hooks, and historical evidence. Skipping peer input whenever the change touches only comments is unsafe because substantive configuration can hide beside comment edits in the same diff. Force-pushing directly to production main to save calendar time bypasses the control the gate exists to enforce. Exam caveat: network and identity-impacting IaC should retain mandatory review even under emergency pressure; any break-glass merge must still be logged, time-bounded, and retrospectively reviewed by municipal security. Operational check: require at least one non-author approval on the peering pull request, confirm policy and CI checks are green, merge only after approval, record reviewers on the change ticket for the emergency-services path, and verify the applied peering matches the reviewed diff before closing the window.