CCNA Monitor and optimize database performance Questions

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because rewriting queries to use fewer joins and aggregations might reduce complexity but does not guarantee performance improvements if the underlying slot contention is the root cause; it also requires significant development effort and may not fully resolve timeouts under high concurrency. Option C is wrong because simply increasing total slots to 2000 does not prioritize the dashboard queries; ad-hoc queries could still consume all slots, leading to the same contention and timeout issue. Option D is wrong because scheduling the dashboard refresh at a different time only avoids the conflict temporarily and does not solve the fundamental slot contention problem; it also may not be feasible if the dashboard requires hourly updates.

Why this answer

How to eliminate wrong answers

Option A is wrong because Query Insights focuses on analyzing query performance, such as latency and execution plans, not on visualizing key-level access patterns to detect hot spots. Option C is wrong because Cloud Trace is a distributed tracing tool for latency analysis of requests across services, not for identifying hot keys in a database. Option D is wrong because Cloud Monitoring provides metrics and alerting for overall system health and performance, but lacks the key-space heatmap visualization required to pinpoint hot spots in Cloud Spanner.

Why this answer

How to eliminate wrong answers

Option A is wrong because flushing the cache periodically removes all data, which would drastically reduce the hit ratio and increase load on the database, the opposite of the desired effect. Option C is wrong because enabling persistence (e.g., RDB snapshots or AOF logs) protects against data loss on restart but does not influence how long data remains in the cache or the hit ratio. Option D is wrong because increasing instance memory size only delays evictions under the maxmemory-policy; if the TTL is too short, data still expires quickly and the hit ratio remains low regardless of memory size.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because 'received_bytes_count' measures network throughput, not connection count; a spike in bytes could be due to large queries or data transfers, not necessarily a connection spike. Option B is wrong because 'seconds_behind_master' is a replication lag metric relevant only for read replicas, not for correlating connection spikes with performance degradation on the primary instance. Option C is wrong because 'instance/uptime' only indicates restarts, which are not directly caused by connection spikes; performance degradation can occur without any instance restart.

Why this answer

How to eliminate wrong answers

Option B is wrong because Cloud Logging captures raw log entries and events but does not provide aggregated query-level performance metrics or resource consumption analysis for Cloud Spanner. Option C is wrong because the Performance Dashboard in Google Cloud Console offers a high-level overview of database metrics like latency and throughput, but it lacks the per-query breakdown and resource attribution needed to identify specific resource-heavy queries. Option D is wrong because Cloud Monitoring metrics provide system-level metrics (e.g., CPU utilization, storage) but do not offer query-level insights or the ability to sort and analyze individual query performance.

Why this answer

How to eliminate wrong answers

Option A is wrong because too many column families do not cause write hotspotting; they affect storage and read performance, not write distribution. Option B is wrong because inefficient reads (e.g., full scans) are a read-side issue, not a cause of high write latency; reverse scan is a read optimization, not a write fix. Option D is wrong because misconfigured tablet splits or pre-splitting addresses initial distribution, but the root cause here is the key design pattern, not split configuration; even with pre-splits, monotonically increasing keys will still hotspot writes to the last tablet.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the absence of an ORDER BY clause does not cause a query to take a long time; it merely affects the order of results, not the scan method. Option B is wrong because interleaving (table interleaving in Cloud Spanner) is a design pattern that can improve performance by co-locating parent and child rows; it does not inherently cause extra I/O and is not relevant to a simple filter on a non-key column. Option C is wrong because the primary key is already defined; the issue is that the query predicate does not match the primary key order, so the primary key cannot be used efficiently for this filter.

Why this answer

How to eliminate wrong answers

