SCS-C02 Threat Detection and Incident 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.

• ✗

  Create an EBS snapshot of the instance's root volume.

  Why it's wrong here

  An EBS snapshot of the root volume captures only the persistent block-level disk state at a point in time; it does not include volatile memory (RAM) such as running processes, open network connections, mounted cryptographic keys, or temporary credentials that a memory dump would contain. Even if the instance is stopped, the snapshot preserves no memory-resident evidence, so it cannot substitute for a proper memory acquisition during a compromise investigation.

• ✗

  Analyze the memory dump on the same EC2 instance.

  Why it's wrong here

  Running analysis tools directly on the compromised EC2 instance risks altering or destroying the very evidence you are trying to examine, because installing or executing a program writes to memory, changes kernel structures, and may trigger anti-forensic or self-destruct mechanisms inside the malware's process space. The correct approach is to acquire a raw memory dump to an external, trusted system and perform any analysis from that clean environment, avoiding contamination of the original volatile evidence.

• ✓

  Record the date, time, and digital signature of the acquisition.

  Why this is correct

  Recording the date, time, and digital signature of the acquisition is a cornerstone of establishing chain of custody, demonstrating exactly when the dump was taken and by whom. A digital signature binds the acquisition record to the responder and protects against later allegations that the evidence was fabricated or altered during collection. This documentation is distinct from, but complements, the hash verification that protects the integrity of the dump file itself.

• ✓

  Generate a cryptographic hash of the memory dump file.

  Why this is correct

  Generating a cryptographic hash, such as SHA-256, of the memory dump immediately after acquisition creates a baseline fingerprint that can be recomputed later to prove the dump has not been changed, corrupted, or tampered with during transport or analysis. Any alteration to the file—even a single bit—will yield a different hash, allowing forensic examiners to demonstrate with mathematical certainty that the evidence is byte-for-byte identical to what was collected on the compromised instance.

• ✗

  Upload the memory dump to a public S3 bucket for analysis.

  Why it's wrong here

  Uploading a memory dump to a public S3 bucket exposes highly sensitive volatile-memory artifacts—such as plaintext API keys, passwords, session tokens, and user data—to the entire internet, which represents a severe confidentiality breach and likely violates compliance and legal requirements. It also eliminates all access control and audit capability, making the evidence discoverable and modifiable by unauthorized parties. A forensic-grade S3 bucket with strict bucket policies, SSE-KMS encryption, versioning, and server access logging is the only acceptable storage destination.