DOP-C02 Monitoring and Logging Practice Question
A company is using AWS Lambda functions for data processing. The operations team needs to monitor the number of invocations, duration, and error counts for each function. They also want to set alarms when the error rate exceeds 5% in a 5-minute period. Which combination of AWS services should the team use to achieve this with minimal effort?
⚠ Common exam trap
DOP-C02 often tests the distinction between metrics and logs; candidates may choose log-based solutions, but the exam favors using built-in CloudWatch metrics and math expressions for minimal effort and real-time monitoring.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use CloudWatch metrics published by Lambda and create a CloudWatch alarm on the ErrorCount metric with a math expression to calculate error rate.
Lambda automatically publishes metrics to CloudWatch, including Invocations, Duration, and Errors. To monitor error rate, you can create a CloudWatch alarm using a math expression that calculates the error rate from the ErrorCount and Invocations metrics. This approach requires minimal effort because it leverages built-in metrics and CloudWatch's native alarm capabilities.
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 AWS CloudTrail to log Lambda invocations and configure CloudWatch alarms on the log events.
Why it's wrong here
AWS CloudTrail records management and data-plane API calls, such as Invoke, but it does not capture the results of the function's execution, including whether the handler threw an exception or returned an error. CloudTrail log events only show that an invocation was made, not the function's error rate or the number of failed invocations over time. Configuring CloudWatch alarms on CloudTrail log events would therefore trigger only when API calls occur, not when your code fails, making this approach ineffective for monitoring processing errors.
- ✗
Enable Lambda Insights to collect detailed metrics and use CloudWatch dashboards to monitor error rates.
Why it's wrong here
Lambda Insights is designed for deep performance troubleshooting by collecting detailed telemetry such as CPU, memory, cold starts, and network I/O via a required Lambda extension. For the simple goal of monitoring the error rate of a Lambda function, Insights adds unnecessary complexity, additional dependencies, and potential runtime overhead. Moreover, it does not directly expose a single ErrorCount metric for alarm purposes; you would still need to aggregate its logs or metrics separately, which is more effort than using the built-in Lambda metrics already available in CloudWatch.
- ✗
Stream Lambda logs to CloudWatch Logs and use CloudWatch Logs Insights to query error rates, then create alarms.
Why it's wrong here
Streaming Lambda logs to CloudWatch Logs and using Logs Insights to query error rates is redundant because Lambda automatically publishes error-related metrics to CloudWatch without any log parsing. Logs Insights queries are run ad hoc and are not designed for continuous real-time alarming; while you could create a metric filter on log messages, that involves extra costs, adds latency, and is less reliable than consuming the 'ErrorCount' metric that Lambda emits natively. CloudWatch alarms operate on numeric metrics, so deriving an error rate from log text is an indirect workaround when the exact metric already exists.
- ✓
Use CloudWatch metrics published by Lambda and create a CloudWatch alarm on the ErrorCount metric with a math expression to calculate error rate.
Why this is correct
Lambda automatically emits a set of standard metrics to CloudWatch, including 'Invocations', 'Errors', and 'ErrorCount' (via enhanced metrics if enabled), so you can directly build an error-rate expression without additional setup. The correct approach is to use a CloudWatch math expression, such as 'm1/m2*100' where m1 is ErrorCount and m2 is Invocations, and then create an alarm on that expression to alert when the error rate exceeds a threshold. This leverages the native, low-latency monitoring pipeline and avoids the overhead of log-based or third-party tooling, making it the simplest and most operationally sound solution.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
One of 1,298 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company uses AWS Lambda for data processing. The operations team wants to be alerted when a function fails. Which TWO methods can they use?
easy- A.Configure S3 event notifications to trigger on Lambda errors.
- B.Enable AWS CloudTrail to log Lambda invocations.
- ✓ C.Configure a dead-letter queue (DLQ) for the Lambda function and monitor the queue.
- ✓ D.Create a CloudWatch alarm on the 'Errors' metric for the Lambda function.
- E.Use AWS Config to detect Lambda function failures.
Why C: Option D is correct because Lambda automatically publishes the 'Errors' metric to Amazon CloudWatch, and a CloudWatch alarm can be created on that metric to trigger an Amazon SNS notification when the error threshold is breached, directly alerting the operations team. Option C is correct because configuring a dead-letter queue (an Amazon SQS queue or SNS topic) for the Lambda function captures failed asynchronous invocations, and monitoring that queue (e.g., via CloudWatch metrics like ApproximateNumberOfMessagesVisible) provides an alerting mechanism for failures. Option A is incorrect because S3 event notifications only trigger Lambda invocations on object events; they do not detect or report Lambda execution errors. Option B is incorrect because CloudTrail records API activity and management events, not Lambda function invocation failures, and it is not an alerting service. Option E is incorrect because AWS Config evaluates resource configuration compliance, not runtime function failures.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.