A payment processor restarts the Snort process on its single FTD appliance every Sunday night and has no budget for a second device. The card-network link must stay up, and the appliance must block exploit traffic whenever inspection is available. Which inline configuration should the team choose for the interface pair?
Select an answer to reveal the explanation.
Short Explanation
Choose an inline set with fail-open so your link stays up while Snort restarts, like a bridge that remains open during repairs. Traffic passes without inspection during the restart, and blocking resumes as soon as inspection returns.
Full Explanation
A fail-open inline set is the best fit for this single-appliance deployment: when Snort restarts and inspection is unavailable, traffic can continue to pass, preserving the payment link; once inspection returns, the prevention policy can block detected exploit traffic. Fail-close is a legitimate choice where enforcement takes priority, but during a Snort restart it can interrupt traffic, violating the explicit requirement that the link stay up. An alert-only intrusion policy is commonly used for monitoring or tuning, and it preserves connectivity during restarts, but it reports rather than blocks exploits even when inspection is available. A high-availability pair with fail-open inline sets and a prevention policy can provide continuity and blocking, but it requires a second appliance, which the scenario rules out by specifying one device and no budget for another. Exam caveat: fail-open governs behavior when inspection is unavailable; it does not mean traffic is always permitted or replace an active prevention policy. Practical check: verify the interface pair’s fail-open setting and confirm the assigned intrusion policy is in prevention mode with the intended exploit rules enabled, then validate restart behavior in a maintenance window.