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.

• ✗

  Enable GuardDuty to export findings to CloudWatch Logs and then create a metric filter.

  Why it's wrong here

  Enabling GuardDuty to export findings to CloudWatch Logs is not a native integration—GuardDuty automatically emits each finding as an event to Amazon EventBridge, not to a CloudWatch Logs group. Even if you used an EventBridge rule to deliver those events into CloudWatch Logs, you would then need a metric filter and alarm to trigger an action, adding latency and operational complexity. The metric filter would only match log text after the logs are written, so this approach is slower and more brittle than consuming the finding event directly.

• ✓

  Create an Amazon EventBridge rule with an event pattern that matches GuardDuty finding events.

  Why this is correct

  GuardDuty publishes every finding as an event to the default EventBridge event bus with a source of 'aws.guardduty' and a detail-type of 'GuardDuty Finding'. A rule with an event pattern that filters on either the source or the detail-type gives you a flexible, event-driven trigger point for incident response. This approach is direct, near-real-time, and requires no extra services or log processing to detect a new security finding.

• ✗

  Create an Amazon SNS topic and subscribe the Lambda function to it, then configure GuardDuty to publish to SNS.

  Why it's wrong here

  GuardDuty has no native capability to 'publish to SNS'; its findings are delivered to EventBridge, so any SNS-based flow would require an extra EventBridge rule to route the finding to the SNS topic and then the Lambda function. That SNS hop is unnecessary for a single subscriber, and it means more IAM roles, permissions, and failure points to manage. Directly invoking Lambda from EventBridge is simpler and more reliable for an automated incident response playbook.

• ✓

  Configure the rule to invoke an AWS Lambda function that executes the incident response playbook.

  Why this is correct

  Once the EventBridge rule matches a GuardDuty finding, you can attach a Lambda function as the rule's target; EventBridge invokes the function asynchronously with a JSON payload containing the finding's details, such as severity, type, region, and affected resource. The Lambda function can then execute the incident response playbook—isolating a compromised EC2 instance, revoking IAM credentials, or calling AWS Security Hub—without needing a server. This is the standard compute target for serverless, event-driven security automation.

• ✗

  Set up a CloudWatch Logs subscription filter to forward GuardDuty logs to the Lambda function.

  Why it's wrong here

  A CloudWatch Logs subscription filter only works against log groups and log streams that actually contain data, but GuardDuty does not write its findings to CloudWatch Logs by default—it emits each finding as an EventBridge event. Without a log stream populated by GuardDuty findings, the subscription filter would never match anything, so the Lambda function would never fire. Even if you piped GuardDuty events into CloudWatch Logs, you would have to parse encoded log events rather than receiving the structured finding directly from EventBridge.

Go deeper

Related to this question