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.

• ✗

  Detach the EBS volumes and attach them to a new instance in a different VPC.

  Why it's wrong here

  Detaching the EBS volumes requires stopping the instance first, which halts the operating system and may flush file-system caches, alter disk state, and overwrite artifacts captured in memory—all critical for forensic analysis. Even after attaching the volumes to a new instance in a different VPC, the original compute instance remains in its original network context unless you separately isolate it, and the stop step may trigger the compromised OS's anti-forensic scripting. This approach is invasive, not reversible, and leaves the compromised instance able to act on the network during the detach process, making it inferior to a snapshot-based AMI plus security-group removal.

• ✗

  Terminate the instance immediately to prevent further damage.

  Why it's wrong here

  Terminating the instance immediately stops the attack surface, but it irrevocably destroys the root EBS volume unless the 'DeleteOnTermination' flag is disabled, and it eliminates all volatile evidence such as memory contents, running processes, active network sockets, and command-line history. Without a memory dump or snapshot taken before termination, the response team cannot perform root-cause analysis or attribute the incident, and the action may also trigger the attacker's failure-handling routines if malware is present. Incident response demands preservation of evidence first; termination is a last resort after all other containment options are exhausted.

• ✓

  Create an AMI of the instance, then remove the instance from the security group to isolate it.

  Why this is correct

  Creating an AMI of the running instance captures point-in-time snapshots of its EBS volumes, preserving the full disk state without requiring a stop; this enables offline forensic analysis of the root volume and any additional data volumes. Removing the instance from its security group—or applying an empty security group—immediately blocks all inbound and outbound traffic to the instance, containing the compromise while the instance remains powered on with its memory, processes, and network flows intact. This approach gives responders the ability to perform live forensics (such as memory capture) while ensuring the attacker cannot use the instance to move laterally, and it is fully reversible if the instance is later cleared.

• ✗

  Stop the instance and change the security group to deny all traffic.

  Why it's wrong here

  Stopping the instance performs a shutdown sequence that can trigger cron jobs, unload kernel modules, and flush memory-backed content to disk, destroying the core evidence needed to understand the attacker's actions—memory is wholly lost and disk state may be subtly altered. Changing the security group to deny all traffic is a sound containment move, but stopping the instance removes the ability to interrogate live processes, open connections, and memory-resident malware that are often essential for determining the scope of the breach. Furthermore, the isolation is not persistent: if the instance is later started—manually or via an autoscaling action—it could rejoin the network unless the security group and instance state are both continuously enforced, so the AMI-plus-removal strategy remains preferable.

Go deeper

Related to this question