SOA-C02 Monitoring, Logging, and Remediation 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 a CloudWatch Logs metric filter and a Lambda function that sends email via SES

  Why it's wrong here

  CPUUtilization is published as a numerical metric by the EC2 instance, not as a log event, so a CloudWatch Logs metric filter cannot parse it from actual log data. Even if you attempted to bridge the gap by having an agent send logs, you would still need a metric filter and an alarm on the resulting custom metric to trigger the Lambda, making the SES/Lambda pipeline redundant and more costly. The native alarm-to-SNS path eliminates Lambda cold starts, IAM permission complexity, and SES email configuration overhead.

• ✓

  Create a CloudWatch metric alarm that sends a notification to an Amazon SNS topic subscribed with email endpoints

  Why this is correct

  A CloudWatch metric alarm continuously evaluates the CPUUtilization metric against a defined threshold, such as 80% for five consecutive evaluation periods. When the alarm enters the ALARM state, it automatically publishes a message to an Amazon SNS topic, and that topic's email-subscribed endpoints receive a notification without any additional infrastructure. This is the standard, fully managed pattern for EC2 metric alerting; SNS handles message delivery, retries, and fan-out to multiple endpoints (email, SMS, etc.) with no servers to manage.

• ✗

  Create a CloudWatch Events rule that matches EC2 instance state changes and sends to SQS with a Lambda consumer

  Why it's wrong here

  CloudWatch Events—now offered through Amazon EventBridge—reacts to event patterns such as EC2 instance state-change notifications (e.g., 'running' or 'stopped'), not to metric thresholds or CPU utilization levels. A rule matching instance state changes would never fire for a CPU spike, so the SQS queue would receive no messages and the Lambda consumer would never trigger an email. This approach also introduces unnecessary asynchronous components that require separate configuration for queue polling, dead-letter queues, and Lambda permissions, adding latency and operational complexity.

• ✗

  Configure a CloudWatch dashboard that displays CPU utilization and share it with the team

  Why it's wrong here

  A CloudWatch dashboard provides a real-time graphical view of CPUUtilization and can be shared via a console link, but it only displays data when someone actively opens it. It does not evaluate thresholds, generate alerts, or initiate any delivery mechanism such as email or SMS. Relying on a dashboard means a human must continuously watch the screen to notice a spike, which is not automated and directly fails the requirement for proactive notification when CPU utilization exceeds a threshold.

Go deeper

Related to this question