Option A is wrong because a primary key index on `Users(Email)` would require `Email` to be the primary key, which is not necessarily the case; the primary key might be `UserId`, and adding a primary key on `Email` could change table structure and is not the missing index for a simple lookup. Option C is wrong because a composite index on `Users(Email, UserId)` is overkill; the query only filters on `Email`, so a single-column index on `Email` suffices, and a composite index may be larger and less efficient for this specific query. Option D is wrong because relying on a full table scan is inefficient and does not guarantee a row is returned if the table is large or the query plan uses a scan that skips the row due to concurrency or statistics; an index is needed for reliable, fast access.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because adding a secondary index on `user_id` does not help queries that filter only on `transaction_id`; it would only be useful if queries filtered on `user_id` alone or in combination with `transaction_id`. Option C is wrong because a query hint to force a specific index scan is unnecessary and ineffective if no suitable index exists; the hint cannot create an index that doesn't exist, and without an index on `transaction_id`, Spanner would still perform a full scan. Option D is wrong because changing the primary key to `(transaction_id, user_id)` would require a costly schema change and data migration, and it would break the interleaved table structure with the parent `users` table, which expects `user_id` as the first part of the primary key for interleaving.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because secondary indexes on join columns do not change the physical co-location of parent and child rows; they only provide an alternative access path, and queries may still require distributed joins across splits, which is the root cause of slowness. Option C is wrong because batch update operations reduce round trips for writes, not for read-heavy join queries; they do not address the physical data layout needed for efficient joins. Option D is wrong because removing interleaving would break the physical co-location guarantee, forcing Spanner to perform distributed cross-split joins, which would make queries even slower, not faster.

Why this answer

How to eliminate wrong answers

Option A is wrong because materialized views reduce the amount of data scanned and recomputation for repeated aggregations, but they do not increase the available slot capacity; if the query is already hitting 100% slot usage, the bottleneck is compute resources, not data volume. Option C is wrong because clustering improves data pruning and scan efficiency for filtered queries, but it does not add more slots; the query will still be throttled by the fixed slot pool. Option D is wrong because partitioning reduces the amount of data read by date range filters, but like clustering, it does not address the root cause of slot exhaustion; the query will still run at the same slot limit.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing the machine type adds cost and masks the underlying issue without diagnosing why CPU spikes occur; it treats a symptom, not the cause. Option B is wrong because enabling connection pooling reduces connection overhead but does not address CPU spikes or query performance; it may even hide connection-related issues without solving the root cause. Option D is wrong because setting a maximum connection limit or reducing connection lifetime can cause application errors or dropped connections without identifying why connections are increasing or why CPU is spiking.

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing the buffer pool size only caches more data in memory, which may reduce physical I/O but does not eliminate the logical I/O caused by key lookups; the query still performs the same number of page accesses. Option B is wrong because rebuilding the index with FILLFACTOR=80 reduces page splits and fragmentation but does not change the index structure to include additional columns, so key lookups still occur. Option D is wrong because using a FORCESEEK query hint forces the optimizer to use an index seek, but it does not prevent key lookups if the index does not cover all required columns; it may even degrade performance by forcing a suboptimal plan.

Why this answer

How to eliminate wrong answers

Option A is wrong because the slow query log in Cloud Logging requires manual filtering and may not be enabled by default, whereas Query Insights provides immediate, structured visibility into high-latency queries. Option C is wrong because increasing the instance tier only masks the symptom by adding more resources, without identifying or fixing the underlying problematic queries. Option D is wrong because enabling the general query log generates excessive volume and performance overhead, and parsing it manually is inefficient compared to using Query Insights' built-in analysis.

Why this answer

How to eliminate wrong answers

Option B is wrong because interleaved tables optimize joins and hierarchical data access, not point reads by a non-primary-key column. Option C is wrong because reordering the primary key to (OrderDate, CustomerID) would break existing data distribution and still not optimize reads by CustomerID alone, as OrderDate would still be required for efficient lookups. Option D is wrong because increasing nodes improves throughput and capacity, not the fundamental latency of point reads caused by missing index support.

Why this answer

How to eliminate wrong answers

Option A is wrong because connection pooling reduces the overhead of establishing new database connections, but it does not reduce the CPU cost of executing the read-heavy queries themselves; the same number of queries still run on the same instance. Option B is wrong because increasing memory size can improve cache hit ratios and reduce disk I/O, but it does not directly lower CPU usage from query execution; CPU-bound workloads are not resolved by adding memory. Option D is wrong because automatic storage increase only prevents out-of-disk errors by expanding disk capacity; it has no effect on CPU utilization or query processing load.

Why this answer

How to eliminate wrong answers

