How to Prevent Production Outages from Firewall ACL Changes?
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 question tests whether candidates can differentiate between procedural compliance and hands-on technical safeguards, with the common trap being selecting the 'correct paperwork' over the action that actually prevents system downtime.
This question distinguishes between administrative governance and technical validation when modifying firewall rules. The community consensus strongly favors staging changes in a non-production environment to catch misconfigurations before they disrupt live services.
Many candidates incorrectly choose Option A (Change Management) because it is a mandatory organizational process. However, documenting and approving a change does not technically verify its functionality; without pre-deployment testing, even fully approved changes can inadvertently block critical traffic.
Community Discussion (23 comments)
Examplary
👍 15
Frankly it should be both A and B. Submitting it to change management does not prevent the issue if it isn't caught by change management, and testing it in non-prod would but also shouldn't be done without a request to change management. It's a different question than the previous one regarding change management: Yes the technician SHOULD put in a change management request first, but that's not the question, the question is what would prevent it and the change management request does not prevent an issue, rather it lets everyone know what is happening and provides a backout plan if issues come up. That still does not PREVENT the issue though so /shrug
SHADTECH123
👍 13
Selected: B
Testing the policy in a non-production environment allows for the identification and resolution of any unforeseen issues, such as servers becoming unreachable, before implementing the policy in the production network. This ensures that any potential impact on business operations is minimized.
slackbot
👍 1
Selected: A
you got this wrong. change management is not about documenting, it is about evaluating the request. if properly reviewed - it will not be allowed. and we are not talking about who does their work well and not - we cannot speculate if change management fails and this is approved. change manamgement (A) should be correct
MarysSon
👍 1
Selected: B
B is the best answer. A change request can be submitted and approved, but problems will arise if the approved change is not applied correctly. Testing the change in a non-production environment will reveal errors before they can affect production.
prabh1251
👍 1
Selected: B
After successful testing and change approval, apply the policy in the production environment.
Andyhung1303
👍 1
Selected: A
Maybe i guess
TECHBOSS
👍 1
Selected: B
Answer: B Procedurally "A" should and needs to occur first, However those 2 steps by themselves won't prevent this Even though those changes will still have to be tested in a non-production environment. Even if the CAB approves the request, ONLY seeing it in action will let anyone know that it will interfere with servers. Testing is the ACTION that will prevent it.
darpanne
👍 1
Selected: B
Testing the policy in a non-production environment allows the technician to identify and fix any unintended consequences before implementing the rule in the production network. This ensures the servers and critical services remain reachable while maintaining security.
MaxiPrince
👍 1
Selected: B
. Testing the policy in a non-production environment before enabling the policy in the production network
MaxiPrince
👍 1
Selected: B
Test policy in no prod environment
43a41d4
👍 1
Selected: B
Since the question mentions that the technician has already updates the policy, we can assume that he got approval first to implement the solution. But, for a good technician to perform well and avoid any issues, he should test the changes in a non-production environment. Both questions A and B are good answers, but B est is the best one in this case.
3dk1
👍 1
Selected: A
B is something that should have been done. HOWEVER, if we documented the new change and submitted a change request this issue could have been prevented as well.
Bito808
👍 2
Selected: A
The answer is "A"! You will get fired if you did not put in a change request before testing or implementing anything! It needs to be documented and approved FIRST! This will determine if you need equipment, resources, special access, or if there's even budget!
Bito808
👍 1
The answer is "A"! You will get fired if you did not put in a change request before testing or implementing anything! It needs to be documented and approved FIRST! This will determine if you need equipment, resources, special access, or if there's even budget!
User92
👍 1
Selected: A
Should be A, check Question #30
User92
👍 2
Selected: A
Change Management Processes: Schedule maintenance windows, Thorough backout plans, Consistent “testing” post-implementation
Gigz_77
👍 1
Selected: A
A. Documenting the new policy in a change request and submitting the request to change management
linuxer
👍 1
Selected: A
change management request will include testing the updated policy before implementing it
Twphill
👍 2
Answer A: Before any changes are made, the request should be submitted to Change Management. As part of Change Management, the change will be tested in a non-production environment. This is not the responsibility of the technician that decided to make the change. His job is to request the change.
tamdod
👍 4
Shouldn't a change management be submitted before changing the firewall? That way other people have a change to look at it, and more than likely someone would have caught the problem before it occurred.
TrebleSmith
👍 1
D would work in a chaotic way lol
dbrowndiver
👍 2
Selected: B
By testing the policy in a non-production environment, the technician can identify potential issues, such as legitimate traffic being blocked, before applying the changes to the production network. This approach allows for adjustments and troubleshooting in a safe setting, minimizing the risk of disruption to business operations.
Zach123654
👍 2
Selected: B
GPT!!!
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Core Concept: Procedural Governance vs. Technical Validation
Modifying firewall Access Control Lists (ACLs) requires strict adherence to both IT governance frameworks and technical best practices. Adding a "deny any" rule at the end of an ACL is a standard security hardening measure, but it will immediately drop all traffic that lacks a preceding explicit permit statement. If necessary communication paths for company servers are missing, adding this rule will cause a widespread outage.Why Option B is Correct
Testing the policy in a non-production environment (or staging/test network) is the definitive technical safeguard. It allows administrators to replicate production traffic patterns, verify connectivity requirements, and identify missing allow rules before deployment. As highlighted by multiple community members, this hands-on validation step directly prevents unintended service disruptions, making it the most accurate answer to "which action would prevent this issue?"Why the Other Options Are Incorrect
- Option A (Change Management): While submitting a change request is a required procedural step, it is an administrative gatekeeping function. Change approval does not equate to technical verification; an approved change can still fail catastrophically if never validated in a test environment.
- Option C (Disable IPS Signatures): Intrusion Prevention Systems operate at Layer 3/4 or 7 and inspect payload/signatures, but they do not override fundamental ACL permit/deny logic. Disabling them would not restore reachability blocked by a blanket deny rule.
- Option D (Include an "allow any" above "deny any"): This completely negates the security posture of the firewall. Placing an overly permissive rule above a restrictive one creates a massive vulnerability, allowing unauthorized traffic while technically fixing the reachability issue.
Community Consensus
Candidates frequently debate between A and B, recognizing that both are part of a proper workflow. However, as noted by users emphasizing practical implementation, change management handles risk assessment and scheduling, whereas staging/testing handles technical correctness. CompTIA rewards the candidate who identifies the direct technical prevention method over the administrative prerequisite.Official Reference
- https://www.comptia.org/training/books/sy0-701-comptia-security-study-guide-eighth-edition
- NIST SP 800-53 Rev. 5, SI-7: Function Security
- ITIL 4 Practice: Change Enablement
- CompTIA Security+ SY0-701 Exam Objectives: 1.4 & 4.2
Exam Strategy
When CompTIA questions ask how to "prevent," "verify," or "validate" a technical outcome, prioritize the option that involves hands-on testing, simulation, or configuration review over purely administrative or documentation-based answers. Remember that procedures like change management manage risk and schedule work, but they do not replace the need for technical validation in staging environments.
Related Analysis
Practice All SY0-701 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SY0-701 Practice Test →