Sample questions
Security Incident ResponseDifficulty 1
A security team writes and rehearses an incident response plan long before any real incident happens. What is the main reason for doing this preparation work in advance?
- aIt sets roles and escalation paths in advance, so responders act fast and consistently under pressure.✓
- bIt guarantees that no security incident will ever happen again once the plan is approved by management.
- cIt replaces the need for monitoring or logging, since a written plan alone can detect intrusions.
- dIt exists only to satisfy an annual audit checklist and has little effect on how a real incident unfolds.
Explanation:Preparation is a distinct phase of incident response: defining roles, contacts, and decision authority ahead of time removes ambiguity during a stressful, time-pressured event. A plan does not prevent incidents or detect them by itself.
Security Incident ResponseDifficulty 1
A typical incident response lifecycle is described as an ordered set of phases. Which sequence best reflects that order?
- aRecovery, then detection, then containment, then preparation.
- bPreparation, detection and analysis, containment/eradication/recovery, then lessons learned.✓
- cEradication, then preparation, then lessons learned, then detection.
- dLessons learned first, followed by containment, then preparation, then detection.
Explanation:The widely taught lifecycle starts with preparation (before anything happens), moves to detection and analysis once something looks wrong, then containment/eradication/recovery to stop and clean up the incident, and closes with a lessons-learned review that feeds back into preparation.
Security Incident ResponseDifficulty 2
A monitoring tool fires an alert every few minutes for a pattern that, after investigation, almost always turns out to be harmless. Why does this matter for incident response?
- aIt has no practical effect, since every alert should be treated with exactly the same urgency regardless of history.
- bIt means the underlying monitoring should be turned off entirely, since alerts that are usually harmless provide no value.
- cIt causes alert fatigue, making responders more likely to dismiss or delay attention to a real incident hidden among the noise.✓
- dIt automatically qualifies as a security incident on its own, simply because an alert fired repeatedly.
Explanation:High-noise, low-signal alerts train responders to tune them out (alert fatigue), which is a real triage risk: a genuine incident can be missed or delayed because it looks similar to routine noise. The fix is tuning or triage rules, not blanket ignoring or blanket urgency.
Security Incident ResponseDifficulty 2
A workstation is confirmed to be running malware that is actively communicating with an external address. The workstation is not critical to production. What is the most appropriate immediate containment action?
- aLeave the workstation fully connected and simply lower its alert priority so it stops generating notifications.
- bWait until the next scheduled maintenance window before taking any action on the workstation.
- cReformat and reinstall the workstation immediately, before anyone reviews what happened.
- dDisconnect the workstation from the network (or block its outbound traffic) while preserving its state for review.✓
Explanation:Isolating the host — pulling it off the network or blocking its outbound traffic — stops the malware from communicating further while keeping the machine intact for analysis. Lowering priority ignores the incident; waiting for maintenance delays containment; immediate reformatting destroys evidence before root cause is understood.
Security Incident ResponseDifficulty 1
In the incident response lifecycle, what does the eradication phase primarily aim to accomplish?
- aRemove the root cause of the incident (such as malware, a rogue account, or the exploited flaw) so it cannot simply reappear.✓
- bRestore the affected systems to normal service without checking whether the underlying cause was addressed.
- cWrite the final report summarizing what happened, several weeks after the systems are already back online.
- dNotify customers about the incident regardless of whether the technical root cause has been identified.
Explanation:Eradication follows containment: once the incident is contained, responders remove the actual cause — malicious files, backdoor accounts, the exploited vulnerability — so the same issue does not simply resurface once systems are reconnected.
Security Incident ResponseDifficulty 2
After eradicating malware from a compromised server, a team is about to bring it back into production during the recovery phase. What should they do before fully restoring normal traffic?
- aImmediately route full production traffic back to the server, since eradication already finished.
- bBring the server back gradually while actively monitoring for signs the compromise indicators reappear.✓
- cSkip monitoring entirely, since the incident is now officially closed once eradication is done.
- dRestore the server from the most recent backup without checking whether that backup also contains the compromise.
Explanation:Recovery is not just 'flip it back on' — it typically involves staged restoration with heightened monitoring to confirm the same indicators of compromise do not return, since eradication can occasionally miss something. Restoring from an unverified backup risks reintroducing the same problem.