Preventing Firewall ACL Changes from Breaking Production
While troubleshooting a firewall configuration, a technician determines that a “deny any” policy should be added to the bottom of the ACL. The technician updates the policy, but the new policy causes several company servers to become unreachable. Which of the following actions would prevent this issue?
Community Votes
71% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The exam tests the distinction between procedural governance (Change Management) and technical risk mitigation (Testing); the trap is choosing Change Management as the primary technical safeguard against misconfiguration errors.
This question explores the critical role of non-production testing in preventing service disruptions during firewall configuration changes. It establishes that while change management is required, only rigorous testing can validate technical correctness before production deployment.
Many learners select 'Documenting the new policy in a change request' because it is a mandatory process step; however, approving a request does not technically prevent the error if the configuration itself is flawed or untested.
Community Discussion (23 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The correct action to prevent this specific issue is B: Testing the policy in a non-production environment before enabling it in the production network. The scenario describes a technical failure where a blanket deny rule blocked legitimate traffic due to missing allow rules or incorrect ordering. A non-production (staging) environment allows the technician to verify that the ACL behaves as intended without impacting live business services. This directly addresses the root cause—the lack of validation—whereas administrative processes do not fix technical errors.Why the Other Options Are Wrong
Option A is incorrect because submitting a change request is a governance requirement, but it does not guarantee technical success; a change manager may approve a request based on documentation without verifying the code's logic. Option C is irrelevant because intrusion prevention signatures are not the cause of connectivity loss from a deny-all rule. Option D creates a security vulnerability by allowing all traffic, defeating the purpose of the deny-all policy and exposing the network to threats.Community Comment Notes
The community was divided between strict adherence to ITIL processes (Change Management) and practical engineering controls (Testing). Several users argued that you should never touch production without a ticket (User92, slackbot), while others emphasized that the test phase is what actually catches bugs (SHADTECH123, MarysSon). One commenter noted that while A is necessary, B is the specific control that prevents the outage described (Examplary). Another user pointed out that Change Management often relies on the technician providing evidence of testing, making B the foundational step for a valid request (Twphill).Exam Strategy
Always look for the option that provides technical verification when a question involves a configuration error causing downtime. If an option offers a way to simulate or validate the change safely (like staging or testing), it is usually superior to purely administrative options like documentation or approval.
Frequently Asked Questions
Is Change Management (A) wrong?
No, it is required, but it is not the technical control that prevents the specific outage described. Testing validates the configuration.
Why is adding Allow Any (D) wrong?
It defeats the security purpose of the firewall by permitting all traffic, leaving the enterprise exposed to external threats.
Related Analysis
Practice All SY0-701 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SY0-701 Practice Test →