SAA-C03 Design High-Performing Architectures Practice Question

A new feature stores user events in DynamoDB. Each event must be fetched by user_id and sorted by event_time. The team expects many different users and wants to avoid a single hot partition. Which partition key design is best?

⚠ Common exam trap

Candidates often choose a constant partition key (Option A) thinking it simplifies queries, not realizing it creates a single hot partition that defeats DynamoDB's scalability.

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

✓

Use user_id as the partition key and event_time as the sort key.

Using user_id as the partition key evenly distributes writes across partitions, avoiding hot spots, while event_time as the sort key enables efficient retrieval of events for a specific user in chronological order. DynamoDB's query operation can then fetch all events for a given user_id sorted by event_time without scanning.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use a constant partition key value (for example, partition_key='events') and store user_id as an attribute.
Why it's wrong here
Using a constant partition key like 'events' collapses every single event into one logical partition. This creates a single hot partition that will quickly exceed the provisioned read/write capacity of that partition, resulting in throttling and expensive retries even if the table's overall capacity is high. Additionally, since user_id is only an attribute, there is no efficient index to retrieve a user's events without a costly full table scan or a secondary index redesign, making both the access pattern and scalability fail.
When this WOULD be correct
If the question required storing a small, fixed dataset (e.g., configuration data) where all items need to be retrieved together and write throughput is negligible, a constant partition key would be acceptable.
✓
Use user_id as the partition key and event_time as the sort key.
Why this is correct
Using user_id as the partition key spreads data across many partitions based on user distribution. event_time as the sort key supports efficient range queries and retrieving events in time order per user. This design matches the stated access pattern and reduces hot partition likelihood.
✗
Use event_time as the partition key and user_id as an attribute to query later.
Why it's wrong here
Partitioning by event_time can still create hotspots if many events share the same time buckets. It also makes queries by user_id inefficient because user_id is not the partition key. The access pattern says user_id must drive retrieval.
When this WOULD be correct
A question where the access pattern requires retrieving all events within a specific time window (e.g., 'get all events between 10:00 and 10:05') and the workload has low write volume, so a time-based partition key is acceptable.
✗
Use a randomly generated UUID as the partition key and query by user_id using a full table scan.
Why it's wrong here
A UUID partition key prevents efficient direct lookups by user_id and forces scans, which are slow and costly at scale. Full table scans do not meet typical performance needs. The design should align partition key with the query pattern.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.

✓Use user_id as the partition key and event_time as the sort key.Correct answer▾

Why this is correct

Using user_id as the partition key spreads data across many partitions based on user distribution. event_time as the sort key supports efficient range queries and retrieving events in time order per user. This design matches the stated access pattern and reduces hot partition likelihood.

✗Use a constant partition key value (for example, partition_key='events') and store user_id as an attribute.Wrong answer — click to see why▾

Why this is wrong here

Using a constant partition key like 'events' would cause all data to land on a single partition, creating a hot partition and defeating the purpose of DynamoDB's distributed architecture.

★ When this WOULD be the correct answer

If the question required storing a small, fixed dataset (e.g., configuration data) where all items need to be retrieved together and write throughput is negligible, a constant partition key would be acceptable.

Why candidates choose this

Candidates may think a constant partition key simplifies queries (e.g., scanning all events) without realizing it creates a bottleneck for high-traffic workloads.

✗Use event_time as the partition key and user_id as an attribute to query later.Wrong answer — click to see why▾

Why this is wrong here

Using event_time as the partition key would create a hot partition for a specific time range (e.g., all events at the same second), causing throttling and uneven load distribution, which fails to avoid hot partitions as required.

★ When this WOULD be the correct answer

A question where the access pattern requires retrieving all events within a specific time window (e.g., 'get all events between 10:00 and 10:05') and the workload has low write volume, so a time-based partition key is acceptable.

Why candidates choose this

Candidates may think that sorting by event_time is best achieved by making it the partition key, overlooking that partition key design must ensure even distribution, not just sorting capability.

Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

Related to this question