DOP-C02 Monitoring and Logging Practice Question
A DevOps engineer is setting up monitoring for an Amazon DynamoDB table that experiences high read traffic. They want to monitor the read capacity consumption and be alerted when the consumed read capacity exceeds 80% of the provisioned capacity for 5 consecutive minutes. Which TWO steps should they take? (Select TWO.)
⚠ Common exam trap
It's easy for candidates to confuse throttling metrics (like ReadThrottleEvents) with capacity utilization metrics, leading them to select Option B, which only detects throttling after it happens rather than providing a proactive alert based on capacity consumption.
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 to monitor the ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits metrics.
CloudWatch directly exposes the ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits metrics for DynamoDB, which are the exact metrics needed to calculate read capacity utilization. Monitoring these metrics allows the engineer to track how much of the provisioned capacity is being consumed over time, which is the foundation for setting up the desired alert.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable AWS CloudTrail to log DynamoDB read requests.
Why it's wrong here
AWS CloudTrail records API activity in DynamoDB, such as GetItem, Query, or Scan requests, but it is not designed to emit operational capacity metrics. CloudTrail is an auditing service that helps with security and compliance, not a real-time monitoring tool for read capacity utilization. Enabling CloudTrail data events would not give you the consumed versus provisioned units that indicate scaling needs.
- ✗
Set up an AWS Lambda function to monitor the DynamoDB ReadThrottleEvents metric.
Why it's wrong here
ReadThrottleEvents is a nonzero CloudWatch metric that DynamoDB emits only when requests are already being throttled due to insufficient provisioned capacity. A Lambda function that monitors this metric is fundamentally reactive: it fires after users have experienced throttled reads, meaning the alarm is too late to prevent service degradation. Proactive monitoring requires observing the consumption trend before it reaches the provisioned limit, which is why you need the ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits metrics instead.
- ✓
Use CloudWatch to monitor the ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits metrics.
Why this is correct
DynamoDB natively publishes ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits to CloudWatch at a one-minute granularity. Monitoring these metrics directly gives you a continuous view of how much read capacity is being used relative to what the table has provisioned. This is the foundational data source for any read-capacity alarm or scaling policy, and it lets you detect capacity pressure before throttling begins.
- ✗
Configure DynamoDB to stream all read events to CloudWatch Logs.
Why it's wrong here
DynamoDB does not have any built-in feature to stream read events to CloudWatch Logs; it only integrates with CloudWatch for metrics and with DynamoDB Streams for item-level changes. CloudWatch Logs can receive application-level logs, but the database service itself does not export every read request as a log entry. This option confuses CloudWatch Logs with the metric-based monitoring that DynamoDB actually supports, so it is not a valid approach.
- ✓
Create a CloudWatch alarm with a metric math expression that calculates (ConsumedReadCapacityUnits / ProvisionedReadCapacityUnits) and set the threshold to 0.8.
Why this is correct
This metric math expression computes the utilization ratio of consumed to provisioned read capacity at each evaluation period, giving a normalized percentage that is independent of the table's absolute throughput settings. Setting the alarm threshold to 0.8 creates a proactive early warning: before consumed capacity reaches 100% and throttling begins, you can trigger a scaling action or alert. Unlike a simple metric alarm, this ratio directly quantifies the risk of capacity exhaustion, making it a more operationally precise monitoring approach.
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.