SAP-C02 - Design for New Solutions (29% of the exam) - Section 2.5

Design a solution to meet performance objectives by selecting instance families, storage options and purpose-built databases, and applying caching, buffering and replicas.

Select instance families, storage options, and purpose-built databases to meet latency, throughput, and durability requirements for a new solution. Apply Amazon ElastiCache for read caching, replica sets for read scaling, and buffering layers to smooth burst traffic before it reaches the primary datastore.

Purpose-built databasesAmazon ElastiCacheInstance familiesStorage options

Practice question for this objective

Free sampleDesign for New Solutionshard

A media company runs a product-catalogue API backed by Amazon RDS for PostgreSQL with a Multi-AZ primary and two read replicas. During campaigns a small set of popular item records is read thousands of times per second, the replicas approach their CPU limit, and read latency rises even though the data changes only a few times an hour. The team needs to absorb this repeated read traffic and cut tail latency to single-digit milliseconds with minimal application change and the lowest added cost. Which approach MOST effectively meets the requirement?

AAdd several more Amazon RDS for PostgreSQL read replicas behind a load balancer and spread the campaign read traffic across the enlarged replica fleet to lower the per-replica request rate during peaks.
BMigrate the catalogue to Amazon DynamoDB with DynamoDB Accelerator enabled so the hottest item reads are served from the in-memory accelerator instead of from the relational database during campaigns.
CEnable Multi-AZ failover on each read replica and increase the instance class of the primary and replicas so the larger engines can hold more of the hot catalogue pages in their local buffer cache.
DPut an Amazon ElastiCache for Redis cluster in front of the database and have the API lazy-load the hot item records into the cache so repeated reads are served from memory with a short time to live. Correct

Apply an ElastiCache cache-aside layer to absorb repeated hot-key reads and cut latency without re-platforming the database. When a small set of slowly-changing records is read enormously often, an in-memory cache in front of the database serves those repeated reads from memory and offloads the database tier, which lowers tail latency far more cheaply than adding replicas or scaling instance classes.

Why A is wrong: More replicas raise read capacity but each request still hits a full database engine, so repeated reads of the same few records cost more standing infrastructure without delivering single-digit-millisecond cached latency.

Why B is wrong: DAX gives microsecond reads but only fronts DynamoDB, so it forces a full re-platform of a working relational catalogue, which is a large application change rather than the minimal one requested.

Why C is wrong: Larger instances and replica failover improve durability and headroom, but scaling the engines up is costlier and still serves every repeated read through the database rather than from a dedicated cache tier.

Why D is correct: A cache-aside ElastiCache layer serves the few repeated hot records from memory at single-digit-millisecond latency, offloads the replicas, and needs only a small read-path change with low incremental cost.

See more SAP-C02 practice questions, answers explained.

Exam traps in Design for New Solutions

Answers that look right on this material and are not. Each one is a distractor from a different question in the SAP-C02 bank for this domain.

Store every measurement as an item in an Amazon DynamoDB table keyed by device identifier and timestamp, and compute rolling-window aggregates by scanning the relevant key ranges from the application on each query.
Why it is wrong: DynamoDB ingests the writes well, but time-window aggregations become application-side range scans and custom tiering logic, so it lacks the native time-series query and lifecycle features the workload needs.
Select a memory-optimised EC2 instance family and provision a single large Amazon EBS io2 Block Express volume sized to the dataset, setting its provisioned IOPS to the per-node random operation rate the engine sustains.
Why it is wrong: io2 Block Express can deliver high durable IOPS, but a single network-attached volume costs far more than local NVMe at this rate and the memory-optimised choice over-pays for RAM the IOPS-bound node does not need.
Run a single large Aurora writer instance sized for the busiest dashboard hour and route every dashboard query to the writer endpoint, raising the instance class whenever sustained read concurrency grows beyond what the current size can serve.
Why it is wrong: Sizing one writer for peak read concurrency over-provisions it for the quiet overnight period and still funnels all reads through a single instance, so it neither scales elastically nor isolates reads from writes.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.