DOP-C02 Monitoring and Logging Practice Question
Network Topology
Refer to the exhibit. A DevOps engineer runs the CloudWatch Logs Insights query and sees a spike in errors at 12:00. Which action would best help identify the root cause?
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
✓
Query the logs around 12:00 without aggregation to see the actual error messages.
The query shows a sudden spike at 12:00. To identify the root cause, the engineer should look at the error messages themselves around that time. Filtering by @timestamp and @message to see the actual error messages will help identify the type of error. Adding a filter for a specific error pattern or grouping by error message would also help.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a filter for @logStream to see which log stream has the most errors.
Why it's wrong here
Filtering by @logStream groups the error count by log stream, which usually corresponds to a specific instance, container, or Lambda function. While this can reveal which resource is emitting the most errors, it does not expose the content of those errors, so you still cannot determine whether they stem from a code defect, a dependency failure, or a misconfiguration. Identifying the root cause requires examining the actual @message payload, not the per-stream distribution.
- ✗
Increase the limit to 100 to see more results.
Why it's wrong here
The limit parameter in a CloudWatch Logs Insights query controls the maximum number of time bins returned in the results, not the number of log events scanned or displayed. Since the spike at 12:00 is already visible in the current 1h bin aggregation, increasing the limit to 100 would merely show more chart points or table rows without adding any insight into why the error count jumped. To find the trigger, you must retrieve the raw log events inside that time window, not request more histogram buckets.
- ✓
Query the logs around 12:00 without aggregation to see the actual error messages.
Why this is correct
Removing the count() and bin() aggregation and running a query that returns the raw @timestamp and @message fields around 12:00 will display the actual error strings, stack traces, and exception types that caused the spike. This is the definitive method for root-cause analysis because it lets you see exactly what the application logged at the moment of failure, such as a TimeoutException, a 500 Internal Server Error, or a specific failed database call. You can then filter further using regular expressions or parse commands to isolate the common pattern.
- ✗
Change the bin time to 1m to get more granular data.
Why it's wrong here
Changing the bin time from 1h to 1m makes the aggregated error count more granular, so you can pinpoint the exact minute the spike began, but it still returns only a count of log events per bin. The spike is already clearly visible at 12:00 in the original query, so finer granularity does not reveal the log message content or the underlying cause. The next logical step is to query the raw events within that minute, using a filter like @timestamp between ... and ... to read the actual error text.
Go deeper
Related to this question
About these practice questions
One of 1,013 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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.