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 CloudWatch Logs for the RDS instance and query the error log.

  Why it's wrong here

  The RDS error log, when published to CloudWatch Logs, captures connection errors, warnings, and startup/shutdown messages, not per-query latency or execution details. Querying it would reveal database-level faults but cannot surface which individual queries are causing slow API responses, nor show wait states or lock contention. Performance Insights is required to associate response degradation with specific SQL statements.

• ✗

  Install the CloudWatch agent on the EC2 instances to collect database performance counters.

  Why it's wrong here

  The CloudWatch agent runs on EC2 instances and reports guest OS metrics such as CPU, memory, and disk utilization; it cannot be installed on an RDS DB instance, which is a managed service. Even if installed on application servers, those counters reflect host health only and do not expose database engine internals like buffer pool hit ratios, wait events, or the SQL-level breakdown of database load. Therefore, it would not pinpoint the query or wait causing the slow API.

• ✓

  Enable Enhanced Monitoring and Performance Insights for the RDS instance.

  Why this is correct

  Enhanced Monitoring delivers OS-level metrics for the RDS host at up to one-second granularity, while Performance Insights provides database load per wait event, per SQL, and per host, enabling you to link slow API calls to specific queries and bottlenecks. Together they let you determine whether the issue is CPU saturation, storage I/O, lock waits, or a poorly performing statement, and then drill into the top SQL contributing to database load. This is the targeted diagnostic combination for an RDS-backed API performance problem.

• ✗

  Monitor the ALB's 'TargetResponseTime' metric and correlate with RDS 'CPUUtilization'.

  Why it's wrong here

  The ALB TargetResponseTime metric aggregates end-to-end latency of the API, which includes ALB, application, and network overhead, while RDS CPUUtilization is only a single utilization number that may be normal even when blocking locks, I/O wait, or row-lock contention is the real cause. Correlating these two curves can hint at a database dependency but cannot identify which query, transaction, or wait event is responsible, so it is insufficient for remediating the slow API.

Go deeper

Related to this question