GSEC Network Security Devices Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable fail-open bypass on the IPS so that traffic is forwarded without inspection when the inspection engine is overwhelmed.

  Why it's wrong here

  Fail-open bypass would preserve availability but defeats the purpose of inline prevention: during overload, malicious packets would pass uninspected. The scenario asks to preserve inline prevention while reducing false drops, and bypass directly removes prevention exactly when it is most needed. It addresses the symptom (dropped legitimate traffic) by disabling the control, not by improving inspection capacity or tuning the engine.

• ✗

  Move the IPS to a passive TAP and rely on alerts to manually block offending sources at the firewall.

  Why it's wrong here

  A passive TAP eliminates inline prevention entirely; the device can only alert, not block. Manual firewall blocking is slow and cannot stop a fast-moving exploit or worm. While this removes false drops caused by inline overload, it also removes the core requirement of inline prevention. The question asks how to preserve inline prevention, so removing it from the traffic path is not a valid adjustment.

• ✓

  Tune the IPS inspection profile to match the segment's actual protocols and disable signatures for services not present on that segment.

  Why this is correct

  Overload often comes from inspecting irrelevant protocols and signatures, which consumes CPU and causes legitimate packets to be dropped. Profiling the segment and disabling unused signatures reduces processing load without removing inline prevention. This preserves enforcement while lowering false positives and false drops. It is the targeted, operationally sound adjustment because it aligns inspection scope with actual traffic rather than disabling protection.

• ✗

  Increase the IPS fail-closed timeout so that traffic is buffered longer during inspection spikes.

  Why it's wrong here

  Extending a timeout does not increase inspection throughput and can worsen latency and packet loss. If the engine is already saturated, longer buffering will overflow or delay sessions, causing application timeouts and more perceived drops. The root cause is inspection load, not timeout duration. This option misdiagnoses the bottleneck and would likely degrade performance further rather than reduce legitimate traffic drops.