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.

• ✗

  Enable DynamoDB Accelerator (DAX) to reduce latency.

  Why it's wrong here

  DAX is a purpose-built in-memory caching service for DynamoDB designed to reduce read latency, not to provide observability. It adds a cache layer that accelerates hot-key reads but emits no metrics or trace data about API errors, Lambda failures, or end-to-end request latency. Deploying DAX would add cost and operational overhead without giving the DevOps team any monitoring or alerting capability, so it does not address the requirement to detect errors and latency.

• ✗

  Enable detailed billing metrics for cost analysis.

  Why it's wrong here

  Detailed billing metrics in Cost Explorer / AWS Cost and Usage are focused on cost allocation, chargeback, and spend trend analysis by service, region, or tag. They reveal how much money a workload consumes, but they expose no operational signals such as Lambda error counts, API Gateway 5XX responses, or latency percentiles. Even if a spike in spend could indirectly hint at an anomaly, these metrics are not a real-time monitoring tool and cannot be used to set fine-grained alarms on error rates or request performance.

• ✗

  Configure CloudWatch Logs for DynamoDB.

  Why it's wrong here

  DynamoDB is a managed database service that does natively publish many metrics to CloudWatch (e.g., ConsumedReadCapacityUnits, ThrottledRequests, SystemErrors), but it does not send operational logs such as query text or user activity to CloudWatch Logs. While CloudTrail can capture data plane and control plane API calls, the resulting JSON logs go to S3 or CloudWatch Logs only if explicitly configured, and that tracks API activity rather than latency or errors. Therefore, simply configuring CloudWatch Logs for DynamoDB is a false premise because no such native log stream exists for the database engine itself.

• ✓

  Enable AWS X-Ray tracing on API Gateway and Lambda.

  Why this is correct

  AWS X-Ray traces requests end-to-end from API Gateway to Lambda and downstream services like DynamoDB, capturing segments, sub-segments, and annotations that reveal where latency is consumed and which component is returning errors. By enabling X-Ray on API Gateway and Lambda, the DevOps engineer can inspect trace timelines, service maps, and error rates per operation to pinpoint performance bottlenecks and failed invocations. This provides correlated, request-level observability that CloudWatch aggregate metrics alone cannot offer, making it a correct component of a comprehensive monitoring solution.

• ✓

  Set up CloudWatch Alarms on Lambda error count and API Gateway 5XX count.

  Why this is correct

  CloudWatch Alarms can be configured on the automatically published metrics LambdaError and ApiGateway 5XXError, triggering SNS notifications or auto-remediation actions when thresholds are breached. Since these metrics represent real invocation failures and upstream client errors, alarms give the DevOps team immediate operational feedback on system health. However, while these alarms detect that errors exist, they do not explain why a specific request failed or where the latency is introduced, so they complement X-Ray rather than replace it.

Go deeper

Related to this question