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.

• ✗

  Create an RDS event subscription for 'low storage' events.

  Why it's wrong here

  RDS event subscriptions deliver SNS notifications for operational database events such as storage capacity thresholds, failover status, or maintenance windows, not for individual query execution. A 'low storage' event indicates disk space pressure, which may indirectly affect performance but does not reveal which SQL statements are slow or why. Because event notifications lack SQL text, duration, and execution plans, they cannot help diagnose specific slow queries, even if storage issues exist.

• ✗

  Monitor the 'CPUUtilization' metric in CloudWatch.

  Why it's wrong here

  CloudWatch's CPUUtilization metric is an aggregated instance-level gauge showing the average percentage of CPU consumed by all database sessions combined. While sustained high CPU can accompany slow query problems, this metric cannot identify any individual query, its SQL text, its execution time, or its frequency. It provides a signal that the database is resource-constrained but leaves you guessing which statements to tune, so it is insufficient as a primary tool for pinpointing slow queries.

• ✓

  Enable the slow query log and publish it to CloudWatch Logs.

  Why this is correct

  Enabling the RDS slow query log captures every SQL statement whose execution exceeds the configured long_query_time threshold, recording details like query text, execution duration, rows examined, and timestamps. By publishing these log events to CloudWatch Logs, you gain a searchable, historical record that can be queried with CloudWatch Logs Insights to filter for the slowest statements, identify patterns, and correlate with other metrics. This directly exposes the exact SQL causing performance issues, making it a definitive diagnostic method for slow query analysis.

• ✓

  Enable Performance Insights to visualize database load and identify top SQL statements.

  Why this is correct

  Performance Insights continuously samples database load in units of Average Active Sessions (AAS) and breaks it down by dimensions such as SQL statement, wait event, and host. Its top SQL panel instantly surfaces the queries contributing the most load, along with corresponding wait events like CPU, disk I/O, or lock waits, enabling you to visualize where time is spent. Unlike logs, it provides real-time, interactive drill-down without requiring thresholds or log configuration, making it ideal for identifying problematic top queries during an active incident.

• ✗

  Enable Enhanced Monitoring to view process list and SQL queries.

  Why it's wrong here

  Enhanced Monitoring uses a lightweight OS-level agent on the RDS host to report granular metrics such as CPU utilization, memory pressure, disk I/O, networking, and a process list at intervals as short as one second. While the process list shows the names and resource usage of OS processes (e.g., mysqld or postgres), it does not reveal the SQL text being executed or per-query statistics like execution time or rows scanned. Therefore, it cannot tell you which specific query is slow; it only hints at whether the instance itself is operating under resource stress.

Go deeper

Related to this question