Option A is wrong because adding more memory to increase the cache hit ratio addresses local cache misses, not high network latency; CPU utilization is below 30%, indicating no memory pressure. Option B is wrong because increasing vCPUs handles more concurrent connections, but the problem is network latency, not CPU or connection bottlenecks. Option D is wrong because migrating to Cloud Spanner is a costly and complex operation that involves changing the database paradigm from relational to globally distributed, which is overkill for a simple latency issue that can be solved with read replicas.

Why this answer

How to eliminate wrong answers

Option A is wrong because high network latency would manifest as increased client-side wait times and not as high row scan counts or CPU usage within the Spanner backend; Query Insights metrics focus on database-side execution, not network round trips. Option B is wrong because a full table scan is a symptom, not the root cause—the underlying reason for the full scan is the missing index on customer_id, making B a description of the effect rather than the most likely performance issue. Option C is wrong because an inefficient join would show high join-related metrics like rows returned from join operations or skewed distribution, but the exhibit does not indicate any join operations; the query appears to be a simple filter on a single table.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because multi-region replication improves availability and latency for global reads, but the database is single-location (us-central1) and read count hasn't changed; the issue is query efficiency, not geographic distribution. Option B is wrong because Firestore is a NoSQL document database that does not require defragmentation or compaction; such operations are for traditional relational databases or storage engines like LevelDB. Option C is wrong because Datastore mode is a legacy mode with different consistency and scaling characteristics; migrating would not resolve latency caused by missing composite indexes and could introduce compatibility issues.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a limit of 10 is not inherently too high; the excessive reads are due to the lack of a composite index, not the limit value. Option B is wrong because the query is not scanning all posts if a single-field index on `author` exists, but it still reads all documents for that author and sorts in memory, which is inefficient. Option C is wrong because the index on `timestamp` does not need to be descending; Firestore can reverse the sort order at query time as long as a composite index on `(author, timestamp)` exists, and the issue is the missing composite index, not the direction of the single-field index.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because Fine-Grained Latency & Replication (FLLR) is a feature for reducing read latency by placing replicas closer to users, not for improving write throughput or CPU-bound write latency; writes still require a quorum across all replicas. Option B is wrong because disabling client-side buffering would increase the number of round trips and likely worsen latency, as buffering helps batch writes and reduce overhead; the issue is server-side CPU saturation, not client-side batching. Option D is wrong because reducing transaction size by batching fewer mutations per transaction would increase the total number of transactions, potentially raising CPU overhead and commit latency further, and the current 50ms commit latency is already high for small score updates.

Why this answer

How to eliminate wrong answers

Option A is wrong because enabling AOF persistence with fsync every second adds disk I/O overhead, which can increase latency rather than reduce it, and does not address the memory pressure causing evictions. Option B is wrong because changing the maxmemory-policy to 'volatile-lru' only affects which keys are evicted (those with TTL set), but does not prevent evictions from occurring when memory is full; the problem is insufficient memory, not the eviction policy. Option D is wrong because configuring a read replica offloads read traffic, but the latency spikes occur during SET (write) operations, and replicas do not handle writes; this does not reduce memory pressure on the primary instance.

Why this answer

How to eliminate wrong answers

Option A is wrong because the number of columns in a column family does not cause hotspotting or node-level traffic imbalance; column family design affects storage and read patterns, not write distribution. Option C is wrong because adding more nodes would not fix the root cause—hotspotting—since all writes for the same `orgId` would still target the same node regardless of cluster size. Option D is wrong because timestamp granularity affects row uniqueness, not write distribution; multiple rows with the same timestamp do not cause one node to handle most traffic.

Why this answer

Why this order

Why this answer

How to eliminate wrong answers

Option B is wrong because increasing shared_buffers to 50% of instance memory can cause excessive memory consumption, leading to increased checkpoint I/O and potential out-of-memory errors; PostgreSQL recommends shared_buffers be set to 25% of total memory, not 50%. Option C is wrong because setting statement_timeout to 30 seconds does not improve performance—it only aborts the query if it exceeds that duration, which would cause the query to fail rather than run faster. Option D is wrong because moving the query to a read replica does not eliminate the full table scan; the replica still performs the same sequential scan on the same large table, so performance remains poor.

