- After a laptop theft, staff review badge-reader logs to see who entered the room overnight. In this use, what type of control are the logs?
Answer: Detective
Reviewing logs after an event identifies what happened and who did it, which makes it a detective control. The badge reader can act as a preventive control at the door, but here the logs are used only to investigate after the theft.
- When the two activities are evaluated independently, which classification is most accurate?
Answer: The access review is detective, and role removal is corrective.
When classifying security controls, you need to ask a simple question about timing: does this action find a problem, prevent one from happening, or fix one that already exists? Detective controls identify issues after they've occurred; preventive controls stop issues before they occur; and corrective controls remediate a discovered problem.
In this scenario, the quarterly access review scans existing permissions and surfaces a policy violation — an employee who already has excessive access. That discovery function is the definition of a detective control. It didn't stop the over-provisioning from happening; it caught it after the fact. The role removal that follows is a direct response to the finding, eliminating the excessive privilege and restoring a compliant state — that's a corrective control. Together, they form the classic detect-then-correct pairing, making B the right answer.
A is wrong because it swaps the labels. Calling the access review "preventive" mischaracterizes it — preventive controls act before a violation, like requiring approval workflows before granting access in the first place. Labeling role removal "detective" is equally off; it doesn't discover anything, it fixes something.
C reverses both controls entirely. Corrective comes after detection, so it cannot be what the review does; and role removal cannot be preventive because it's responding to an existing problem, not blocking a future one.
D incorrectly classifies role removal as detective. Removing a role produces no new information — it's a remediation action, not a discovery action.
Your study tip: memorize the sequence prevent → detect → correct as a timeline. If a control acts before an event, it's preventive; if it finds an event, it's detective; if it fixes the aftermath, it's corrective.
- What is the best description of the effect of this configuration change?
Answer: The gateway changes from detective to preventive while retaining a detective function.
When security controls are described, exams often test your ability to classify them as preventive (blocks threats before they occur), detective (identifies and records threats), or corrective (remedies damage after the fact). A single system can perform multiple roles simultaneously, and configuration changes can shift which roles are active.
In the original setup, the gateway only alerted on suspicious requests — it detected them but let them through. That's a purely detective function. After reconfiguration, it rejects matching requests before they reach the backend, which is the definition of a preventive control — stopping the threat from occurring. Critically, it still generates the same alerts and audit records, meaning the detective function remains intact alongside the new preventive one. That makes B the correct answer: the gateway transitions from detective to preventive while retaining its detective capability.
A is wrong because "corrective" means restoring a system after harm has occurred (think backups or incident response), not blocking or logging requests. Recording rejections doesn't make a control corrective.
C reverses the direction entirely — the original configuration was never preventive, so it can't transition from preventive to corrective. This distractor relies on you confusing the before and after states.
D is wrong because the order of operations (pattern matching before rejection) doesn't lock a control into being purely detective. Detection can be a step within a preventive process; what matters is the outcome — blocking the request makes it preventive.
A useful tip: always ask what happens to the threat — if it's stopped, that's preventive; if it's only recorded, that's detective; if damage is undone, that's corrective.
- Which set satisfies the required preventive, detective, and corrective functions, respectively?
Answer: Application allowlisting (blocks unauthorized execution); endpoint behavior alerts (identifies suspicious activity); reimaging from a trusted baseline (restores the endpoint)
When tackling endpoint security design questions, anchor yourself to the classic preventive → detective → corrective control sequence. Preventive controls stop a threat before it causes harm, detective controls identify threats that slip through, and corrective controls restore normal operations after a compromise.
With that framework, map each tool to its true function: application allowlisting is preventive because it blocks unauthorized executables from running in the first place — the attack can't begin. Endpoint behavior alerts are detective because they monitor running processes and flag anomalous activity that has already started occurring. Reimaging from a trusted baseline is corrective because it wipes and restores a compromised machine to a known-good state after an incident.
Answer D arranges these tools in exactly the right order — allowlisting (prevent), behavior alerts (detect), reimaging (correct) — satisfying all three requirements.
A fails because it swaps the detective and corrective controls. Reimaging is listed second as if it's the detective function, and behavior alerts third as if corrective, which reverses their actual roles entirely.
B leads with behavior alerts as the preventive control, which is wrong — alerts don't block anything, they only notify. It also ends with log retention as a corrective control, but storing records doesn't restore a system; it's an administrative/detective function.
C lists reimaging first as the preventive control, which makes no sense — you can't restore a system before it's compromised to prevent the compromise.
Study tip: Memorize the triad as block → find → fix. On exam questions, watch for distractors that place reactive tools (alerts, reimaging) in the preventive slot — that's the most common trap.
- Which statement best classifies the monitoring and recovery capabilities?
Answer: Backup monitoring is detective, while restoring the verified backup is corrective.
When classifying security controls, keep three categories in mind: preventive controls stop incidents before they happen, detective controls identify that something has gone wrong, and corrective controls restore normal operations after an incident. This question tests whether you can correctly map real-world actions to those categories.
The monitoring service watches for missing or undersized backups — it doesn't stop ransomware from striking, but it detects anomalies after they occur. That makes it a detective control. Restoring the verified backup is a direct response to the ransomware incident, returning the system to a known-good state — a textbook corrective control. Answer B captures both of these correctly.
Answer A misclassifies monitoring as preventive. The monitoring service doesn't block anything; it raises an alert after detecting a problem. Calling it preventive confuses alerting with blocking. Answer C flips both labels entirely — calling monitoring corrective (it doesn't fix anything, it detects) and restoration preventive (you can't prevent an incident that already happened). Answer D correctly identifies monitoring as detective but then mislabels restoration as preventive. Restoring a backup after a ransomware attack is clearly a recovery action, not a measure taken in advance to prevent harm.
A useful memory trick: ask yourself when the control acts. Before the incident? Preventive. During or right after, to recognize it? Detective. After, to fix damage? Corrective. On exams, distractors often swap "detective" and "preventive" — always anchor your classification to the timing and purpose of the control, not just its technical nature.
- Which classification best describes the gateway's two relevant functions?
Answer: Rejection is preventive, while recording and later log analysis are detective.
When classifying security controls, always ask: does this action stop a bad event from happening, or does it identify/record that one occurred? That distinction separates preventive from detective controls — and it's exactly what this question tests.
The email gateway rejects the malicious message before it ever reaches the recipient's inbox. Because the harm is blocked before it occurs, rejection is a preventive control. Then, the system records the sender, recipient, and attachment hash, and analysts later search those logs to uncover related campaigns. Both recording and log analysis happen after the threat event is identified — they surface information about what occurred so analysts can investigate further. That makes them detective controls. This confirms C as the correct answer.
A is wrong because it swaps the labels entirely — rejection is not corrective (corrective controls restore systems after damage), and logging is not preventive (it doesn't stop anything).
B is wrong in both halves. Rejection isn't detective — it doesn't simply observe the threat, it actively blocks it. And logging/analysis isn't corrective, because no remediation or restoration takes place.
D is partially right (rejection is correctly labeled preventive), but it misclassifies logging and analysis as corrective. Corrective controls fix damage that has already occurred — think quarantining an infected host or restoring from backup. Logging and searching logs only identify patterns; they don't remediate anything.
Study tip: Memorize the three-control framework: preventive stops it, detective finds it, corrective fixes it. Many exam questions hinge on distinguishing detective from corrective, so watch for whether an action is observing/recording versus actively restoring.
- What is the most appropriate primary classification of the decoy server in this deployment?
Answer: Detective, because interaction with it exposes potentially malicious activity.
When classifying security controls, always anchor your thinking to the primary purpose of the mechanism: does it prevent, detect, or correct? A decoy server — commonly called a honeypot — is purpose-built to attract and expose adversaries, making classification straightforward once you apply this framework.
The server described has no production function, meaning it cannot prevent anything from happening to real systems. Its entire value comes from what happens when someone interacts with it: that interaction immediately signals potentially malicious behavior and is forwarded to analysts as a high-priority alert. This is the textbook definition of a detective control — it identifies and surfaces suspicious activity so humans can respond. Answer C is correct.
A is wrong because the server doesn't block, filter, or deter access to production assets. The passage explicitly states it does not block connections to production systems. A preventive control stops an attack before harm occurs; this system lets attackers roam freely and simply watches them. B and D are both wrong for the same structural reason: corrective controls act after an incident to restore normal operations or remove unauthorized access. The honeypot doesn't remediate anything — it doesn't patch systems, revoke credentials, or kick out intruders. Choosing B or D reflects a common trap: confusing "the analysts could correct things afterward" with the control itself being corrective.
Study tip: On security exams, always classify the control by what it does automatically, not what humans might do in response to it. A honeypot detects; the analyst who later responds corrects.
- Which option correctly classifies the three actions in the order presented?
Answer: Detective, corrective, preventive
When you see a question like this on a security exam, think about the security control lifecycle: detective controls identify that something happened, corrective controls fix the damage, and preventive controls stop future occurrences. The key is mapping each action to its timing and purpose relative to an incident.
Walking through the passage in order: analysts searching logs for attack indicators are looking for evidence of what already occurred — that's a detective action. Administrators rebuilding the server from a trusted image are restoring normal operation after harm was done — that's a corrective action. Engineers adding an input-validation rule that rejects the exploit pattern are blocking future attacks before they reach the application — that's a preventive action. This maps perfectly to Answer A: Detective, Corrective, Preventive.
Answer B (Corrective, Detective, Preventive) swaps the first two. Log analysis isn't fixing anything — it's discovering what happened, which is detective, not corrective. Answer C (Detective, Preventive, Corrective) misclassifies the server rebuild. Rebuilding doesn't stop future attacks; it restores functionality, making it corrective, not preventive. Answer D (Preventive, Corrective, Detective) reverses the logic entirely — log analysis happens after an incident and identifies it, which is the definition of detective, not preventive.
A reliable memory trick: think "D-C-P" as the incident timeline — you Detect it first, Correct the damage second, then Prevent recurrence. If the action looks backward (logging, auditing, alerting), it's detective. If it looks forward (patching, filtering, training), it's preventive. If it restores, it's corrective.
- A firm wants a preventive control that stops staff from copying data to USB drives. Which measure best fits?
Answer: Block USB storage through endpoint policy
Blocking USB storage stops the copying before any data leaves, so it is preventive. Alerting on insertion can seem protective, but it only reports the event. The data can still be copied.
- An inline device drops packets that match an attack signature before they reach the server. What is its primary control type?
Answer: Preventive: it blocks the attack before harm
Dropping malicious packets before they reach the server stops the attack, so the device is a preventive control. It does use signature matching, but a detective control only reports an attack. This device stops it.
- When the agent's functions are classified separately according to their immediate purposes, which classification is most accurate?
Answer: The alert is detective; process termination and registry restoration are corrective.
When classifying security controls, you need to ask one precise question for each function: what is its immediate purpose at the moment it acts? The three categories are preventive (stops an incident before it occurs), detective (identifies and reports an incident as it happens), and corrective (repairs damage after an incident is confirmed).
In this scenario, the alert fires because the unauthorized modification has already occurred — the process already touched the registry keys. The alert's immediate purpose is to notify someone that a security event was detected, making it detective. Process termination stops the ongoing threat and registry restoration repairs the damage caused — both actions respond to a confirmed incident with the goal of undoing harm, which is the definition of corrective. That reasoning confirms A as the correct answer.
B misclassifies the alert as preventive, but prevention happens before a threat materializes — an alert cannot prevent what has already triggered it. C calls the alert corrective, which would mean the alert itself repairs something; alerts report, they don't fix. It also labels termination and restoration as preventive, but by the time these actions run, the incident has already occurred. D is the most tempting distractor — it correctly identifies the alert as detective but calls termination and restoration preventive. The trap here is confusing "stopping further damage" with "preventing the original incident." Corrective controls can limit ongoing harm without being preventive.
As a study tip, always anchor your classification to timing and purpose: before the event = preventive, during/discovery = detective, after/repair = corrective.
- Which classification best reflects the primary function of the lockout and the notification?
Answer: The lockout is preventive, and the notification is detective.
When you see a question about security control classifications, your first move should be to map each control to its timing relative to an attack: preventive controls stop harm before it occurs, detective controls identify that something is happening or has happened, and corrective controls fix or recover after an incident is confirmed.
Apply that lens here. The account lockout triggers after five failed attempts — it kicks in during an ongoing attack and blocks further attempts from succeeding. Because it stops the threat (unauthorized access) from materializing, it is preventive. The SOC notification, meanwhile, doesn't stop anything on its own — it alerts a human analyst that suspicious activity is occurring, which is the definition of detection. That makes D — lockout is preventive, notification is detective — the correct answer.
A is wrong on both counts: calling the lockout "detective" misreads its purpose entirely. The lockout doesn't observe or report the attack; it actively stops it. Labeling the notification "corrective" is also wrong because no remediation action is taken by the notification itself — it simply raises awareness.
B incorrectly labels the lockout "corrective," implying something has already gone wrong and needs fixing. The lockout is proactive, not reactive to damage. It also misclassifies the notification as "preventive," but a passive alert doesn't prevent anything by itself.
C swaps the two correctly identified categories — it gets the lockout right (preventive) but calls the notification "corrective," which overstates what an alert does. Notifying someone is not the same as fixing a problem.
A useful memory hook: P-D-C maps to Stop it → See it → Fix it. When a control blocks, think preventive; when it reports, think detective.
- A corrective control limits damage and restores normal operation after an incident. Which is an example?
Answer: Quarantining malware and restoring a clean file
Quarantining malware and restoring a clean file contains the damage and returns the system to normal, which is corrective. Signature scanning is tempting because it deals with malware, but it only detects the malware.
- How should the hash comparison and automated replacement be classified?
Answer: Hash comparison is detective, and automated replacement is corrective.
When classifying security controls, you need to ask a simple question about timing and purpose: Does the control stop something bad from happening (preventive), detect that something bad has occurred (detective), or fix the damage after it occurs (corrective)?
In this scenario, the file-integrity monitor continuously compares current file hashes against known-good approved hashes. It isn't blocking any change from happening — instead, it discovers that a change already occurred and raises an alert. That makes it a detective control. Once the mismatch is flagged, the automated workflow kicks in and replaces the corrupted file with a trusted copy — actively undoing the damage. That's the definition of a corrective control. Answer A is correct.
Answer B flips the logic on hash comparison, calling it preventive. Preventive controls stop threats before they occur — like access controls or encryption. Hash comparison runs after a file changes, so it cannot be preventive. Answer C gets both labels wrong: calling hash comparison "corrective" implies it fixes something, but it only identifies a problem. Calling automated replacement "preventive" suggests it stops a future attack, but its job is to repair current damage. Answer D correctly identifies hash comparison as detective but misclassifies replacement as preventive — the replacement isn't stopping a future incident, it's responding to an existing one.
A quick memory anchor: Detective = discovers, Corrective = repairs. On the exam, automated response actions that restore a system to a known-good state are almost always corrective, not preventive — don't let the word "automated" mislead you into thinking speed equals prevention.
