DBS-C01 Monitoring and Troubleshooting Practice Test 7 — 15 Questions

Question 1

A company uses Amazon DocumentDB (with MongoDB compatibility) for its application. The application is experiencing high write latency. The DB cluster has one primary instance and two replicas. Which action should be taken to identify the cause?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Enable Enhanced Monitoring and review OS-level metrics like CPU, memory, and I/O.. High write latency on a DocumentDB cluster points to resource contention or storage-level bottlenecks on the primary instance, since all writes go to the primary. Enhanced Monitoring exposes OS-level metrics (CPU, memory, disk I/O, swap) at up to 1-second granularity via CloudWatch, which is exactly what's needed to pinpoint whether the primary is CPU-bound, I/O-bound, or memory-starved. Slow query logging is useful for read-heavy query tuning but does not surface the OS-level resource saturation that typically drives write latency.

Answer

Migrate the database to Amazon DynamoDB for better write performance.

Answer

Add more read replicas to distribute the load.

Answer

Enable slow query logging and analyze slow queries.

Question 2

A company's Amazon Redshift cluster is experiencing slow query performance. The cluster has three nodes. The administrator wants to identify if the issue is due to data distribution skew. Which approach should be used?

Accepted Answer

Query the STV_SLICES table to compare disk usage across slices.. STV_SLICES shows disk space usage per slice on each node, which directly reveals data distribution skew. If some slices have much higher disk usage than others, the data is skewed, causing uneven query processing and slow performance. This is the correct table to diagnose distribution skew.

Answer

Examine the STL_QUERY table to analyze query execution times.

Answer

Check the STV_WLM_SERVICE_STATE table to see current queue state.

Answer

Review CloudWatch metrics for CPUUtilization per node.

Question 3

A company uses Amazon RDS for SQL Server with Multi-AZ deployment. During a failover test, the application experienced a longer downtime than expected. Which monitoring metric should be reviewed to understand the failover duration?

Accepted Answer

DatabaseConnections. The DatabaseConnections metric in Amazon CloudWatch tracks the number of active database connections. During a Multi-AZ failover, existing connections are dropped and new connections are blocked until the standby becomes the primary. By monitoring the time period when DatabaseConnections drops to zero or a low value, you can estimate the failover duration. Options A (FailoverTime) is not a valid CloudWatch metric for RDS; the actual metric is 'Failover' which is a count, not a duration. WriteLatency may increase during failover but does not directly measure downtime. ReplicaLag applies to read replicas, not Multi-AZ failover.

Answer

FailoverTime

Answer

WriteLatency

Answer

ReplicaLag

Question 4

Which THREE metrics should be monitored to troubleshoot a slow Amazon Redshift query? (Choose three.)

Accepted Answer

DiskSpaceUsage. Options B, C, and D are correct. DiskSpaceUsage can indicate disk spills that slow queries, WLMQueueWaitTime measures time queries wait in a queue, and QueryDuration directly measures execution time. Option A (DatabaseConnections) tracks connection count, not query performance. Option E (NetworkThroughput) measures network throughput, which is not directly related to query slowness.

Answer

DatabaseConnections

Answer

NetworkThroughput

Question 5

Which TWO actions should be taken to troubleshoot high memory usage on an Amazon ElastiCache for Redis node? (Choose two.)

Accepted Answer

Monitor the Evictions CloudWatch metric.. Monitoring the Evictions CloudWatch metric is the only valid action among the options for troubleshooting high memory usage on an Amazon ElastiCache for Redis node. Option B is incorrect because the maxmemory parameter is determined by the node type and cannot be increased; it is fixed. Options C, D, and E are not direct troubleshooting steps for memory pressure. Option C monitors CPU, not memory. Option D (enabling cluster mode) is a scaling action, not a troubleshooting step for an existing node. Option E (Reserved Memory) is a preventive setting but not a primary troubleshooting action.

Answer

Increase the maxmemory parameter to allow more memory usage.

Answer

Monitor CPUUtilization CloudWatch metric.

Answer

Enable cluster mode to distribute memory across shards.

Answer

Enable Reserved Memory parameter group setting.

Question 6

A company is using Amazon RDS for MySQL with Multi-AZ deployment. The database experiences a sudden increase in latency and the application reports timeouts. CloudWatch shows elevated 'ReadLatency' and 'WriteLatency' metrics, while 'CPUUtilization' and 'DatabaseConnections' remain normal. Which is the MOST likely cause?

Accepted Answer

A large transaction is being processed. A large transaction can cause increased latency without high CPU or connection count, as it may be waiting on disk I/O or replication. Option A is wrong because a runaway query consuming CPU would show elevated CPUUtilization, which is normal. Option B is wrong because a Multi-AZ failover would cause a brief spike in latency followed by recovery, not sustained latency. Option D is wrong because insufficient provisioned IOPS would typically show BurstBalance or IOPS metrics, not just ReadLatency and WriteLatency.

Answer

A runaway query is consuming CPU resources