Why this answer

How to eliminate wrong answers

Option B is wrong because while insufficient nodes can cause performance issues, the specific symptom of high read latency combined with increasing transaction abort rates points to hotspotting from the primary key design, not a general capacity problem. Option C is wrong because the primary key already includes UserId as the first column, so queries filtering by UserId can use the primary key directly without needing a secondary index. Option D is wrong because interleaving the Posts table under a Users table would not solve the hotspotting issue caused by the descending timestamp; it would actually exacerbate the problem by colocating all posts for a user on the same split.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because storage utilization measures data volume, not throughput capacity; a database can have low storage but still hit throughput limits due to high read/write operations. Option B is wrong because query error rate indicates failures (e.g., due to deadlocks or timeouts), but it is a lagging indicator of throughput saturation, not a direct measure of approaching limits. Option D is wrong because average commit latency can increase due to many factors (e.g., network latency, contention) and is not a primary metric for throughput capacity; Spanner's key metric for node saturation is CPU utilization.

Why this answer

How to eliminate wrong answers

Option A is wrong because InnoDB row reads measure the number of rows read from the InnoDB storage engine, which indicates query activity but does not directly correlate with disk space consumption. Option B is wrong because CPU utilization reflects processing load, not storage usage; high CPU could be a symptom of inefficient queries but does not explain disk usage. Option C is wrong because query latency measures the time taken to execute queries, which can be affected by disk I/O but does not identify the specific cause of high disk usage.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because adding secondary indexes on primary key columns does not reduce CPU utilization on Spanner nodes; it adds additional index maintenance overhead and may increase write latency without addressing the high read CPU issue. Option C is wrong because redesigning the schema to use interleaved tables improves locality for parent-child relationships but does not directly reduce CPU load from high-throughput point lookups; it may even increase CPU usage due to more complex splits. Option D is wrong because reducing the number of Spanner nodes decreases total CPU capacity, which would likely increase CPU utilization per node and worsen read latency, not reduce it.

Why this answer

How to eliminate wrong answers

Option A is wrong because batch writes combine multiple mutations into a single request but do not change the underlying key distribution; if all writes target the same row, batching still causes contention on that row. Option B is wrong because using a monotonically increasing timestamp as a prefix to the primary key exacerbates hot-spotting, as all new writes go to the same split, increasing contention rather than reducing it. Option C is wrong because adding a secondary index on the frequently updated column does not affect the primary key distribution; it may even increase write overhead and contention due to index maintenance.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because deleting binary logs too frequently on the primary does not directly cause replica lag; it can cause replication errors if the replica hasn't yet processed the logs, but lag itself is driven by apply delays, not log retention. Option B is wrong because the query cache is deprecated in MySQL 8.0 and, even when enabled, it caches SELECT results on the primary, not affecting replication lag. Option C is wrong because a higher machine tier on the replica would reduce, not increase, replica lag by providing more resources to apply changes faster.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because storage utilization measures disk space usage, not processing capacity; Spanner automatically manages storage distribution and high storage does not directly cause point-read latency. Option C is wrong because rows returned per second is a throughput metric, not a latency metric; high throughput can coexist with high latency if nodes are overloaded, so it does not identify the bottleneck. Option D is wrong because 'number of committed nodes' is not a standard Spanner metric; Spanner uses a fixed number of nodes provisioned, and committed nodes refer to a different concept (e.g., in Google Cloud commitments), not a real-time performance indicator.

Why this answer

How to eliminate wrong answers

