GSI key selection strategy in DynamoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Choosing the Partition Key for a GSI

In DynamoDB, when creating a Global Secondary Index (GSI), which of the following is the best reason to choose a partition key that has high cardinality (many unique values)?

A To evenly distribute read and write traffic across partitions and avoid hot partitions.

B To make the index smaller by grouping many items under the same key.

C To ensure the GSI always returns results sorted by the partition key.

D To reduce the number of attributes stored in the GSI.

💡 Hint

Think about how DynamoDB spreads data and traffic across partitions.

A partition key with many unique values helps DynamoDB distribute traffic evenly, preventing any single partition from becoming a bottleneck (hot partition). This improves performance and scalability.

❓ query_result

intermediate

Querying a GSI with Partition and Sort Keys

Given a DynamoDB table with a GSI where the partition key is Category and the sort key is Price, what will be the result of this query?

Query the GSI for Category = 'Books' and Price between 10 and 20.

Assuming the GSI contains these items:

• {Category: 'Books', Price: 15, Title: 'Book A'}
• {Category: 'Books', Price: 25, Title: 'Book B'}
• {Category: 'Books', Price: 12, Title: 'Book C'}
• {Category: 'Electronics', Price: 15, Title: 'Gadget'}

A Returns all items with Category 'Books' regardless of Price.

B Returns 'Book B' only because Price is 25.

C Returns no items because Price is not the partition key.

D Returns 'Book A' and 'Book C' only.

💡 Hint

Remember how partition and sort keys work in queries.

The query filters items where the partition key equals 'Books' and the sort key (Price) is between 10 and 20. So only 'Book A' (Price 15) and 'Book C' (Price 12) match.

📝 Syntax

advanced

Identifying the Correct GSI Key Schema Syntax

Which of the following JSON snippets correctly defines a GSI key schema with a partition key named UserId and a sort key named Timestamp in a DynamoDB table?

A { "IndexName": "UserActivityIndex", "KeySchema": [ { "AttributeName": "Timestamp", "KeyType": "HASH" }, { "AttributeName": "UserId", "KeyType": "RANGE" } ] }

B { "IndexName": "UserActivityIndex", "KeySchema": [ { "AttributeName": "UserId", "KeyType": "HASH" }, { "AttributeName": "Timestamp", "KeyType": "RANGE" } ] }

C { "IndexName": "UserActivityIndex", "KeySchema": [ { "AttributeName": "UserId", "KeyType": "RANGE" }, { "AttributeName": "Timestamp", "KeyType": "HASH" } ] }

D { "IndexName": "UserActivityIndex", "KeySchema": [ { "AttributeName": "UserId", "KeyType": "PRIMARY" }, { "AttributeName": "Timestamp", "KeyType": "SORT" } ] }

💡 Hint

Recall the correct key types for partition and sort keys in DynamoDB.

In DynamoDB, the partition key uses KeyType 'HASH' and the sort key uses 'RANGE'. Option B correctly assigns these.

❓ optimization

advanced

Optimizing GSI for Query Performance

You have a DynamoDB table storing orders with attributes: OrderId, CustomerId, Status, and OrderDate. You want to create a GSI to efficiently query all orders by CustomerId and sort them by OrderDate. Which GSI key selection strategy is best?

A Set <code>OrderDate</code> as the partition key and <code>CustomerId</code> as the sort key of the GSI.

B Set <code>Status</code> as the partition key and <code>OrderDate</code> as the sort key of the GSI.

C Set <code>CustomerId</code> as the partition key and <code>OrderDate</code> as the sort key of the GSI.

D Set <code>OrderId</code> as the partition key and <code>Status</code> as the sort key of the GSI.

💡 Hint

Think about how you want to query the data and which attribute groups the data logically.

To query all orders by a customer and sort by date, the partition key should be CustomerId (to group orders by customer) and the sort key OrderDate (to order them by date).

🔧 Debug

expert

Diagnosing a Hot Partition Issue in a GSI

You created a GSI with Status as the partition key and CreatedAt as the sort key. Your application experiences throttling and slow queries. The Status attribute only has three possible values: 'Pending', 'Completed', and 'Cancelled'. What is the most likely cause of the problem?

A The low cardinality of the partition key 'Status' causes hot partitions due to uneven traffic distribution.

B The sort key 'CreatedAt' is not indexed properly, causing slow queries.

C The GSI is missing a projection of the 'Status' attribute.

D The table's primary key conflicts with the GSI partition key.

💡 Hint

Consider how the number of unique partition key values affects traffic distribution.

Having only three possible partition key values causes all traffic to concentrate on very few partitions, creating hot partitions and throttling. This is a common cause of performance issues in GSIs.