DOP-C02 Monitoring and Logging 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 alarm on the ApproximateNumberOfMessagesVisible metric of the dead-letter queue.

  Why this is correct

  The ApproximateNumberOfMessagesVisible metric of the dead-letter queue is a native SQS metric that reports the number of messages available for retrieval. When the redrive policy moves messages from the source queue to the DLQ after the maximum receive count is exceeded, this metric immediately increases. Creating a CloudWatch alarm on this metric provides a direct, near-real-time signal that messages are failing processing, and you can trigger an SNS notification or other action from the alarm.

• ✗

  Enable CloudTrail to log SQS API calls and create a metric filter for SendMessage to the DLQ.

  Why it's wrong here

  CloudTrail logs management-plane API calls for SQS, such as CreateQueue or DeleteQueue, but it does not capture data-plane message operations like SendMessage, ReceiveMessage, or DeleteMessage at the message level. Messages entering a DLQ are moved internally by SQS's redrive policy based on receive count, not via a separate user-invoked SendMessage API call. Therefore, a CloudTrail event to trigger a metric filter for messages sent to the DLQ simply does not exist, making this approach technically impossible.

• ✗

  Create a CloudWatch Events rule to monitor the Lambda function errors.

  Why it's wrong here

  A CloudWatch Events (EventBridge) rule monitoring Lambda function errors would only indicate that an invocation failed, not that a message landed in the dead-letter queue. The DLQ is a separate SQS queue that receives messages after the source queue's redrive policy threshold is reached, which can happen even when no Lambda error is logged because the failure could be outside Lambda or in a downstream service. Furthermore, this rule monitors Lambda specifically, while the SQS DLQ could be used by other producers, so it would not comprehensively or directly monitor the DLQ.

• ✗

  Configure the Lambda function's dead-letter queue to send notifications via Amazon SNS.

  Why it's wrong here

  Configuring the Lambda function's dead-letter queue to send notifications via Amazon SNS addresses a different mechanism: Lambda's own DLQ for asynchronous invocations, where failed events are sent to a separate SQS queue or SNS topic. In this scenario, the dead-letter queue in question is an SQS DLQ used as a target by a source queue or the queue itself, and it is not automatically connected to Lambda. Taking 'dead-letter queue' to mean Lambda's DLQ and wiring it to SNS creates a false conflation, and even then SNS would simply publish messages, not provide CloudWatch monitoring of the SQS DLQ's metrics.

Go deeper

Related to this question