Answer

A Multi-AZ failover occurred

Answer

The database has insufficient provisioned IOPS

Question 7

A developer reports that an Amazon RDS for PostgreSQL database instance's storage is full and the instance is in 'storage-full' state. The team wants to resolve this without downtime. Which action should be taken?

Accepted Answer

Modify the DB instance to increase allocated storage. Modifying the DB instance to increase allocated storage is the correct action because Amazon RDS supports storage scaling without downtime for most engines, including PostgreSQL. This operation can be performed while the instance is running, and the additional storage becomes available immediately after the modification completes, resolving the 'storage-full' state.

Answer

Create a read replica and promote it

Answer

Delete old automated snapshots

Answer

Reboot the DB instance

Question 8

A company uses Amazon DynamoDB Global Tables with strong consistent reads. They notice that a write to us-east-1 is not visible in eu-west-1 after several seconds. Which configuration setting is MOST likely causing this behavior?

Accepted Answer

DynamoDB Streams is not enabled on the table. DynamoDB Global Tables require DynamoDB Streams to be enabled on the table. If streams are disabled, write operations in one region will not be replicated to other regions, causing the writes to never become visible. This matches the symptom of writes not appearing after several seconds. Option B (Auto Scaling) does not affect replication. Option C (LWW conflict resolution) is enabled by default and does not cause delays. Option D (strongly consistent reads) are not supported on Global Tables and would generate an error, not a delay.

Answer

Auto Scaling is configured for write capacity

Answer

Last writer wins (LWW) conflict resolution is disabled

Answer

Strongly consistent reads are used on a global table

Question 9

A company runs a critical application on Amazon RDS for PostgreSQL. The application team reports that the database occasionally becomes unresponsive for a few seconds. CloudWatch metrics show 'CPUSurplusCreditsCharged' and 'CPUSurplusCredits' are not 0. The instance is a db.t3.medium. What is the likely cause and how should it be fixed?

Accepted Answer

The instance is out of CPU credits and is being throttled; switch to a larger or non-burstable instance. The CloudWatch metrics CPUSurplusCreditsCharged and CPUSurplusCredits being non-zero indicate the db.t3.medium burstable instance has exhausted its CPU credits and is now paying surplus credits, which can lead to throttling and the observed unresponsiveness. The fix is to move to a larger burstable instance or a non-burstable instance class so the workload has sustained CPU capacity.

Answer

Enable Enhanced Monitoring to diagnose the issue

Answer

Increase the allocated storage to improve I/O

Answer

The instance is experiencing a failover; enable Multi-AZ

Question 10

A company is troubleshooting an Amazon DynamoDB table that is throttling write requests. The table has a partition key ('userId') and a sort key ('timestamp'). The 'WriteCapacityUnits' is set to 1000. CloudWatch shows 'ThrottledWriteRequests' but the 'ConsumedWriteCapacityUnits' is only 500. Which TWO actions could resolve the throttling?

Accepted Answer

Add a random suffix to the partition key to distribute writes more evenly. Option A is correct because the throttling occurs even though ConsumedWriteCapacityUnits (500) is below the provisioned 1000 WCU, which indicates a hot partition: writes are concentrated on a small number of partition key values, so adding a random suffix to 'userId' spreads the writes across more partitions and lets the table actually use its provisioned capacity. Option C is correct because raising the write capacity units increases the total throughput ceiling available to the table, so even with uneven access patterns the per-partition limits are less likely to be hit and the throttled write requests can be absorbed. Option B is not correct because DAX caches reads, not writes, so it cannot relieve write throttling. Option D is not correct because Global Tables replicate writes to other regions but do not increase the local write throughput or fix a hot partition. Option E is not correct because removing the sort key does not change the partition key distribution and would not resolve the hot-partition throttling.

Answer

Enable DynamoDB Accelerator (DAX) to cache writes

Answer

Enable Global Tables to replicate writes across regions

Answer

Remove the sort key and use only a partition key

Question 11

A database administrator is monitoring an Amazon RDS for MySQL instance and sees the following CloudWatch metrics: 'DiskQueueDepth' is consistently at 10, 'WriteLatency' is 20 ms, 'FreeStorageSpace' is less than 10% of total. The instance uses gp2 storage. Which THREE actions should be taken to improve performance?

Accepted Answer

Switch to Provisioned IOPS (io1 or io2) for consistent performance. Option A is correct because gp2 storage performance is tied to volume size via burst credits, and switching to Provisioned IOPS (io1/io2) provides dedicated, consistent IOPS independent of volume size, directly addressing the sustained DiskQueueDepth of 10 and 20 ms WriteLatency. Option B is correct because increasing allocated storage on gp2 raises the baseline IOPS (3 IOPS per GiB) and burst credit ceiling, which alleviates the queue depth and write latency caused by insufficient IOPS. Option C is correct because FreeStorageSpace is below 10%, and freeing space prevents the volume from filling, which would otherwise degrade performance and risk storage-full events; it also complements the gp2 IOPS-to-size relationship. Option D is not correct because Multi-AZ provides high availability through synchronous standby replication, not additional I/O capacity for the primary. Option E is not correct because Performance Insights is a diagnostic/monitoring tool that helps identify slow queries but does not itself improve I/O performance.

