At acceptance testing, the team pulls the cable on the active management link and the GUI stays unreachable for the entire failover period — redundancy had been assumed but never demonstrated. What belongs in the basic network configuration to prevent this outcome?

Redundancy is a configuration plus an observed behavior, never an intention. The management path should reach acceptance with an explicit arrangement selected — which interface is active, what standby exists, what the failover behavior and expected convergence time are — and the setup should end with a physical pull test that measures that behavior while the deployer still controls the window. Silence for the entire failover period in this story is the test telling the truth: without configured failover, a failed link simply removes the path, and the recovery people expected was never built. Replication-layer guarantees fail by scope — data replication protects data placement across systems and does nothing to move a management address from a dead interface to a live one. Switch-side spanning-tree priorities fail by mechanism: STP prevents and repairs loops within a switching topology; it cannot relocate an interface's IP identity to another appliance port that was never configured to hold it. Postponing the proof to a later team fails the definition of done — the pull test is the configuration task's verification step, and deferring it converts a measurable design attribute into a surprise reserved for the first real failure. Exam caveat: record the measured interruption in seconds, not just a pass-or-fail tick, so future changes have a baseline. Operational check: pull the active management link, watch reachability drop and return, confirm the standby interface answers with the management address, and file the measured failover time in the acceptance record.