At noon on a weekday, a network engineer modifies the edge firewall rules without submitting a change request, and remote VPN users lose connectivity for two hours. What was the ROOT process failure?
Select an answer to reveal the explanation.
Short Explanation
Change management is like air traffic control: you don't take off without clearance. This engineer skipped the tower entirely. A backup firewall or a fresher diagram won't fix that, because the failure happened the moment the change went in unapproved.
Full Explanation
Change management exists to ensure that modifications to production systems are reviewed, scheduled, and approved by those who understand their impact. The change advisory board evaluates requests, considers impact analysis, test results, and backout plans, and approves an appropriate maintenance window. Skipping the request meant no one reviewed whether the rule change would affect VPN traffic, no one scheduled it outside business hours, and no backout plan was ready. A high-availability firewall peer would replicate the same faulty rules, so it would not have prevented the outage caused by a misconfiguration. Updating diagrams is part of closing a change correctly, but stale documentation was not what disconnected users. SIEM monitoring of the VPN concentrator might have shortened detection time, yet the outage stemmed from an unreviewed change rather than from a monitoring blind spot. Exam caveat: when a stem describes an unauthorized change during business hours that causes an outage, the expected answer is the bypassed approval process rather than a technical improvement. Operational check: compare firewall configuration change logs against approved change tickets, alert on any change without a matching ticket number, and restrict direct firewall administration to accounts used within approved change windows.