20+ practice questions focused on Monitoring and Troubleshooting — one of the most tested topics on the AWS Certified Database Specialty DBS-C01 exam. Each question includes a detailed explanation so you learn why the right answer is correct.
Start Monitoring and Troubleshooting PracticeAn organization is using Amazon DynamoDB with on-demand capacity. They notice that the 'ThrottledRequests' metric is non-zero during a specific hour each day. The table stores session data and has a partition key of 'user_id'. The workload is uniform. What is the most likely cause of throttling?
Explanation: With on-demand capacity, throttling can occur when the account-level read/write capacity limit is exceeded, even with a uniform workload. The account-level limit (default 40,000 RCU or 40,000 WCU) applies across all on-demand tables in an AWS account. If the workload spikes during a specific hour, it may exceed this limit, causing throttling. Although per-partition limits exist (3,000 RCU or 1,000 WCU), a uniform workload means partition key distribution is even, so hot partitions are unlikely. Thus, the most likely cause is the account-level limit being reached.
You are managing an Amazon RDS for PostgreSQL Multi-AZ DB instance that handles a high-traffic e-commerce application. Recently, the database has been experiencing intermittent slowdowns during peak hours. You have enabled Enhanced Monitoring and Performance Insights. After reviewing the Performance Insights dashboard, you notice that the 'db.sql.queries.avg_latency' metric spikes during the slowdowns, and the top SQL queries are all simple SELECT statements on a frequently accessed 'orders' table. The table has over 10 million rows and is indexed on 'order_id', 'customer_id', and 'order_date'. The average query latency for these SELECT statements jumps from 5 ms to over 500 ms during the spikes. You also observe that the 'ReadIOPS' metric on the DB instance is consistently below the provisioned IOPS limit of the gp2 storage. The DB instance type is db.r5.large with 16 GB memory. The 'DatabaseConnections' metric shows that the number of connections is well within the max_connections limit (set to 200). However, the 'CPUCreditBalance' for the underlying EC2 instance, which is a T3 medium, drops to near zero during the spikes. The 'CPUUtilization' metric is below 50%. Which of the following is the MOST likely cause and the appropriate action to resolve the issue?
Explanation: The issue is caused by a missing composite index on the 'orders' table. Although single-column indexes exist on 'order_id', 'customer_id', and 'order_date', the simple SELECT statements likely filter on multiple columns simultaneously, forcing the database to use a single index and then perform additional filtering in memory, resulting in high latency. Adding a composite index on the columns used in the WHERE clauses (e.g., (customer_id, order_date)) allows index-only scans and eliminates unnecessary processing. The other options are inconsistent with the symptoms: the instance is already a dedicated CPU type (db.r5.large), so CPU credit exhaustion does not apply; memory and connection metrics show no bottleneck.
A company is running a production Amazon RDS for Oracle DB instance. The database specialist is setting up monitoring to detect and troubleshoot performance issues. Which TWO metrics should be used to identify whether the database is experiencing I/O bottlenecks?
Explanation: The correct answers are ReadLatency (C) and WriteLatency (D). These metrics directly measure the time taken for I/O operations; high values indicate I/O bottlenecks. Option A (DatabaseConnections) measures the number of connections, not I/O performance. Option B (CPUUtilization) measures CPU usage, which can be high for many reasons, not necessarily I/O. Option E (FreeStorageSpace) indicates storage capacity, not performance. Therefore, only C and D are correct.
A company is troubleshooting a performance issue with an Amazon RDS for MariaDB instance. The CloudWatch metric 'ReadIOPS' is consistently high, but 'WriteIOPS' is low. Which TWO actions could help improve read performance?
Explanation: (Add a read replica) offloads read queries from the primary instance, reducing read IOPS. Option D (Increase the DB instance class to one with more memory) can improve caching (e.g., InnoDB buffer pool), reducing disk reads. Option B (Increase allocated storage) may increase baseline IOPS but not directly address read performance. Option C (Use Amazon ElastiCache) is a valid caching solution but not specific to RDS and is not one of the two best actions. Option E (Enable Multi-AZ) enhances availability but does not improve read performance, as the standby replica is not used for reads.
A team is troubleshooting an Amazon Aurora MySQL cluster where the writer instance fails over unexpectedly every few days. The failover is not triggered by manual intervention or maintenance events. CloudWatch metrics show that the failover occurs when the replica lag on the reader instances spikes to over 10 seconds. What is the MOST likely cause of the failover?
Explanation: If reader instances are under-provisioned, they cannot apply changes from the writer fast enough, leading to replica lag. This replica lag can cause the system to initiate a failover if it exceeds a threshold, as the writer may be deemed unhealthy due to the inability of readers to keep up. Option A is incorrect because over-provisioned reader instances would have ample resources and would not cause replica lag; idle connections do not trigger failovers. Option B is incorrect because a storage subsystem bottleneck in a single Availability Zone is unlikely in Aurora, which uses shared storage across three AZs; even if it occurred, it would affect both writer and readers equally, not specifically cause writer failover. Option C is incorrect because in Aurora, replication is at the storage layer and is not blocked by long-running transactions on the writer. Such transactions do not directly cause replica lag on readers.
+15 more Monitoring and Troubleshooting questions available
Practice all Monitoring and Troubleshooting questions1. Baseline your knowledge
Start with 10 questions to gauge your current understanding of Monitoring and Troubleshooting. This tells you whether you need a concept refresher or just practice.
2. Review every explanation
For each question — right or wrong — read the full explanation. Understanding why an answer is correct is more valuable than knowing the answer itself.
3. Focus on exam traps
Monitoring and Troubleshooting questions on the DBS-C01 frequently use trap wording. Look for subtle differences in answers that test your precision, not just general knowledge.
4. Reach 80% consistently
Do repeated sessions until you score 80%+ three times in a row. Then move to mixed-mode practice to test cross-topic recall under realistic conditions.
The exact number varies per candidate. Monitoring and Troubleshooting is tested as part of the AWS Certified Database Specialty DBS-C01 blueprint. Practicing with targeted Monitoring and Troubleshooting questions ensures you can handle any format or difficulty that appears.
Yes. Courseiva provides free DBS-C01 practice questions across all exam topics and domains. The platform includes topic-based practice, mock exams, missed-question review, bookmarked questions, and readiness tracking — no account required.
Difficulty is subjective, but Monitoring and Troubleshooting is a high-priority exam concept tested in multiple ways — direct recall, scenario analysis, and command-output interpretation. Consistent practice is the best way to build confidence.
Launch a full Monitoring and Troubleshooting practice session with instant scoring and detailed explanations.
Start Monitoring and Troubleshooting Practice →