A change window depends on a configuration backup that has never been restored, even in a lab. What is still unproven about that backup?
Select an answer to reveal the explanation.
Short Explanation
A file you have never rolled back is a hope, not a plan. Restore it once in a lab before the window depends on it. Saving the guest name is not the test.
Full Explanation
A backup proves it can be restored only after a restore succeeds. This file has never been restored, even in a lab, so the window's rollback is untested. The backup does not prove an SSID is hidden. It does not wait for a restore before it contains the beacon interval, and the beacon is not what this test is about. Saving a backup does not clear client exclusions. The backup file has never been restored, even to a lab controller. An untested backup is not yet a rollback plan. Check one live client after the change and leave the rest of the floor alone until that client matches the result you expected. Confirm the symptom on the next attempt before changing anything else. Exam caveat: a restore in a lab that uses different hardware or a different version can succeed there and fail on the production pair. Restore to something as close as you can to the chassis you would really recover. Operational check: restore the file to a lab controller, confirm the configuration comes back, and only then treat it as the rollback for the window.