All questions
Question 1
Attackers are suspected of using DNS queries as a command-and-control channel. The queries use changing subdomain values that do not match any known malicious string, but their length, timing, and frequency differ substantially from the organization's normal DNS behavior. The team accepts additional tuning work if it improves detection of previously unseen techniques.
Which detection approach most directly supports the stated goal?
- Apply anomaly-based detection to identify DNS behavior that departs from an established baseline. (correct answer)
- Apply signature-based detection only, because changing values are reliably matched by known indicators.
- Apply firewall port filtering only, because malicious DNS can be distinguished by its destination port.
- Apply availability monitoring only, because command-and-control activity primarily causes service outages.
Explanation: When a question describes behavioral clues — length, timing, frequency — rather than known malicious strings, it's signaling a detection methodology question. Your job is to match the evidence type to the right detection approach.
The scenario explicitly states that the subdomains don't match any known malicious string, which immediately rules out relying on signatures. What is observable is that the DNS traffic deviates from normal organizational behavior. Anomaly-based detection works by first establishing a baseline of normal activity, then alerting when observed behavior statistically departs from it — exactly what's needed here. A is correct because it directly leverages the available evidence (statistical deviation) and aligns with the team's stated willingness to invest in tuning, which anomaly systems require.
B is wrong because it contradicts the scenario's own premise. Signature-based detection matches traffic against a library of known indicators. The passage explicitly says the subdomain values don't match known malicious strings — signatures would be blind to this threat by design.
C is wrong because DNS tunneling and C2 over DNS use standard port 53, the same port as legitimate DNS traffic. Port filtering cannot distinguish malicious DNS queries from benign ones when they share the same destination port.
D is wrong because it mischaracterizes how C2 channels behave. Command-and-control traffic is typically low-volume and stealthy — designed specifically not to cause outages. Availability monitoring would almost certainly miss it entirely.
Study tip: When a scenario gives you behavioral anomalies (timing, frequency, size) but no known signatures, anomaly-based detection is almost always the answer. Signatures need prior knowledge; anomaly detection doesn't.
Question 2
An anomaly-based intrusion system assigns a score to each connection and alerts when the score exceeds a configured threshold. Analysts are overwhelmed by benign alerts and raise the threshold substantially, while all other settings and traffic remain unchanged.
Which outcome is the most likely tradeoff of this change?
- Both false positives and false negatives decrease because only stronger anomalies are evaluated.
- False positives likely decrease, but subtle malicious activity is more likely to become a false negative. (correct answer)
- False negatives likely decrease, but ordinary activity is more likely to generate false-positive alerts.
- Detection accuracy remains unchanged because thresholds affect alert priority rather than classification.
Explanation: Whenever you see a question about intrusion detection system (IDS) tuning, think in terms of the detection threshold's effect on the sensitivity-specificity tradeoff. Raising a scoring threshold means the system requires stronger evidence before firing an alert — this directly shifts which events get classified as malicious versus benign.
When analysts raise the threshold substantially, routine traffic that previously triggered alerts now falls below the cutoff, so false positives decrease — benign connections no longer generate unwanted alerts. However, this same higher bar means that subtle or low-intensity attacks, which produce anomaly scores just above the old threshold but below the new one, now go undetected. Those missed attacks become false negatives. This is exactly what answer B describes, making it correct.
Answer A is wrong because the two error types don't move in the same direction here. Raising the threshold reduces false positives but increases false negatives — they are inversely linked by the threshold position, not jointly reduced by it. Answer C has the logic exactly backwards: a higher threshold means less sensitivity, not more, so ordinary activity becomes less likely to generate false positives, and missed attacks become more common — the opposite of what C claims. Answer D is a common misconception: thresholds don't merely affect priority or display order, they directly determine whether an alert fires at all, so classification is absolutely affected.
A useful mental model: picture a sliding bar. Push the threshold right (higher), and you trade sensitivity for specificity — fewer false positives, more false negatives. Push it left, and the tradeoff reverses. This pattern appears frequently on security exams whenever IDS tuning or alert fatigue is discussed.
Question 3
A passive network sensor detects a malicious TCP session through a switch mirror port. It immediately sends forged reset packets to both endpoints. In testing, some sessions terminate, but in other cases the exploit payload reaches the server before the reset is processed.
How should this control be characterized?
- It is an inline IPS because any automated response converts passive monitoring into guaranteed prevention.
- It is a passive IDS only because an IDS cannot initiate any automated action after detecting traffic.
- It is an IDS with active response because reset injection may disrupt sessions but cannot reliably drop original packets. (correct answer)
- It is an inline IPS in fail-open mode because the exploit passes only when the bypass mechanism activates.
Explanation: When classifying a security device, the key question is whether it sits inline with traffic (able to physically block packets) or out-of-band (only observing copies of traffic). This distinction determines what guarantees the control can actually provide.
A sensor connected to a mirror/SPAN port receives a copy of traffic — the original packets travel independently to their destination. Because the sensor never touches the real traffic stream, it cannot intercept or drop anything. Sending forged TCP RST packets is an active response, but it's a race condition: the reset must reach the endpoints before the payload is processed. The scenario explicitly tells you the exploit sometimes lands first, confirming the mechanism is inherently unreliable. That makes this an IDS with active response — detection is passive, but the device attempts disruption through out-of-band injection. That's exactly what C describes.
A is wrong because automated response alone doesn't transform a sensor into a guaranteed prevention device. The physical architecture determines capability — a mirror-port sensor injecting RSTs is still racing against packets it cannot block. "Automated" ≠ "inline."
B is wrong because it overcorrects. An IDS can take automated actions (alerting, sending resets, triggering firewall rules); the defining characteristic of an IDS vs. IPS is topology and reliability of blocking, not whether it responds at all.
D is wrong because fail-open describes an inline device that passes traffic when its blocking mechanism fails. A mirror-port sensor is never inline to begin with — fail-open doesn't apply.
For the exam, remember: mirror port = out-of-band = cannot guarantee drops, regardless of what active responses the sensor initiates.
Question 4
A host agent records changes to protected system files, checks their hashes against an approved baseline, and alerts when an unauthorized modification occurs. It neither restores the files nor stops the process that changed them.
Which classification and detection goal best describe the agent?
- A host-based IPS focused on availability because any file-integrity alert automatically prevents service disruption.
- A host-based IDS focused on integrity because it detects unauthorized changes without directly preventing them. (correct answer)
- A network-based IDS focused on confidentiality because file hashes reveal outbound data-exfiltration attempts.
- A network-based IPS focused on authentication because baseline comparison blocks unauthorized user sessions.
Explanation: When classifying security tools, you need to ask two questions simultaneously: where does it operate (host vs. network) and what does it do (detect vs. prevent)? Then layer in the CIA triad goal it serves. This question tests all three dimensions at once.
The agent in the passage monitors files directly on the host, compares hashes to a trusted baseline, and issues alerts — but explicitly does not restore files or stop processes. That passive, observe-and-report behavior is the defining characteristic of an Intrusion Detection System (IDS). Because it targets unauthorized file modifications, its security goal maps to integrity — the "I" in CIA. That makes B the correct answer: a host-based IDS focused on integrity.
A is wrong on two counts. First, the agent doesn't block or prevent anything, so calling it an IPS is incorrect. Second, integrity — not availability — is the relevant CIA pillar when the concern is file modification. C misidentifies both the deployment location (this is host-based, not network-based) and the security goal; file hashes verify integrity, not confidentiality or exfiltration. D compounds multiple errors: it's host-based, not network-based; it detects rather than prevents, so "IPS" is wrong; and baseline comparison addresses integrity, not authentication.
A useful memory hook: IDS = alert only, IPS = act on it. If a tool watches and warns without intervening, it's always detection, never prevention. On exam questions like this, eliminate answers the moment you spot a mismatched IDS/IPS label — that single distinction usually cuts the options in half immediately.
Question 5
An organization terminates inbound TLS connections on a reverse proxy before forwarding unencrypted HTTP requests to an application server. A network IPS appliance cannot decrypt TLS. The goal is to inspect request content and block web exploits before they reach the application server.
Where should the IPS be placed to best meet this goal?
- Outside the perimeter firewall, where it can inspect encrypted requests before any filtering occurs.
- On a mirror port beside the application server, where it can observe plaintext requests without adding latency.
- Between internet clients and the reverse proxy, where it can block attacks before TLS termination.
- Inline between the reverse proxy and application server, where it can inspect and block plaintext requests. (correct answer)
Explanation: When you see a question about IPS placement alongside TLS termination, the core concept to anchor on is where plaintext traffic exists. An IPS that cannot decrypt TLS is blind to encrypted payloads — it can only inspect what it can actually read. Your job is to find the point in the network where traffic is both decrypted and still blockable before reaching the target.
In this scenario, the reverse proxy terminates TLS, which means everything downstream of that proxy flows as unencrypted HTTP. Placing the IPS inline between the reverse proxy and the application server (D) satisfies both requirements: the traffic is plaintext (so the IPS can inspect it) and the IPS is inline (so it can actively block malicious requests before they hit the application server). This is the correct placement.
A is wrong because traffic between internet clients and the perimeter firewall is still TLS-encrypted — the IPS can't read it, making inspection impossible. C has the same fundamental flaw: placing the IPS between clients and the reverse proxy means it's still upstream of TLS termination, so it sees only ciphertext. B sounds appealing because a mirror port does expose plaintext traffic, but "observe without adding latency" is the giveaway — a passive mirror port lets traffic pass regardless. The IPS can detect but cannot block, which directly contradicts the goal of stopping exploits before they reach the application server.
As a study tip, remember this rule: inspect requires plaintext, block requires inline. Any answer that offers only one of these two properties will fall short when the goal demands both.
Question 6
A security team connects a network sensor to a switch's mirror port. The sensor identifies a known data-exfiltration pattern in an outbound session and immediately generates a high-severity alert. Packet capture later confirms that the entire session reached the external server.
Which conclusion best explains why detection succeeded but prevention did not?
- The sensor was signature-based, so it could classify the session only after every packet had left the network.
- The sensor was out of band, so it could observe mirrored traffic without directly stopping packets on the original path. (correct answer)
- The sensor was anomaly-based, so it could report unusual behavior but was technically unable to initiate any response.
- The sensor was positioned outbound, so it could inspect external attacks but could not enforce controls on internal sessions.
Explanation: When you see a question about why a security device detected something but couldn't prevent it, your first instinct should be to think about deployment architecture — specifically, whether the device sits in the path of traffic or merely observes a copy of it.
A mirror port (also called a SPAN port) sends a duplicate of all traffic to the connected sensor, while the original packets continue flowing uninterrupted on their actual path. This is called an out-of-band (or passive) deployment. Because the sensor only receives copies, it has no mechanism to drop, block, or modify the real packets — it can only analyze and alert. That perfectly explains the scenario: detection succeeded because the signature matched the copied traffic, but prevention failed because the sensor was never in a position to intercept anything.
A is wrong because signature-based detection doesn't require all packets to arrive before classification — many signatures trigger mid-session. The real issue is architecture, not detection method. C is wrong for a similar reason: the limitation described isn't about anomaly-based detection being incapable of response. Even anomaly-based systems can be deployed inline and block traffic; the problem here is physical placement, not detection methodology. D is wrong because "outbound positioning" isn't a real architectural limitation that prevents enforcement on internal sessions — this option conflates traffic direction with deployment mode.
As a study tip, remember this pairing: inline = can block, out-of-band = can only observe. On exam questions, watch for clues like "mirror port," "SPAN port," or "tap" — those always signal a passive, detection-only sensor.
Question 7
A network IDS is installed where it sees client-to-server traffic, but return traffic follows a different route and never reaches the sensor. The IDS reports repeated connection attempts yet does not identify an exploit whose signature depends on reconstructing a complete bidirectional session.
Which explanation best accounts for the missed detection?
- Asymmetric visibility prevented complete session reconstruction, limiting detection even though some malicious traffic was observed. (correct answer)
- The IDS became an IPS when it observed connection attempts, so it ignored responses that it was not authorized to block.
- Signature detection requires installation on each endpoint, so a network sensor cannot reconstruct bidirectional sessions.
- Return traffic is irrelevant to network detection, so the missed exploit proves that its signature was incorrectly written.
Explanation: Whenever you see a question about network intrusion detection, think about what the sensor can actually see. A network IDS detects threats by inspecting traffic passing through a specific point — and if it only sees half of a conversation, it may not have enough information to fire certain signatures.
This scenario describes asymmetric routing, where client-to-server packets traverse the sensor but server-to-client responses take a different path entirely. Some exploit signatures — particularly those involving multi-stage attacks or protocol handshakes — require the IDS to reconstruct a complete bidirectional TCP session. Without both halves, the sensor cannot assemble the full context, so the exploit goes undetected even though the outbound connection attempts were observed. That reasoning confirms A as correct: asymmetric visibility is the precise technical cause of the missed detection.
B is wrong because an IDS does not become an IPS simply by observing connection attempts — they are architecturally distinct systems, and the explanation invents a fictional authorization logic that doesn't exist. C is wrong because it overstates the limitation; network sensors can reconstruct bidirectional sessions when they see both directions of traffic — the issue here is routing topology, not an inherent architectural impossibility. D is wrong because return traffic is absolutely relevant to many detection techniques; dismissing it as "irrelevant" contradicts how session-aware signature matching works, and blaming a poorly written signature ignores the routing problem entirely.
For the exam, remember this pattern: asymmetric routing = incomplete session visibility = missed session-dependent signatures. Any time a question mentions traffic following different paths, think asymmetric routing first.
Question 8
A firewall permits inbound HTTPS to a public web server as required by policy. An inline security appliance then detects a known exploit within an otherwise valid HTTPS request after decryption and discards the request.
Which statement best distinguishes the two controls in this scenario?
- The firewall failed because permitting a connection necessarily requires permitting every request carried by that connection.
- The inline appliance functions only as an IDS because the firewall had already authorized the HTTPS connection.
- The firewall and appliance perform identical detection, but only the firewall is positioned to discard traffic.
- The firewall permits the required service, while the IPS blocks malicious content within an allowed connection. (correct answer)
Explanation: When a question contrasts two security controls, your job is to identify what layer each operates at and what decision each is capable of making — not just whether they block or allow traffic.
A firewall operating at the network/transport layer makes coarse-grained decisions: does this protocol, port, and IP combination match policy? Permitting HTTPS to a public web server is exactly that — a policy-based service decision. It says nothing about the content of that traffic. An Intrusion Prevention System (IPS), by contrast, operates at the application layer. After decryption, it inspects the actual payload for malicious patterns — exploit signatures, malformed requests, known attack sequences — and can actively discard dangerous traffic even within an otherwise permitted connection. That layered distinction is precisely what answer D captures: the firewall permits the required service, and the IPS blocks malicious content within that allowed connection. Both controls do their jobs correctly; they simply operate at different layers with different inspection capabilities.
Answer A is wrong because it describes a false limitation — firewalls permitting a service absolutely do not surrender control over individual requests. Layered security exists precisely because connection-level and content-level decisions are separate. Answer B incorrectly conflates IDS and IPS. An IDS only detects and alerts; an IPS detects and blocks. Since the appliance actively discards the request, it is functioning as an IPS, not an IDS. Answer C is wrong because the two devices perform fundamentally different types of detection — port/protocol versus deep packet inspection — and both can discard traffic within their respective scopes.
As a study tip, remember: firewall = service-level gatekeeper; IPS = content-level enforcer. Questions will often bait you into thinking one replaces the other — they don't; they complement each other.
Question 9
An organization places an IPS inline between its internet firewall and internal network. Because uninterrupted connectivity is the primary business requirement, the appliance uses a hardware bypass that activates if the IPS loses power.
What is the most likely security consequence when the bypass activates?
- Traffic stops until the IPS recovers, preserving inspection at the cost of network availability.
- Traffic is redirected to the firewall, which automatically assumes the IPS inspection and blocking functions.
- Traffic continues without IPS inspection, preserving connectivity while temporarily removing that prevention layer. (correct answer)
- Traffic remains fully inspected, but detected attacks generate alerts rather than being blocked by the IPS.
Explanation: When you see a question about inline security appliances, focus on what "inline" actually means: traffic physically passes through the device. That architecture creates a critical design tension — if the device fails, what happens to the traffic flow?
A hardware bypass is a fail-open mechanism. When the IPS loses power, the bypass circuit creates a direct electrical connection between the two network interfaces, essentially turning the appliance into a wire. Traffic flows through unimpeded — but uninspected. This makes C correct: connectivity is preserved at the cost of losing that prevention layer. The business requirement (uninterrupted connectivity) is satisfied, but the security control temporarily disappears.
A describes a fail-closed behavior, where the device drops all traffic on failure. Some high-security environments prefer this, but it's the opposite of what a hardware bypass does — and it would violate the organization's stated priority of uninterrupted connectivity.
B is a common misconception. Firewalls and IPS devices are distinct tools. A firewall performs packet filtering and stateful inspection based on rules, but it doesn't automatically inherit deep-packet inspection or signature-based attack blocking from a failed IPS. No such handoff mechanism exists by default.
D describes a detection-only (IDS) mode, where the device monitors but doesn't block. That's a valid operating mode, but it still requires the device to be powered and processing traffic — a bypassed, unpowered device does neither.
The key study tip: memorize the fail-open vs. fail-closed distinction. Fail-open preserves availability but removes security controls; fail-closed preserves security posture but disrupts availability. Exam questions will test which behavior matches a given design goal.
Question 10
A hospital wants an IPS to block attacks against a critical clinical application, but false blocking could interrupt patient care. The hospital has limited knowledge of the application's normal traffic and wants eventual prevention rather than permanent alert-only monitoring.
Which deployment strategy best balances the stated goals?
- Enable all available IPS signatures in blocking mode immediately, accepting the operational risk in exchange for the strongest possible protection from day one.
- Deploy a passive IDS permanently and never transition to inline prevention, because critical clinical applications are inherently incompatible with any blocking capability.
- Begin with alert-only monitoring, tune detections using observed traffic, then block selected high-confidence attacks. (correct answer)
- Suspend all detection during the baseline period to avoid alert noise, then automatically block every connection that deviates from the resulting average throughput.
Explanation: When questions involve deploying intrusion detection or prevention systems in sensitive environments, focus on three competing demands: security effectiveness, operational risk, and the maturity of your traffic baseline. A good strategy must satisfy all three over time, not just one immediately.
The approach described in C — starting with alert-only (passive) monitoring, tuning signatures against real observed traffic, then selectively enabling blocking for high-confidence detections — is the textbook IDS-to-IPS transition methodology. It directly addresses every constraint in the scenario: the hospital lacks baseline knowledge (so monitoring first builds that knowledge), false positives threaten patient care (so tuning before blocking minimizes them), and the goal is eventual prevention (so a permanent alert-only posture isn't the endpoint). This phased approach is how mature security programs responsibly deploy inline prevention.
Choice A ignores the knowledge gap entirely. Enabling all signatures in blocking mode immediately maximizes both protection and false positive risk — a dangerous gamble when false blocks could disrupt patient care. Choice B misrepresents the tradeoffs by claiming clinical environments are inherently incompatible with blocking. This is false; they require careful deployment, not permanent avoidance. Blocking is achievable once you have sufficient confidence in your detections. Choice D is doubly flawed: suspending detection during baselining eliminates any security coverage during a vulnerable window, and then auto-blocking every deviation from average throughput would generate catastrophic false positives on any complex clinical application.
As a study tip, watch for scenarios that describe a phased or graduated deployment — security questions in operational contexts often reward the answer that balances risk reduction over time rather than maximizing any single metric on day one.