- Which classification and detection goal best describe the agent?
Answer: A host-based IDS focused on integrity because it detects unauthorized changes without directly preventing them.
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.
- Which deployment strategy best balances the stated goals?
Answer: Begin with alert-only monitoring, tune detections using observed traffic, then block selected high-confidence attacks.
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.
- Which statement best distinguishes the two controls in this scenario?
Answer: The firewall permits the required service, while the IPS blocks malicious content within an allowed connection.
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.
- What is the most likely security consequence when the bypass activates?
Answer: Traffic continues without IPS inspection, preserving connectivity while temporarily removing that prevention layer.
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.
- How should this control be characterized?
Answer: It is an IDS with active response because reset injection may disrupt sessions but cannot reliably drop original packets.
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.
- Where should the IPS be placed to best meet this goal?
Answer: Inline between the reverse proxy and application server, where it can inspect and block plaintext requests.
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.
- Which detection approach most directly supports the stated goal?
Answer: Apply anomaly-based detection to identify DNS behavior that departs from an established baseline.
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.
- Which conclusion best explains why detection succeeded but prevention did not?
Answer: The sensor was out of band, so it could observe mirrored traffic without directly stopping packets on the original path.
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.
- Which explanation best accounts for the missed detection?
Answer: Asymmetric visibility prevented complete session reconstruction, limiting detection even though some malicious traffic was observed.
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.
- Which outcome is the most likely tradeoff of this change?
Answer: False positives likely decrease, but subtle malicious activity is more likely to become a false negative.
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.