Option B is wrong because Spanner allows queries during an optimize operation; waiting is unnecessary and defeats the purpose of high availability. Option C is wrong because dropping and restoring the database would restart the optimization from scratch, wasting time and resources without any benefit. Option D is wrong because canceling the optimize operation would leave the database in a suboptimal state, and performance would remain degraded until optimization is completed or re-triggered.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because read latency measures time for read operations, not write commit latency, and single-row inserts are writes. Option C is wrong because storage utilization affects capacity and cost, not commit latency directly; Spanner handles storage scaling automatically. Option D is wrong because CPU utilization per node indicates compute load but does not directly measure lock contention, which is the primary cause of high commit latency for single-row inserts.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the instance has 8 vCPUs, which is typically adequate for 500 writes per second; the degradation is due to index maintenance, not CPU starvation. Option B is wrong because the index size depends on the column data type and row count, but 30GB RAM is ample for a single index on a 10-million-row table; the issue is write amplification, not memory pressure. Option C is wrong because whether the index is used for reads is irrelevant to write performance degradation; the problem is the overhead of maintaining the index during writes, not its read usage.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because using many small keys instead of a few large keys does not reduce the eviction rate; it may actually increase memory overhead due to per-key metadata and does not address the root cause of memory pressure. Option B is wrong because decreasing the `maxmemory` setting forces earlier eviction, which would increase the eviction rate, not reduce it. Option C is wrong because setting `maxmemory-policy` to `noeviction` prevents any eviction, causing write operations to fail with an OOM error when memory is full, which does not reduce the eviction rate but instead breaks the application.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because decreasing `max_connections` reduces the number of concurrent connections but does not address the internal locking mechanism of the query cache; contention is a lock-level issue, not a connection-level one. Option C is wrong because increasing `innodb_buffer_pool_size` improves InnoDB data caching and reduces disk I/O, but it does not affect query cache locks, which are a separate memory structure. Option D is wrong because increasing `query_cache_size` only allocates more memory to the query cache, which can actually worsen contention by increasing the time spent scanning or invalidating cache entries under high concurrency.

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing nodes improves throughput and load distribution but does not address the root cause of scattered recent data due to row key ordering; it may even increase latency due to additional network hops. Option C is wrong because single cluster routing reduces cross-cluster latency in multi-cluster setups, but the question does not mention multiple clusters; the latency issue is within a single cluster due to row key design. Option D is wrong because using a scan with a prefix filter is less efficient than point reads for known row keys; it scans unnecessary rows and increases latency, whereas the goal is to optimize point lookups for recent timestamps.

Why this answer

How to eliminate wrong answers

Option A is wrong because removing indexes typically reduces write overhead but does not significantly lower CPU utilization from read-heavy workloads; indexes often speed up reads, and removing them could increase CPU usage due to full table scans. Option B is wrong because reducing max_connections limits concurrent users but does not address the root cause of high CPU from read queries; it may cause application errors without reducing CPU load if queries are already queued. Option D is wrong because increasing the machine type (higher vCPU count) is a vertical scaling approach that is more expensive than adding a read replica and does not leverage the cost efficiency of distributing read traffic across multiple instances.

Why this answer

How to eliminate wrong answers

Option A is wrong because migrating to Cloud Spanner is a drastic architectural change that does not diagnose the problem; it introduces new complexity and cost without addressing the immediate cause (e.g., missing index or stale statistics). Option B is wrong because adding a composite index is a potential solution, not a diagnostic step; you must first confirm the query's WHERE clause and execution pattern via pg_stat_statements to avoid creating an ineffective index. Option C is wrong because increasing vCPUs treats the symptom (high CPU) rather than the cause (sequential scan); it may temporarily reduce CPU but does not fix the underlying query performance issue and could be wasteful.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because network latency affects response times, not the cache hit ratio; moving to the same zone reduces latency but does not prevent evictions or increase the number of cached keys. Option B is wrong because setting 'noeviction' causes Redis to return errors on write operations when memory is full, which can break the application and does not restore existing evicted keys. Option D is wrong because AOF persistence ensures data durability across restarts but does not affect the eviction behavior or the number of keys in memory; it may even reduce available memory for caching due to overhead.

Why this answer

How to eliminate wrong answers

Option A is wrong because non-uniform table load typically causes hot spots or uneven data distribution, which can lead to performance degradation but does not directly cause replication latency; replication latency is a cluster-wide issue related to the replication protocol's processing speed. Option B is wrong because storage utilization at 70% is within normal operational limits and does not directly impact replication latency; replication latency is more sensitive to CPU and network bandwidth than to storage capacity. Option D is wrong because the number of nodes being above the recommended count can increase network overhead and coordination delays, but the most direct and common cause of replication latency in a cluster with high CPU is CPU saturation, not node count alone.

