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.

• ✓

  Configure an Amazon EventBridge rule to match GuardDuty findings and invoke the Lambda function.

  Why this is correct

  EventBridge is GuardDuty's native event bus integration. GuardDuty automatically publishes each finding as an event to the default event bus, where a rule can match the detail-type 'GuardDuty Finding' and use Lambda as a target. The rule supports filtering by severity, account, or finding type, and Lambda receives the finding JSON directly, enabling precise, low-latency automated remediation. This is the architecturally supported pattern with built-in retry and optional dead-letter queues.

• ✗

  Subscribe the Lambda function to an SNS topic that GuardDuty publishes findings to.

  Why it's wrong here

  This pattern is not supported by GuardDuty: GuardDuty does not publish findings to an SNS topic directly. Instead, findings are emitted as EventBridge events, and if a notification is desired, an EventBridge rule must first route the finding to an SNS topic as a target. Directly subscribing a Lambda function to a GuardDuty SNS topic would require a manually-created publisher that duplicates findings, adds latency, and risks missing events unless you build a separate polling mechanism.

• ✗

  Use CloudWatch Logs subscription filter to trigger Lambda on GuardDuty log entries.

  Why it's wrong here

  GuardDuty never writes its findings to CloudWatch Logs as log entries, so a log subscription filter has no GuardDuty data to match. A CloudWatch Logs subscription filter is intended for VPC Flow Logs, CloudTrail logs, or application log groups, not for GuardDuty finding streams. Even if you configure it, the filter pattern will never match because there is no corresponding log group or log stream containing GuardDuty finding JSON. The real-time integration point is EventBridge, not Logs.

• ✗

  Have the Lambda function poll the EC2 instance metadata for threat indicators.

  Why it's wrong here

  EC2 instance metadata (accessed at http://169.254.169.254/latest/meta-data) contains instance identity, IAM role, or user data, but it has no relationship to GuardDuty findings. GuardDuty generates findings by analyzing VPC DNS logs, VPC Flow Logs, and threat intelligence, and it publishes those findings through its API and EventBridge. Polling metadata would neither retrieve findings nor trigger a Lambda function; it would also add unnecessary custom infrastructure, latency, and credential-handling risk compared to the event-driven EventBridge integration.

Go deeper

Related to this question