Most infrastructure work is forgiving. A bad deployment can be rolled back, a misconfigured autoscaler can be corrected in minutes, and a broken pipeline step can be reverted with a single commit. A smaller set of changes behaves differently: once executed, there is no clean path back, or the path back costs far more than the change itself. Those are the moments when an independent second reviewer, someone who did not design the change and has no deadline riding on it, earns their time. Below are eight such changes that DevOps engineers meet in practice, with notes on why each is hard to reverse and what an outside reviewer should examine before anyone presses enter.

Why a second reviewer, and why only for these

Routine code review already exists in most teams. The difference here is independence and focus. A colleague on the same squad shares your assumptions, your sprint goals and often your blind spots. A reviewer from another team or another organisation approaches the plan cold. Reserving this heavier step for genuinely one-way changes keeps it meaningful; applied to every pull request, it would simply slow delivery without adding safety.

The eight changes

1. Migrating or restructuring Terraform state

Moving resources between state files, splitting a monolithic state into modules, or changing the backend are operations where a single mistake can cause Terraform to believe infrastructure does not exist, and then try to create it again or destroy it. If you need a refresher on what state actually tracks, our explainer on how Terraform records the resources it manages covers the fundamentals.

Reviewer focus: the exact sequence of import, move and remove commands; whether a backup of the current state exists and has been tested; and whether a plan run after each step is expected to show zero changes.

2. Major-version database upgrades

Upgrading a production database across a major version often changes on-disk formats. Once applications have written data under the new version, downgrading may be impossible without restoring from backup and losing recent writes.

Reviewer focus: extension and driver compatibility, query planner changes that could slow critical queries, and the realistic time to restore if the upgrade must be abandoned.

3. Deleting or rotating encryption keys

Scheduling deletion of a key in a cloud key management service is, after the waiting period, permanent. Any data still encrypted with that key becomes unreadable. Rotations that retire old key versions carry a similar risk.

Reviewer focus: an inventory of every data store, backup and snapshot that might depend on the key, including those in other accounts or regions.

4. Transferring a domain or changing registrars

Registrar transfers lock the domain for a period and can disrupt DNSSEC, email routing and certificate validation. Getting it wrong on a primary domain affects every customer at once.

Reviewer focus: DNSSEC key handling during transfer, mail exchanger and verification records, and timing relative to certificate renewals.

5. Replacing a Kubernetes cluster rather than upgrading it

Blue-green cluster replacement is often safer than in-place upgrades, but the final step, decommissioning the old cluster, removes the fallback. Persistent volumes, external load balancer addresses and service account bindings may not transfer cleanly. Teams scaling container platforms will find wider context in our guide to running Kubernetes and cloud operations across an enterprise.

Reviewer focus: stateful workloads, any hard-coded addresses in partner systems, and how long the old cluster stays available after cutover.

6. Restructuring cloud accounts or organisations

Moving accounts between organisational units, consolidating billing, or closing legacy accounts can silently break permission boundaries, service control policies and cross-account roles. Closing an account may also start a countdown after which its resources are gone for good.

Reviewer focus: trust relationships that reference account identifiers, logging destinations, and any resource still running in an account scheduled for closure.

7. Changing data retention or lifecycle policies

Tightening a retention rule on object storage or a log platform will, at the next lifecycle run, permanently delete older data. A typo in a prefix or an overly broad rule can erase far more than intended.

Reviewer focus: exactly which objects match the rule, legal or contractual obligations to keep data, and whether a dry-run listing has been produced.

8. Retiring a region or data centre

Exiting a region is the largest item on this list and usually the slowest to reverse. Latency-sensitive users, regulatory data-residency requirements and disaster recovery assumptions all change at once.

Reviewer focus: residency obligations, whether recovery plans assume the region still exists, and any customer contract that names a location.

A pattern across all eight

Look at the list again and a common thread appears. In almost every case, the dangerous moment is not the main change but the clean-up that follows it: deleting the old state, retiring the previous cluster, closing the legacy account, letting the lifecycle rule run. Teams often review the migration carefully and then treat removal of the old thing as housekeeping. That is backwards. The removal is usually the one-way step, and it is exactly where an independent reviewer should be asked to look. A useful rule is to schedule the review for the decommission ticket, not just the migration ticket, and to keep the fallback alive until that review has been completed.

What to hand the reviewer

Whichever of the eight you face, a reviewer can only work with what you supply. A compact pack should include:

• A one-sentence statement of the change and the point beyond which it cannot be undone.
• The runbook with exact commands or pipeline steps.
• Evidence from a rehearsal in a non-production environment.
• A list of assumptions the team has not been able to verify.
• The team’s own recommendation, stated plainly, so it can be challenged directly.

When the reviewer’s view differs from yours

Disagreement is the purpose of the exercise, not a failure. Handle it methodically:

• Check for information gaps first. Many differences disappear once both sides see the same data.
• Distinguish fact from risk tolerance. If both agree on what will happen but differ on whether it is acceptable, escalate the trade-off to the accountable owner.
• Look for a way to make the change less permanent, such as retaining a snapshot, extending a deletion window or keeping the old cluster idle for longer.
• Write both positions down in the change record.

A practice shared with other high-stakes fields

Engineering is not alone in this. Aircraft maintenance uses independent inspection of critical work, and in medicine an independent review of a diagnosis is a long-standing practice that some health portals offer directly. MyMedicPlus, which covers treatments, medical tests and travel for care, is one site that accepts a diagnosis someone has already received and routes it to an expert for a fresh opinion. This article expresses no view on any medical matter, which only qualified clinicians can address; the mention illustrates how widely the principle is accepted.

Building the habit into training

For learners preparing for infrastructure certifications, it is worth practising this discipline early. When you work through labs, write a short review pack for any step that destroys or migrates resources and ask a classmate from a different cohort to read it. The exam may not test the habit, but production will. If you are studying for HashiCorp credentials specifically, our Terraform certification study guide pairs well with rehearsing items one and seven above in a sandbox account.

Key points

• Reserve independent review for changes that are both high-impact and hard to reverse.
• Choose a reviewer outside the team and outside the deadline.
• Give them evidence and assumptions, not a sales pitch.
• Treat disagreement as information and record how it was resolved.