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.

• ✗

  Modify the Lambda function to catch the timeout exception and log it to CloudWatch Logs

  Why it's wrong here

  Adding a try/catch around your handler to capture the timeout and write it to CloudWatch Logs only creates a passive record—there is no mechanism to proactively page or notify an operator. Lambda already emits a timeout as an Errors metric, so waiting for someone to read logs is not an automated alerting strategy. It also fails to address the operational need for immediate incident response, and logging alone does not satisfy the requirement for real-time notification.

• ✓

  Create a CloudWatch alarm on the Lambda Errors metric that sends an SNS notification

  Why this is correct

  A CloudWatch alarm on the AWS/Lambda Errors metric directly monitors every failed invocation, including timeouts, and transitions to ALARM when the error count exceeds the configured threshold. The alarm then publishes to an SNS topic, which can deliver email, SMS, or trigger a webhook or incident-management tool. This is the native, low-latency path because the metric is emitted automatically by the Lambda service without any code changes or log processing.

• ✗

  Set up a CloudWatch Logs subscription filter to send error logs to an SNS topic

  Why it's wrong here

  A subscription filter on the Lambda function's log group can only stream log events to destinations like Lambda, Kinesis, or OpenSearch—there is no native SNS subscription destination, so you would need to insert an intermediary Lambda or Kinesis consumer to publish to SNS. Even where an intermediary handles forwarding, this path depends on the function writing a log line containing the relevant error pattern and adds latency, complexity, and an extra failure point compared to simply alarming on the Errors metric. It might work in a pinch, but it is a brittle workaround rather than the recommended monitoring pattern.

• ✗

  Configure an Amazon SNS topic as a Lambda destination for the function

  Why it's wrong here

  Lambda Destinations (including an SNS topic for failure events) apply only to asynchronous invocations or to stream-based event source mappings like Kinesis and DynamoDB, not to SQS poll-based event source mappings. When Lambda consumes from an SQS queue via an event source mapping, it invokes the function synchronously with the queue messages, so the destination configuration is ignored. Configuring an SNS destination therefore will not fire on SQS-triggered timeouts; you would need to configure a Dead-Letter Queue or rely on the Errors metric instead.

Go deeper

Related to this question