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.

• ✗

  Configure S3 event notifications to trigger on Lambda errors.

  Why it's wrong here

  S3 event notifications are designed to react to object-level events such as s3:ObjectCreated or s3:ObjectRemoved in a bucket, not to Lambda execution outcomes. Lambda function errors are runtime exceptions that occur outside S3's event namespace, and S3 has no visibility into invocation failures. Routing error data to S3 would require custom instrumentation, and S3 notifications themselves cannot be triggered by a Lambda function's failure status. Thus this option provides no mechanism to monitor or detect Lambda errors.

• ✗

  Enable AWS CloudTrail to log Lambda invocations.

  Why it's wrong here

  AWS CloudTrail records management-plane API calls to Lambda, including Invoke actions, but it does not capture the function's runtime output, unhandled exceptions, or execution status. A CloudTrail event shows that an invocation occurred and from which IAM entity, not whether the code executed successfully or failed. You could query CloudTrail logs for unusual invocation patterns, but this is neither real-time nor error-specific, and it would require building a separate analytics pipeline. Therefore, CloudTrail is an audit tool, not a functional error-monitoring solution.

• ✓

  Configure a dead-letter queue (DLQ) for the Lambda function and monitor the queue.

  Why this is correct

  For asynchronous invocations, Lambda can be configured with a dead-letter queue (an SQS queue or SNS topic) to receive event payloads that could not be processed after a function fails or exhausts retry attempts. The DLQ preserves the exact original event data, allowing you to inspect, replay, or archive failed records in a durable buffer. Monitoring the DLQ (for example, with a CloudWatch alarm on SQS ApproximateNumberOfMessagesVisible) directly alerts you to the presence of undelivered events. This is why the correct answer combines a DLQ with active monitoring of that queue.

• ✓

  Create a CloudWatch alarm on the 'Errors' metric for the Lambda function.

  Why this is correct

  CloudWatch publishes a Lambda Errors metric that increments whenever an invocation fails due to an unhandled exception, timeout, or runtime issue. Creating an alarm on this metric with a threshold such as '> 0 for 1 datapoint' triggers an SNS notification, enabling near-real-time operational alerts when failures occur. However, this metric is aggregated across all invocations and does not contain the event payloads, so it cannot tell you which specific record failed. It is still a valid and complementary failure-detection mechanism, especially for synchronous or high-volume functions where aggregate indicators matter.

• ✗

  Use AWS Config to detect Lambda function failures.

  Why it's wrong here

  AWS Config is a governance service that tracks configuration changes to resources and evaluates them against rules (for example, ensuring Lambda functions have a DLQ or a specific runtime). It reads the configuration of the function — like memory size, timeout, or assigned roles — but never sees runtime execution metrics, errors, or successful invocations. A custom Config rule could flag functions that lack a DLQ, but that is a forward-looking compliance check, not an alert on actual errors that have occurred. Thus Config cannot detect or monitor Lambda function failures.

Go deeper

Related to this question