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.

• ✓

  Create an Amazon EventBridge rule that matches GuardDuty findings and triggers a Lambda function.

  Why this is correct

  Amazon GuardDuty publishes a `GuardDuty Finding` event to the default EventBridge event bus whenever a finding is generated. An EventBridge rule with an event pattern that matches finding types, account IDs, or severity can directly invoke a Lambda function as a target, giving you a serverless, near-real-time response path. This is the most idiomatic native integration for GuardDuty because it requires no polling, no extra queue, and gives you full filtering and transformation logic inside Lambda.

• ✗

  Configure Amazon CloudWatch Logs to send log events to an email distribution list.

  Why it's wrong here

  Amazon CloudWatch Logs is a service for ingesting, storing, and querying log data; it has no native email delivery capability. You would need a subscription filter that streams log events to Lambda, which then calls SNS, and CloudWatch Logs does not receive GuardDuty findings in the first place unless you build a custom pipeline to write them there. Using CloudWatch Logs directly as an email notification channel is architecturally incorrect and adds needless complexity.

• ✗

  Create an Amazon CloudWatch Events rule to route findings to a Lambda function.

  Why it's wrong here

  Amazon CloudWatch Events is the predecessor of Amazon EventBridge and its rules can technically route GuardDuty findings to Lambda, so this option would still function in practice. However, AWS recommends EventBridge for GuardDuty because EventBridge provides richer event payloads, schema support, and has replaced CloudWatch Events as the modern integration point. For a new implementation, choosing the legacy CloudWatch Events API is not the best-practice answer even though it is compatible with existing pipelines.

• ✓

  Create an Amazon Simple Notification Service (SNS) topic and subscribe the email distribution list.

  Why this is correct

  Amazon SNS is a pub/sub service that can send email messages to a subscribed distribution list, and GuardDuty findings can be routed to an SNS topic through EventBridge to trigger those emails. Because SNS email delivery requires subscribers to confirm their subscription, the engineer would also need an EventBridge rule that targets the topic; as a delivery mechanism, the SNS topic and email subscription are valid. It is arguably simpler than involving Lambda if no message transformation is needed, though it lacks the filtering and enrichment flexibility of a Lambda target.

• ✗

  Create an Amazon Simple Queue Service (SQS) queue and have the Lambda function poll the queue.

  Why it's wrong here

  Amazon SQS is a message queue designed for decoupling producers and consumers, not for sending human-readable email alerts. While a Lambda function could poll the queue and then use SNS to send email, the option as stated omits both the Lambda function and the SNS topic needed to actually deliver email. Adding SQS in front of Lambda introduces latency and polling overhead with no benefit for a simple GuardDuty email notification, making it an unnecessarily complex and incomplete pattern.

Go deeper

Related to this question