SAA-C03 Design High-Performing Architectures Practice Question
A data engineering team ingests a continuous stream of clickstream events into Amazon Kinesis Data Streams. Downstream consumers process the events, but the team observes that a single consumer is handling a disproportionate share of the records, causing hot shards and throttling. The team wants the stream to distribute records as evenly as possible across shards. Which change should the team make?
⚠ Common exam trap
The trap here is blaming the consumers and reaching for enhanced fan-out when the imbalance originates in how the producer chooses partition keys.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Increase the number of open shards and configure the producer to use a random partition key for each record.
Skew in Kinesis comes from the partition key mapping many records to the same shard hash range. Choosing a high-cardinality, evenly distributed key such as a random value spreads records across all shards, and adding shards provides more capacity. Together these changes balance the stream and relieve hot-shard throttling.
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 retention period of the stream to 365 days to smooth out the load.
Why it's wrong here
Retention controls how long records remain available for replay; it has no effect on how records are partitioned or how load is spread across shards. Extending retention changes cost and replay capability, not distribution, so it cannot resolve hot shards or producer throttling.
- ✗
Enable enhanced fan-out on the stream so each consumer gets dedicated throughput.
Why it's wrong here
Enhanced fan-out gives each registered consumer its own read throughput and reduces consumer-side contention, but it does not change how records are distributed across shards by the producer. The hot shard problem originates in partition key selection, so this feature does not address the root cause.
- ✗
Switch the producer to use an explicit partition key equal to the event's source IP address.
Why it's wrong here
Using source IP as the partition key groups all events from the same address onto one shard, which can create hot shards when a few sources generate most of the traffic. It does not spread load evenly, and it can worsen the skew the team is trying to eliminate, so it is not the right change.
- ✓
Increase the number of open shards and configure the producer to use a random partition key for each record.
Why this is correct
Record distribution across shards is determined by the partition key: Kinesis hashes the key and maps it to a shard. A random or highly varied partition key spreads records across all shards, avoiding a hot shard, and adding shards increases the total capacity so the workload can be absorbed evenly.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.