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 VPC Flow Logs to send logs to CloudWatch Logs, then create a metric filter that triggers a Lambda function.

  Why it's wrong here

  VPC Flow Logs capture metadata about accepted and rejected traffic but do not provide real-time, event-driven triggers for malicious IP detection; GuardDuty generates findings based on threat intelligence, and those findings must directly invoke a Lambda function via CloudWatch Events or EventBridge to isolate the instance. This option is tempting because VPC Flow Logs are commonly used for network monitoring and can feed CloudWatch Logs for metric-based alerts, which would be correct for detecting traffic volume anomalies rather than specific known malicious IP addresses.

• ✗

  Use Amazon GuardDuty to send findings to AWS Systems Manager Automation to run a document that isolates the instance.

  Why it's wrong here

  Amazon GuardDuty cannot directly send findings to AWS Systems Manager Automation. An intermediary service, such as Amazon EventBridge, is required to route GuardDuty findings to trigger a Systems Manager Automation document. This option is tempting because Systems Manager Automation is perfectly capable of executing runbooks to isolate EC2 instances, making it a valid component for automated remediation, but it requires the correct event source integration.

• ✓

  Use Amazon GuardDuty to send findings to Amazon CloudWatch Events, which triggers an AWS Lambda function that modifies the security group to remove the instance.

  Why this is correct

  Amazon GuardDuty is purpose-built to generate security findings based on threat intelligence and anomaly detection, including malicious IP addresses attempting to communicate with EC2 instances. These findings can be delivered as events to Amazon CloudWatch Events (or Amazon EventBridge) using a rule that matches specific finding types, and that rule triggers an AWS Lambda function. The Lambda function can then programmatically modify the instance's security group—removing its association or revoking ingress/egress rules—to automatically isolate the compromised resource. This is a well-established, near-real-time automated response pattern that requires no manual intervention and directly ties a confirmed threat to an infrastructure-level containment action.

• ✗

  Use AWS Config rules to detect the traffic and invoke a Lambda function to change the security group.

  Why it's wrong here

  AWS Config rules evaluate the configuration state of AWS resources against desired policy, such as checking whether a security group allows unrestricted SSH access or whether an instance has the correct tag. They do not inspect network packets, monitor traffic flows, or analyze real-time communications between instances and external IPs, so they cannot detect malicious traffic in the first place. While a Config rule could be set to invoke a Lambda function on a configuration change, the rule itself has no mechanism to identify that an instance is communicating with a known bad actor. Thus, this option conflates configuration governance with traffic inspection and would fail to meet the security requirement of detecting and responding to an active network threat.

Go deeper

Related to this question