SOA-C02 Cost and Performance Optimization 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.

• ✗

  Enable Multi-AZ deployment

  Why it's wrong here

  Multi-AZ deployment provisions a synchronously replicated standby instance in a separate Availability Zone and enables automatic failover, but the standby is completely passive — it cannot serve reads or offload any SELECT traffic from the primary. It is designed purely for high availability and data durability, so it does nothing to address the read-heavy workload; in fact, it roughly doubles your database cost for zero additional read capacity. This choice would be appropriate only if the primary concern were recovery from an AZ failure, not read scalability.

• ✗

  Increase the DB instance class to a larger size

  Why it's wrong here

  Increasing the DB instance class, such as moving from db.t3.large to db.r5.4xlarge, adds vCPUs and memory that can improve both read and write performance, but you are scaling the entire primary node horizontally, which means you pay disproportionately more for write capacity you may not need. The approach also hits hard limits: at some point you cannot scale higher without switching to a completely different architecture, and the single node remains a bottleneck for concurrent readers. In a read-heavy scenario, multiple smaller read replicas provide a much more targeted and cost-effective way to grow read throughput than a single larger instance.

• ✗

  Use Amazon ElastiCache to cache read results

  Why it's wrong here

  While ElastiCache reduces read load by caching frequent queries, it fails to address the scenario’s requirement for low cost, as it introduces an additional service with its own provisioning and operational expense. This option is tempting because caching is a standard technique for alleviating high read traffic on databases; it would be correct if the stem prioritised latency reduction over cost minimisation, or if the existing RDS instance were already at maximum capacity.

• ✓

  Add one or more Read Replicas in the same Region

  Why this is correct

  Adding one or more Read Replicas in the same Region creates independent, actively readable database copies that serve SELECT traffic, leaving the primary free to handle writes. Because the replicas stay in the same Region, you avoid inter-Region data transfer charges, and you can select smaller instance classes for the replicas to closely match the read-only workload. This horizontal scaling approach is cost-efficient because you add capacity only for the traffic that needs it, and it also preserves the primary's performance for the write-heavy portion of the workload.

Go deeper

Related to this question