SOA-C02 Cost and Performance Optimization Practice Question

A company runs a production database on Amazon RDS for PostgreSQL. The SysOps administrator wants to improve query performance for a read-heavy application without increasing costs significantly. Which THREE actions should the administrator take? (Choose three.)

⚠ Common exam trap

It's easy for candidates to confuse Multi-AZ deployment with read scaling; candidates often assume Multi-AZ improves read performance, but it only provides a standby replica for failover, not for serving read traffic.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Optimize slow queries by reviewing the slow query log

Reviewing the slow query log in RDS for PostgreSQL allows the administrator to identify and optimize poorly performing queries, which directly improves query performance without incurring additional infrastructure costs. This is a standard performance tuning practice that targets the root cause of read-heavy application slowdowns.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Enable Multi-AZ deployment
Why it's wrong here
Enabling Multi-AZ deployment creates a synchronous standby replica in a separate Availability Zone for automatic failover, but this standby never serves read traffic or helps with query processing. The primary instance continues to handle all queries with the same CPU, memory, and I/O configuration, so slow queries remain just as slow. Its purpose is durability and availability, not performance.
✗
Increase the allocated storage size
Why it's wrong here
Increasing allocated storage on an RDS instance can only help if you are hitting storage or IOPS limits; it does not change how the query planner executes queries or reduce logical I/O for a poorly written query. A slow query is typically caused by inefficient plans, missing indexes, or excessive data scanning, none of which are addressed by simply adding gigabytes. In fact, modern RDS instances decouple storage size from baseline IOPS, so additional capacity alone rarely improves query latency.
✓
Optimize slow queries by reviewing the slow query log
Why this is correct
Reviewing the slow query log is a direct diagnostic step because it captures SQL statements that exceed a configured execution-time threshold, allowing you to identify exactly which queries are problematic. Once identified, you can then add indexes, rewrite the query, or adjust parameters like work_mem (for PostgreSQL) to reduce execution time. This addresses the root cause of the performance issue rather than adding more resources to mask it.
✓
Implement an Amazon ElastiCache cluster to cache frequent query results
Why this is correct
Implementing an Amazon ElastiCache cluster, such as Redis, caches the results of frequent, repeatable queries so subsequent requests can be served from memory instead of hitting the RDS instance. This is highly effective when the same read-heavy queries are executed repeatedly with low data-change rates, but it adds complexity around cache invalidation and does nothing for write-heavy workloads or one-off analytical queries.
✓
Add one or more Read Replicas
Why this is correct
Adding one or more Read Replicas offloads read traffic from the primary database instance by allowing applications to route SELECT queries to the replicas, which remain synchronized via asynchronous replication. This scales read throughput horizontally and prevents a single instance from becoming a bottleneck for read-intensive workloads. However, replicas do not improve write latency, require application changes to route traffic, and replication lag can cause stale reads.

Go deeper

SOA-C02 Cost and Performance Optimization Practice Question

Why each option matters

Option-by-option breakdown

Related to this question