Why this answer

How to eliminate wrong answers

Option A is wrong because using separate tables per device does not solve hotspotting; it merely shifts the problem to table-level contention and increases operational overhead, as Bigtable is optimized for a single wide table, not many small tables. Option C is wrong because storing timestamps in column qualifiers does not address row key hotspotting; it only changes the schema structure without distributing the load, and queries still scan the same hot row key range. Option D is wrong because prefixing with deviceID and reversing the timestamp still results in sequential deviceID-based keys, which cause hotspotting; reversing the timestamp only helps if the deviceID is already distributed, but here the deviceID is the leading component, so all recent data for a device still falls on the same tablet.

Why this answer

How to eliminate wrong answers

Option A is wrong because indexing only product_id on the products table does not help with filtering or ordering on the orders table's order_date column, and the query likely involves the orders table. Option B is wrong because indexing only order_date on orders does not help with filtering on product_id, which is typically the more selective filter. Option D is wrong because a composite index on orders(order_date, product_id) would be less efficient if the query filters on product_id first, as MySQL cannot use the second column of the index when the first column is not used in a equality condition, leading to a full index scan or extra sorting.

Why this answer

How to eliminate wrong answers

Option A is wrong because a partial index with a hardcoded `user_id = 123` only benefits queries for that specific user, not the general slow query; it also ignores the `created_at` column needed for ordering or filtering. Option B is wrong because an index on `created_at` alone does not help if the query filters on `user_id` first — PostgreSQL may still perform a sequential scan or need to filter many rows. Option C is wrong because the column order `(created_at, user_id)` is suboptimal: if the query filters on `user_id` (equality) and then orders by `created_at`, the leading column should be `user_id` to allow index seek; leading with `created_at` forces a full index scan or inefficient filtering.

Why this answer

Why these pairings

Why this answer

How to eliminate wrong answers

Option A is wrong because B-tree index fragmentation in PostgreSQL is typically not a primary cause of high CPU usage; while index bloat can affect performance, the main issue here is the `SELECT *` causing excessive heap lookups, not index fragmentation. Option B is wrong because increasing the instance machine type treats the symptom (high CPU) rather than the root cause (inefficient query design), and it incurs unnecessary cost without addressing the underlying query pattern. Option D is wrong because the index on `order_date` is very likely being used (PostgreSQL's planner will use it for a range scan on a large table), but the high CPU stems from the heap lookups for all columns, not from the index being ignored; forcing index usage would not reduce the heap access overhead.

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing max_connections does not reduce buffer pool contention or disk reads; it may actually worsen contention by allowing more concurrent sessions to compete for the same limited buffer pool resources. Option B is wrong because reducing max_heap_table_size would force more temporary tables to disk, increasing disk reads per second, which is the opposite of the desired effect. Option D is wrong because the query cache is deprecated and removed in MySQL 8.0; even in earlier versions, it introduces mutex contention and is ineffective for write-heavy OLTP workloads, failing to address buffer pool contention or disk I/O.

Why this answer

How to eliminate wrong answers

Option A is wrong because reducing the number of replicas does not reduce write latency; it may actually increase latency by reducing read availability and fault tolerance, and writes still require leader confirmation. Option B is wrong because directed reads are used to route read requests to the nearest replica for lower read latency, but they do not affect write latency, as writes must still go through the leader. Option D is wrong because follower reads are a read-only feature that allows reads from non-leader replicas; writes cannot be performed on followers, so enabling follower reads for writes is technically invalid.

Why this answer

How to eliminate wrong answers

Option B is wrong because adjusting staleness to 5 seconds for reads reduces read CPU by allowing stale reads, but the problem states high CPU utilization on multiple nodes with read-write transactions; stale reads do not reduce the CPU cost of write operations or index maintenance, which are the primary drivers. Option C is wrong because increasing nodes spreads the CPU load but does not address the root cause; it may mask the issue and increase costs without resolving the underlying index overhead. Option D is wrong because creating a separate read-only replica pool offloads read traffic, but the high CPU is from read-write transactions, and read-only replicas cannot handle writes; they do not reduce CPU for write-heavy workloads.