During a maintenance window an engineer changes the management IP address, netmask, default gateway, primary DNS server, and NTP server on a Data Domain, all in one sitting, to match the target design in the handover packet. When finished, the management GUI is unreachable, and the engineer decides to roll all five settings back because nobody can tell which change caused the loss of reachability. Which working practice would have prevented this outcome?
Select an answer to reveal the explanation.
Short Explanation
Change five network settings at once and when the box goes dark, you have five suspects and no witnesses. The fix is boring but bulletproof: change one thing, prove reachability from the console, then move on, so the broken change confesses immediately. Trust that one-at-a-time habit; it is the difference between a two-minute rollback and a full-blown escalation.
Full Explanation
Network settings interact, and only a discipline of applying one change and verifying it before the next creates a clean causal chain from symptom to cause. Console access and the platform's connectivity tests give ground truth at each step: after an address or netmask change you test the local subnet and gateway, after a gateway change you test a known off-subnet host, and after DNS or NTP changes you test name resolution and clock sync respectively, so a failure points at the single setting just modified. Snapshot-based rollback is a recovery mechanism, not a diagnostic one: it restores service but leaves the defective value unidentified, and the same breakage returns whenever the batch is retried in anger. Console-only batch work preserves your access during the window but still ends with five unverified changes and the original mystery, while ordering by perceived risk confuses probability with evidence, since a wrong netmask or gateway breaks reachability regardless of when it is applied. Exam caveat: keep a live console session open during any remote network change, because some settings can drop the in-band path mid-configuration. Operational check: after each change run a targeted test such as pinging the gateway or a known remote host, and confirm GUI or SSH reachability before scheduling the next change.