SOA-C02 Monitoring, Logging, and Remediation 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.

• ✗

  Increase the instance size from db.r5.large to db.r5.xlarge.

  Why it's wrong here

  Increasing the instance size from db.r5.large to db.r5.xlarge doubles the vCPUs and memory, which could provide more compute headroom and temporarily reduce CPU utilization. This is a vertical scaling approach that keeps all read and write traffic on a single database endpoint, so the primary still remains a bottleneck for read-heavy workloads. It is also a relatively expensive fixed-cost change and does not deliver the elastic horizontal read scaling that read replicas offer. For an application dominated by reads, scaling out is a more efficient and cost-effective strategy.

• ✗

  Enable Multi-AZ deployment for the RDS instance.

  Why it's wrong here

  Enabling Multi-AZ deployment creates a synchronous standby replica in a different Availability Zone and enables automatic failover, which greatly improves database availability and durability. The standby is passive and cannot accept connections or serve read traffic, so it does nothing to reduce the CPU load on the primary instance. In fact, synchronous replication introduces a small amount of write overhead, which could slightly worsen write latency. Multi-AZ is a high-availability feature, not a read-scaling feature, and is therefore irrelevant to this CPU utilization problem.

• ✓

  Create one or more read replicas and direct read traffic to them.

  Why this is correct

  Creating one or more read replicas and redirecting SELECT queries to them offloads a significant portion of the read workload from the primary DB instance, directly lowering its CPU utilization. The primary continues to handle writes and any critical read-your-own-writes traffic, while the replicas asynchronously apply changes and can serve large numbers of reads. This horizontal scaling approach is the standard and most cost-effective solution for read-heavy or OLTP workloads experiencing high CPU. Read replicas can even be placed across Availability Zones or regions to also improve read latency.

• ✗

  Change the storage type to Provisioned IOPS.

  Why it's wrong here

  Provisioned IOPS improves storage performance by guaranteeing a consistent level of input/output operations per second, which specifically targets disk latency and throughput bottlenecks. However, the monitored metric is CPU utilization, and Provisioned IOPS does not reduce the number of queries the database engine must process. Since the workload is constrained by compute, not storage I/O, this change will not lower CPU pressure or offload any read traffic.

Go deeper

Related to this question