DVA-C02 Multi-AZ 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.

• ✓

  Implement an in-memory cache layer with Amazon ElastiCache.

  Why this is correct

  Implementing an in-memory cache layer with Amazon ElastiCache (e.g., Redis or Memcached) is an effective strategy for reducing CPU load on a read-heavy database. By caching frequently accessed data, ElastiCache intercepts read requests before they reach the database, serving them much faster from memory. This significantly decreases the number of queries the RDS instance needs to process, directly lowering its CPU utilization and improving overall application responsiveness. It requires application-level changes to interact with the cache, but these are typically manageable.

• ✗

  Migrate the database to Amazon Aurora with auto-scaling.

  Why it's wrong here

  Migrating the database to Amazon Aurora with auto-scaling is a significant architectural change that involves considerable migration effort and potential application refactoring. While Aurora offers superior performance, scalability, and auto-scaling capabilities for read replicas, it is an extensive solution for simply addressing high CPU utilization on an existing RDS for MySQL instance due to read load. A more targeted and less disruptive approach should be considered first before a full platform migration.

• ✗

  Increase the DB instance size to a larger instance type.

  Why it's wrong here

  Increasing the Amazon RDS DB instance size to a larger type provides additional CPU, memory, and I/O capacity. While this might temporarily alleviate high CPU utilization by allowing the instance to process more queries concurrently, it does not fundamentally reduce the number of read queries hitting the database. This approach is vertical scaling, which merely increases the primary instance's ability to handle the existing load at a higher cost, rather than reducing the load itself, making it less efficient than caching for read-heavy scenarios.

• ✗

  Create a Multi-AZ deployment and use the standby for read queries.

  Why it's wrong here

  An Amazon RDS Multi-AZ deployment is designed exclusively for high availability and disaster recovery. It provisions a synchronous standby replica in a different Availability Zone that is used solely for automatic failover in case of an outage of the primary instance. The standby instance cannot be directly accessed for read queries, nor does it offload any read traffic from the primary database. Therefore, implementing Multi-AZ would not reduce the CPU load on the primary DB instance.

Go deeper

Related to this question