SCS-C02 Threat Detection and Incident Response Practice Question

A company uses Amazon GuardDuty to detect threats. The security team wants to be alerted when GuardDuty generates a finding with a severity level of HIGH or CRITICAL. Which AWS service should the team use to send notifications based on GuardDuty findings?

⚠ Common exam trap

Many exam-takers assume GuardDuty findings go directly to CloudWatch Logs or that Lambda is required for filtering, but the native integration with EventBridge eliminates the need for custom processing or intermediate services.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Amazon EventBridge and Amazon Simple Notification Service (SNS)

Amazon EventBridge can capture GuardDuty findings as events using a rule that matches the 'GuardDuty Finding' event type. The rule can then invoke an SNS topic to send email or SMS notifications. This is the recommended pattern because EventBridge provides native integration with GuardDuty and supports filtering by finding severity using event patterns, while SNS handles the actual notification delivery.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Amazon Simple Queue Service (SQS)
Why it's wrong here
Amazon Simple Queue Service (SQS) is a durable message queue designed for decoupling producers and consumers; it does not actively push alerts to end users or provide any built-in notification channel. Even if GuardDuty findings were routed to SQS through an EventBridge rule, a downstream consumer would still need to poll the queue and then format and send a separate notification, making SQS an intermediate buffer rather than a notification endpoint. Because the goal is direct security alerting, SQS alone cannot satisfy the requirement.
✓
Amazon EventBridge and Amazon Simple Notification Service (SNS)
Why this is correct
Amazon EventBridge and Amazon Simple Notification Service (SNS) form the canonical real-time alerting pattern for GuardDuty. GuardDuty automatically publishes every finding to the default EventBridge bus, and a rule can filter on fields like severity, finding type, or affected resource before targeting an SNS topic. SNS then fans out the notification to email, SMS, HTTP/S endpoints, or mobile push, ensuring security analysts are immediately notified without custom code or polling. This native integration is the recommended and fully managed approach.
✗
AWS Lambda
Why it's wrong here
AWS Lambda is a serverless compute service, not a notification mechanism; it can process a GuardDuty finding but cannot directly alert a human. To actually notify an analyst, Lambda would have to call an external service such as SNS, Amazon SES, or a third-party webhook, which adds custom code and operational overhead. While Lambda is useful for enrichment, remediation, or automated response via EventBridge, it is not a substitute for SNS as the alert delivery channel.
✗
Amazon CloudWatch Logs and Amazon Simple Notification Service (SNS)
Why it's wrong here
Amazon CloudWatch Logs and Amazon Simple Notification Service (SNS) are incorrect because GuardDuty does not send findings to CloudWatch Logs by default; its native event destination is EventBridge. Although you could build a custom pipeline to forward findings to CloudWatch Logs and then create a metric filter with a CloudWatch alarm that triggers SNS, that is an unnecessary and non-standard workaround. The direct, supported service pairing for GuardDuty alerts is EventBridge with SNS, not CloudWatch Logs.

Go deeper

SCS-C02 Threat Detection and Incident Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question