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.

• ✗

  CloudWatch Logs Insights and CloudWatch metrics.

  Why it's wrong here

  CloudWatch Logs Insights requires streaming database engine logs such as the MySQL slow query log to a log group, which only captures queries that exceed long_query_time and omits every SQL statement outside your configured thresholds. CloudWatch metrics from RDS are aggregated at the instance level and show averages, percentiles, and counts for native metrics like CPU and free memory, but they cannot drill into per-statement wait events or execution plans. Consequently this pairing lacks the query-level granularity needed to pinpoint the exact SQL causing the bottleneck.

• ✓

  Amazon RDS Performance Insights and Enhanced Monitoring.

  Why this is correct

  RDS Performance Insights computes a Database Load metric in 'average active sessions' and breaks it down by wait state, host, and individual SQL statement, so you can immediately rank queries by their contribution to the bottleneck. Enhanced Monitoring supplements this by gathering hypervisor and operating-system metrics (CPU, memory, file descriptor pressure, and network throughput) at one-second to one-minute intervals through a separate agent on the RDS instance. Together they reveal not only which query is responsible, but whether the root cause is CPU saturation, memory contention, or disk I/O, enabling a targeted fix such as adding an index or scaling the instance class.

• ✗

  VPC Flow Logs and Lambda.

  Why it's wrong here

  VPC Flow Logs capture IP traffic metadata at the Elastic Network Interface level, recording protocol, source/destination addresses, ports, packet counts, and byte counts, but they never expose SQL text, parameterized query strings, or database wait events. A Lambda function consuming these logs can aggregate traffic volume or identify anomalous connection patterns, but it cannot attribute a slow response to a specific SELECT or JOIN, nor can it represent resource waits inside the RDS instance. Therefore flow logs are useful for network-layer troubleshooting but fundamentally blind to query-performance diagnosis.

• ✗

  CloudTrail and CloudWatch alarms.

  Why it's wrong here

  CloudTrail records control-plane API calls that create, modify, or stop RDS instances, such as ModifyDBInstance or RebootDBInstance, along with the calling IAM principal and source IP, but it does not intercept data-plane SQL operations executed by your application against the database engine. CloudWatch alarms can monitor CloudTrail events like unauthorized access attempts or instance status changes, but they contain no execution statistics for queries because those are engine internal, not emitted as AWS API calls. Thus this combination would never surface the specific slow-running statement that is causing the performance issue.

Go deeper

Related to this question