DOP-C02 Incident and Event Response Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Detach the EBS volumes and attach them to a forensic instance.

  Why it's wrong here

  Detaching the EBS root and data volumes from a running instance is a viable preservation step only after you have captured volatile state; doing it first halts the instance (or requires a stop), which destroys RAM and interrupts kernel/process activity that may be key to the investigation. Moreover, attaching the original volumes directly to a forensic instance can modify access times, journal logs, and filesystem metadata, contaminating evidence. The correct order is to snapshot the volumes while the instance is still running (or after a memory dump) to create a bit-for-bit forensic copy for analysis without altering the originals.

• ✗

  Retrieve the instance metadata from the console.

  Why it's wrong here

  Instance metadata from the console, such as AMI ID, instance type, security groups, and user-data, is non-volatile configuration persisted in EC2's control plane and can be retrieved at any time after the incident. It does not contain disk contents, running processes, open network connections, or memory, so it cannot reveal the attacker's actions or payloads. Relying on this as an evidence-collection step wastes critical time while volatile data degrades; it is merely supplementary context, not a preservation action.

• ✓

  Create a snapshot of the attached EBS volumes.

  Why this is correct

  Creating a snapshot of the attached EBS volumes is a core forensic preservation technique because it captures the full disk state—including deleted file remnants, user-space artifacts, logs, and malware binaries—without stopping the instance. Unlike a live filesystem copy, an EBS snapshot is crash-consistent (or application-consistent with pre-freeze), providing a point-in-time image that can be analyzed on a separate forensic instance without risking further alteration of the original evidence. This must be done before any stop/termination, since those actions can change or destroy disk data.

• ✓

  Collect a memory dump from the instance before stopping it.

  Why this is correct

  Collecting a memory dump before stopping the instance preserves volatile data that exists only in RAM—encryption keys, injected processes, kernel modules, active network connections, and in-memory malware—which is permanently lost the moment the instance is stopped or terminated. Techniques like LiME (Linux Memory Extractor) or Windows Memory Acquisition require the instance to be running and ideally executed with minimal interference to avoid corrupting the sample. This is a complementary step to an EBS snapshot: memory captures the live threat, while the disk snapshot captures persistent artifacts for offline forensics.

• ✗

  Terminate the instance immediately to prevent further access.

  Why it's wrong here

  Terminating the instance immediately is the worst possible response because it irrevocably destroys every piece of forensic evidence—both volatile memory and the entire EBS volume set (unless termination protection/deletion protection was configured, which is rare)—and removes the ability to determine the attack vector, scope, or attacker's methods. A termination also breaks active network connections and deletes the instance's console output, making incident reconstruction nearly impossible. The correct containment approach is to isolate the instance with security group changes or network ACLs while preserving its memory and disk state for investigation.

Go deeper

Related to this question