Before a risky change, an engineer opens the configuration archive and finds it empty. The backup job has been failing for weeks. What has to be fixed before the change is safe to make?
Select an answer to reveal the explanation.
Short Explanation
The archive you would roll back to has been empty for weeks, because the job that fills it is failing. Fix the backup before the risky change. Hiding a guest name does not write a configuration.
Full Explanation
A restore is only possible if a backup actually landed. This job has been failing for weeks and the archive is empty, so the risky change has no rollback until the job is fixed and a real copy exists. Hiding the guest SSID does not fill an archive. The beacon interval does not write a configuration when it expires. Client exclusion does not store the running configuration. The backup job has been failing, so the archive the engineer trusts is empty. The maintenance miss is the failed job, not the change they are about to make. Check one live client after the change and leave the rest of the floor alone until that client matches the result you expected. Read the live counters after you retest. Confirm the symptom is gone on the next attempt before you change a second setting anywhere else on that floor. Exam caveat: a job that reports success and writes an empty file is not fixed either. Open the archive after a run and confirm the configuration is in it. Operational check: repair the job, run it once, and confirm the archive contains the current configuration before the change starts.