SCS-C02 Infrastructure Security 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 Amazon CloudWatch Events to trigger an AWS Lambda function that sends an Amazon SNS notification when a Shield Advanced event occurs.

  Why this is correct

  Shield Advanced is integrated natively with Amazon CloudWatch Events (now Amazon EventBridge), publishing real-time events such as DDoSDetected, AwsShibboleth, and AwsServiceEventNotification. Rather than polling or manual monitoring, you create a CloudWatch Events rule that matches these Shield event types and sets an AWS Lambda function as its target; the Lambda function then formats the event detail and publishes a message to an Amazon SNS topic, enabling timely notifications to your incident-response team. This pattern is the documented, reliable way to automate responses to Shield Advanced findings because it puts the filtering and routing logic in the event bus, not in the notification channel itself.

• ✗

  Enable VPC Flow Logs and create a CloudWatch alarm for high traffic volume.

  Why it's wrong here

  VPC Flow Logs capture metadata about IP traffic entering and leaving your VPC, such as source/destination addresses, ports, and packet counts. While a CloudWatch alarm on 'high traffic volume' could indicate a volumetric DDoS, it is not a signal from Shield Advanced itself, so it cannot guarantee that a true Shield-detected event occurred or will be reported. Furthermore, legitimate traffic spikes can trigger false alarms, and the alarm has no direct awareness of AWS Shield's detections, mitigations, or the specific DDoS event types that the service emits—making it an indirect, unreliable substitute for subscribing to Shield's actual event stream.

• ✗

  Subscribe an SNS topic to Shield Advanced notifications directly.

  Why it's wrong here

  Although Amazon SNS is a common notification endpoint, AWS Shield Advanced does not publish directly to an SNS topic as a native destination. Instead, Shield Advanced emits events to CloudWatch Events, and you must create an event rule whose target is an SNS topic (or a Lambda function that then publishes to SNS) to receive those notifications. Attempting to subscribe an SNS topic directly to Shield Advanced will fail because the Shield service has no API or console action that establishes such a direct SNS subscription; routing through CloudWatch Events/EventBridge is the required integration pattern.

• ✗

  Enable AWS CloudTrail and create a metric filter for DDoS events.

  Why it's wrong here

  AWS CloudTrail records and logs API activity against your AWS account, such as who called which AWS API and when, but it does not capture raw network-level DDoS events or Shield-specific notifications. A metric filter applied to CloudTrail logs can only search for strings in those API-call records, and Shield Advanced does not log its DDoS detection events to CloudTrail as API interactions. Therefore, creating a metric filter for 'DDoS events' in CloudTrail will either find nothing or match incidental API calls that are not actual Shield events, so this approach cannot provide the security-event notification the question requires.

Go deeper

Related to this question