A web-based application is running in AWS. The application is using a MySQL Amazon RDS database instance for persistence. The application stores transactional data and is read-heavy. The RDS…

Question

Options

• AScale up the RDS instance to a larger instance size
• BEnable the RDS database Multi-AZ option
• CCreate a read replica of the RDS instance
• DUse Amazon DynamoDB instead of RDS
• EUse Amazon ElastiCache to cache read queries

• A
  11% (4)
• B
  5% (2)
• C
  81% (30)
• D
  3% (1)

Explanation

Read Replicas (C) offload read traffic from the primary RDS instance to one or more replicas, directly addressing the read-heavy bottleneck with a scalable, purpose-built AWS feature. ElastiCache (E) adds an in-memory caching layer that serves frequently repeated read queries without hitting the database at all, dramatically reducing latency at peak load - and both solutions scale horizontally without downtime.

Why the others are wrong:

• A (Scale up): Vertical scaling gives a temporary performance bump but hits a ceiling, is not horizontally scalable, and requires downtime - the question specifically asks for a scalable solution.
• B (Multi-AZ): Multi-AZ is for high availability and failover, not read performance - the standby instance does not serve read traffic.
• D (DynamoDB): Switching databases is a massive architectural change, not a targeted performance optimization, and the app is already built around relational/transactional MySQL.

Memory tip: Think "Read = Replica or Cache" - when a question mentions read-heavy + scalable, your first instinct should be Read Replicas (more DB read capacity) and ElastiCache (fewer DB reads altogether). Multi-AZ is always about availability, never performance.

No community discussion yet for this question.