Answer

Enable Multi-AZ to increase I/O capacity

Answer

Enable Performance Insights to identify slow queries

Question 12

A company uses Amazon Redshift and notices that queries are taking longer than usual. CloudWatch metrics show 'CPUUtilization' is high and 'DiskSpace' is low. Which TWO actions can help improve query performance?

Accepted Answer

Add more nodes to the cluster. Option B is correct because adding more nodes to the Redshift cluster horizontally scales compute and storage capacity, distributing the query workload across additional slices so that high CPUUtilization is reduced and queries complete faster. Option E is correct because optimizing sort keys aligns data on disk with query predicates, enabling zone maps to skip irrelevant blocks and reducing the amount of data scanned, which lowers CPU and I/O pressure. Option A is wrong because disabling concurrency scaling removes the ability to offload burst workloads to transient clusters, which would typically hurt rather than help performance. Option C is wrong because Multi-AZ in Redshift is a high-availability/disaster-recovery feature that provides a standby cluster, not a mechanism for distributing read/query load. Option D is wrong because VACUUM reclaims space and re-sorts rows, but the scenario shows low DiskSpace, not bloated tables, and VACUUM alone does not address high CPU from poorly chosen sort keys.

Answer

Disable concurrency scaling to free resources

Answer

Enable Multi-AZ to distribute load

Answer

Run VACUUM to reclaim space

Question 13

A company is using Amazon RDS for MySQL with Multi-AZ deployment. The application team reports that write latency has increased significantly over the past hour. CloudWatch shows elevated 'ReadLatency' and 'WriteLatency' metrics. The DB instance is a db.r5.large with 500 GB General Purpose SSD (gp2) storage. Which action is most likely to resolve the issue?

Accepted Answer

Increase the allocated storage size to 1,000 GB. The correct action is C: increase the allocated storage size to 1,000 GB, because with gp2 storage, IOPS scale with volume size (3 IOPS per GB, up to 16,000), so a 500 GB gp2 volume provides only 1,500 baseline IOPS, and doubling to 1,000 GB raises baseline IOPS to 3,000, directly addressing the elevated ReadLatency and WriteLatency caused by storage throughput saturation. Multi-AZ is already enabled per the scenario, so option A is redundant and would not change performance. A read replica (B) only offloads read traffic and does not improve write latency on the primary. Scaling the instance class (D) adds CPU/RAM but does not increase the EBS-backed storage IOPS ceiling that gp2 ties to volume size, so it is less likely to resolve the bottleneck.

Answer

Enable Multi-AZ deployment

Answer

Create a read replica to offload read traffic

Answer

Scale up the DB instance class to db.r5.xlarge

Question 14

A DevOps engineer notices that an Amazon RDS for PostgreSQL instance has been in 'storage-full' state for the past 30 minutes. The instance has 500 GB of General Purpose SSD (gp2) storage, and the free storage space is 0 bytes. The database is critical and cannot tolerate downtime. What is the MOST efficient way to resolve this issue while minimizing downtime?

Accepted Answer

Modify the DB instance to increase allocated storage to 1,000 GB. The correct action is to modify the DB instance to increase allocated storage to 1,000 GB. For Amazon RDS, storage can be scaled up dynamically without downtime; the change typically takes effect within minutes and the instance remains available. This directly addresses the immediate storage-full condition by providing additional capacity, allowing the database to continue operating. Other options either require downtime, are not immediate, or do not resolve the root cause efficiently.

Answer

Take a snapshot of the DB instance and restore it to a new instance with larger storage

Answer

Enable storage auto-scaling on the DB instance

Answer

Delete unnecessary data, such as old logs or temporary tables

Question 15

A company has an Amazon Aurora MySQL DB cluster with one writer and two readers. The application is experiencing high read latency. CloudWatch shows that the 'AuroraBinlogReplicaLag' metric is high for one of the reader instances. What is the most likely cause?

Accepted Answer

The reader instance is not keeping up with the write workload from the writer. The 'AuroraBinlogReplicaLag' metric measures the lag between the writer and a reader when using binary log replication. A high value indicates that the reader is not applying changes from the writer quickly enough, causing read latency. This is typically because the reader instance is not keeping up with the write workload from the writer. Option A is incorrect because Aurora storage is shared and not the cause of replication lag. Option C is incorrect; while an undersized reader can contribute to lag, the primary cause is the reader not keeping pace with writes, not necessarily size. Option D is incorrect because parameter groups affect settings but not replication lag directly.

Answer

The Aurora cluster storage is experiencing high I/O latency

Answer

The reader instance is undersized and needs to be scaled up

Answer

The DB cluster parameter group is misconfigured