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.

• ✗

  Use AWS Systems Manager to automatically connect to the instance via EC2 Instance Connect, run commands to capture forensic data, and then modify the security group to deny all inbound traffic.

  Why it's wrong here

  This response lacks automated triggering because AWS Systems Manager does not natively listen for GuardDuty findings, and EC2 Instance Connect requires a manual session initiation; it cannot start automatically to perform forensic actions. Even if invoked manually, using a security group to deny all inbound traffic would cut off all management access before you could run further commands, and you would still need to snapshot the EBS volume first. The correct architecture uses EventBridge to trigger Lambda, which snapshots first, then isolates and stops the instance.

• ✗

  Create a CloudWatch Logs metric filter on the VPC Flow Logs for the attacker IP. When the metric breaches a threshold, trigger an SNS topic that runs an AWS Systems Manager Automation document to isolate the instance and take an EBS snapshot.

  Why it's wrong here

  VPC Flow Logs are not an appropriate trigger source because GuardDuty findings are delivered to Amazon EventBridge, not to CloudWatch Logs, and a metric filter on Flow Logs for a specific attacker IP cannot reliably correlate with the finding in near-real time. Flow Logs are sampled and may not show every packet, so you could miss the attack or take hours to see the traffic. The correct pattern is an EventBridge rule on the GuardDuty finding that directly calls Lambda, which snapshots the volume before any isolation or stopping, rather than relying on a CloudWatch Logs metric threshold and SNS.

• ✓

  Configure Amazon EventBridge to detect the GuardDuty finding and invoke an AWS Lambda function. The Lambda function first calls the EC2 CreateSnapshot API to capture a forensic snapshot of the instance's EBS volume. Then, it uses AWS Systems Manager Automation to run a pre-defined automation document that isolates the instance by modifying the instance's security group to only allow traffic from a trusted management IP, and then stops the instance.

  Why this is correct

  This is the correct automated response because Amazon EventBridge natively receives GuardDuty findings and can invoke a Lambda function as a target. The Lambda function first calls the EC2 CreateSnapshot API, ensuring a forensic copy of the EBS volume is preserved before any state changes. Then, instead of terminating the instance, it uses AWS Systems Manager Automation with a predefined document to modify the security group to allow only the trusted management IP, and finally stops the instance—which preserves the instance for further analysis and minimizes the risk of losing evidence.

• ✗

  Configure a CloudWatch Events rule to detect the GuardDuty finding and invoke an AWS Lambda function. The Lambda function terminates the EC2 instance and then takes a snapshot of the EBS volume for forensic analysis.

  Why it's wrong here

  Although CloudWatch Events (now EventBridge) can trigger on GuardDuty findings, the fatal flaw here is the order of operations: terminating the EC2 instance before taking a snapshot can cause the EBS volume to be deleted if the 'Delete on Termination' flag is set, and it also destroys any running processes, open files, or volatile data that might be needed for forensics. A terminating instance cannot be restarted for live analysis, so the incident response process is cut short. The snapshot must be taken first—ideally by a Lambda function that then isolates and stops the instance via Systems Manager—to preserve the evidence and allow for a controlled investigation.

Go deeper

Related to this question