The Incident Response Lifecycle
Incident response is a defined sequence, and the exam cares far more about the order of the steps than about the tooling used in any of them. The single most important idea is that preparation happens long before anything goes wrong: the plan, the team, the contact list and the practice runs all have to exist in advance, because nobody writes a good process during a crisis. After that the flow is consistent. Detect that something has happened, contain it so it stops spreading, remove the cause, restore service, and then feed what you learned back into preparation so the next one goes better.
Exam tip. Order questions are decided by one rule: contain before you eradicate, and eradicate before you recover. If an option offers to rebuild or restore before the cause is removed, it is wrong. When a compromised machine is found, the expected first action is to isolate it from the network, not to power it off, because powering off destroys volatile evidence.
Evidence Handling and Chain of Custody
The moment an incident might end up in court or in a disciplinary hearing, how you handle the evidence matters as much as what the evidence shows. Digital evidence is trivially altered, so the discipline is about proving that what you present is identical to what you collected. That means working from a verified copy rather than the original, hashing to demonstrate integrity, collecting in order of how quickly the data will disappear, and keeping an unbroken written record of every person who touched it. A single gap in that record is usually enough to have the evidence excluded, regardless of what it proves.
Exam tip. If an answer has you examining the original drive, it is wrong: image it with a write blocker and work on the copy. When a question asks what would most likely get evidence thrown out, the answer is a break in the chain of custody. And once litigation is anticipated, the immediate action is a legal hold that suspends routine deletion.
Disaster Recovery Strategies, Sites and Backups
Disaster recovery is the technical half of continuity: getting systems and data back after a disruption. Every decision here is a trade of money against time, and the recovery objectives from the business impact analysis are what tell you how much time you are allowed to buy back. Alternate sites range from an empty building you would have to fit out, through a partly equipped facility, to a fully mirrored environment that can take over almost immediately. Backup strategy follows the same logic: how often you copy the data decides how much you can lose, and how you copy it decides how long restoring takes.
Exam tip. Restore-order questions are almost always about incremental versus differential, so fix that pair firmly. Site questions come down to recovery time objective against budget: a very short RTO forces a hot site, and a cold site can never satisfy one. Watch for answers that treat replication as a backup, because replicated corruption is still corruption.
Disaster Recovery Testing and Plan Maintenance
A recovery plan that has never been tested is a document, not a capability. Testing runs on a ladder of increasing realism and increasing risk to live operations, and the exam expects you to know the rungs in order and what each one actually proves. You begin with people reading the plan, progress to discussing a scenario together, then to simulating a response, then to actually running production at the alternate site, and finally to shutting the primary down entirely. The last of these gives the most conclusive evidence and is the only test that can itself cause the outage it was rehearsing for.
Exam tip. Questions here usually ask for either the least disruptive test or the most conclusive one. Least disruptive is the read-through, most conclusive is the full interruption test, and parallel is the answer whenever the stem wants proof the alternate site works without risking production. A full interruption test always requires explicit senior management approval.
Monitoring and Detection: Logging, SIEM and IDS
Detection is what turns preventive controls from a hope into a system, because sooner or later something gets through and the only question is how long it goes unnoticed. That capability rests on logs that are complete, time-consistent and protected from the very attacker they record, and on a platform that correlates them across sources so a pattern nobody could see in one log becomes visible across many. Detection technology then splits on one design choice: matching what you already know is bad, or flagging what departs from normal. Each catches what the other misses, which is why mature environments run both.
Exam tip. Zero-day and previously unknown are the trigger words for anomaly-based detection, while known attack pattern points at signatures. If the requirement is to stop the traffic rather than record it, the answer is an inline IPS. And if a scenario has an administrator deleting evidence of their own activity, the control is forwarding logs to a separate system they cannot reach.