Secondary indexes (GSI, LSI) in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Difference between GSI and LSI in DynamoDB

Which statement correctly describes a key difference between a Global Secondary Index (GSI) and a Local Secondary Index (LSI) in DynamoDB?

A A GSI can only be created at table creation, while an LSI can be added anytime after table creation.

B A GSI can have a different partition key than the base table, while an LSI shares the same partition key but has a different sort key.

C Both GSI and LSI must share the same partition and sort keys as the base table.

D An LSI can have a different partition key than the base table, while a GSI shares the same partition key but has a different sort key.

💡 Hint

Think about which index type allows a different partition key from the main table.

A Global Secondary Index (GSI) allows a different partition key and sort key from the base table, enabling queries on different attributes. A Local Secondary Index (LSI) shares the same partition key but uses a different sort key. LSIs must be created when the table is created.

❓ Architecture

intermediate

Choosing index type for query flexibility

You have a DynamoDB table with a partition key 'UserID' and sort key 'OrderDate'. You want to query orders by 'ProductCategory' regardless of user. Which index type should you create?

A Create a Global Secondary Index with 'ProductCategory' as partition key.

B Create a Local Secondary Index with 'ProductCategory' as sort key.

C Create a Local Secondary Index with 'ProductCategory' as partition key.

D Create a Global Secondary Index with 'UserID' as partition key and 'ProductCategory' as sort key.

💡 Hint

Remember that LSIs share the same partition key as the base table.

To query by 'ProductCategory' regardless of 'UserID', you need an index with 'ProductCategory' as partition key. Only a Global Secondary Index (GSI) allows a different partition key. LSIs must share the base table's partition key.

❓ service_behavior

advanced

Impact of LSI size limit on table design

Your DynamoDB table uses an LSI. What happens if the total size of all items with the same partition key exceeds 10 GB?

A DynamoDB rejects writes that cause the size to exceed 10 GB for that partition key.

B DynamoDB automatically creates a new partition to handle the extra data.

C DynamoDB deletes the oldest items to keep size under 10 GB.

D DynamoDB converts the LSI to a GSI automatically.

💡 Hint

Consider DynamoDB's hard limits on LSI size per partition key.

LSIs have a strict limit of 10 GB per partition key. If a write causes this limit to be exceeded, DynamoDB rejects the write with a validation error. It does not automatically repartition or delete data.

❓ security

advanced

Access control for GSIs in IAM policies

You want to restrict a user to only query a specific Global Secondary Index (GSI) on a DynamoDB table. Which IAM policy condition is required?

A Use the 'dynamodb:PartitionKey' condition key to specify the GSI partition key.

B Use the 'dynamodb:TableName' condition key to specify the GSI name.

C Use the 'dynamodb:Attributes' condition key to specify GSI attributes.

D Use the 'dynamodb:IndexName' condition key to specify the allowed GSI name.

💡 Hint

Think about which IAM condition key controls access to indexes.

The IAM condition key 'dynamodb:IndexName' allows you to restrict actions to a specific index name, including GSIs. 'dynamodb:TableName' controls table access, but not specific indexes.

✅ Best Practice

expert

Optimizing cost and performance with GSIs

You have a DynamoDB table with a GSI that is rarely queried but has high write traffic. What is the best practice to optimize cost and performance?

A Remove the GSI and perform full table scans instead.

B Increase the provisioned write capacity on the GSI to handle all writes.

C Use sparse indexes by including a GSI partition key attribute only on items that need to be indexed.

D Duplicate the table and use the duplicate for GSI queries.

💡 Hint

Think about how to reduce unnecessary writes to the GSI.

Sparse indexes reduce write costs and improve performance by only indexing items that have the GSI partition key attribute. This avoids writing all items to the GSI when not needed.

Practice

1. What is the main difference between a Local Secondary Index (LSI) and a Global Secondary Index (GSI) in DynamoDB?

easy

A. LSI can have a different partition key, but GSI must use the main table's partition key.

B. LSI uses the same partition key as the main table, but GSI can use a different partition key.

C. LSI and GSI both require the same partition and sort keys as the main table.

D. LSI is only for read operations, while GSI is only for write operations.

Solution

1. Step 1: Understand LSI key structure

   LSI shares the same partition key as the main table but allows a different sort key.

2. Step 2: Understand GSI key structure

   GSI can have a completely different partition key and sort key from the main table.

3. Final Answer:

   LSI uses the same partition key as the main table, but GSI can use a different partition key. -> Option B

4. Quick Check:

   LSI shares partition key, GSI can differ [OK]

Hint: LSI shares partition key; GSI can change both keys [OK]

Common Mistakes:

• Thinking LSI can have a different partition key
• Assuming GSI must use main table keys
• Confusing read/write capabilities of indexes

2. Which of the following is the correct syntax to define a Global Secondary Index (GSI) in a DynamoDB table using AWS CloudFormation?

easy

A. "GlobalSecondaryIndexes": [{"IndexName": "GSI1", "KeySchema": [{"AttributeName": "UserId", "KeyType": "HASH"}], "Projection": {"ProjectionType": "KEYS_ONLY"}}]

B. "LocalSecondaryIndexes": [{"IndexName": "GSI1", "KeySchema": [{"AttributeName": "UserId", "KeyType": "HASH"}], "Projection": {"ProjectionType": "ALL"}}]

C. "GlobalSecondaryIndexes": [{"IndexName": "GSI1", "KeySchema": [{"AttributeName": "UserId", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"}}]

D. "GlobalSecondaryIndexes": [{"IndexName": "GSI1", "KeySchema": [{"AttributeName": "UserId", "KeyType": "HASH"}], "Projection": {"ProjectionType": "ALL"}}]

Solution

1. Step 1: Identify correct index type and key schema

   GlobalSecondaryIndexes is the correct property for GSI, and the partition key must have KeyType "HASH".

2. Step 2: Check projection type and syntax

   ProjectionType "ALL" is valid and commonly used; syntax matches CloudFormation format.

3. Final Answer:

   "GlobalSecondaryIndexes": [{"IndexName": "GSI1", "KeySchema": [{"AttributeName": "UserId", "KeyType": "HASH"}], "Projection": {"ProjectionType": "ALL"}}] -> Option D

4. Quick Check:

   GSI uses GlobalSecondaryIndexes with HASH key [OK]

Hint: GSI uses GlobalSecondaryIndexes with HASH key [OK]

Common Mistakes:

• Using LocalSecondaryIndexes for GSI
• Setting KeyType to RANGE for partition key
• Incorrect projection types or syntax errors

3. Given a DynamoDB table with a Global Secondary Index (GSI) on attribute Category as partition key and Price as sort key, what will the following query return?

Query on GSI where Category = 'Books' and Price between 10 and 20

medium

A. All items with Category 'Books' and Price between 10 and 20

B. All items with Price between 10 and 20 regardless of Category

C. All items with Category 'Books' regardless of Price

D. An error because Price cannot be used in query conditions

Solution

1. Step 1: Understand GSI query conditions

   Query on GSI requires specifying the partition key (Category = 'Books') and can filter by sort key range (Price between 10 and 20).

2. Step 2: Interpret the query result

   The query returns all items matching Category 'Books' with Price in the specified range.

3. Final Answer:

   All items with Category 'Books' and Price between 10 and 20 -> Option A

4. Quick Check:

   GSI query filters partition and sort keys correctly [OK]

Hint: Query GSI with partition key + sort key range filters [OK]

Common Mistakes:

• Ignoring partition key in query
• Thinking sort key can't be filtered
• Expecting error on valid query

4. You created a Local Secondary Index (LSI) on a DynamoDB table but your query on the LSI returns no results even though matching items exist. What is the most likely cause?

medium

A. The LSI was created with a different partition key than the main table.

B. The query used a filter expression instead of a key condition.

C. The query did not specify the same partition key as the main table.

D. LSIs do not support queries, only scans.

Solution

1. Step 1: Recall LSI key requirements

   LSI shares the same partition key as the main table, so queries must specify that partition key.

2. Step 2: Analyze query behavior

   If the query does not specify the partition key, no results will be returned because partition key is mandatory for queries on LSI.

3. Final Answer:

   The query did not specify the same partition key as the main table. -> Option C

4. Quick Check:

   LSI queries require main table partition key [OK]

Hint: LSI queries must include main table partition key [OK]

Common Mistakes:

• Assuming LSI can have different partition key
• Using filter instead of key condition for partition key
• Believing LSI does not support queries

5. You have a DynamoDB table with a partition key UserId and sort key OrderDate. You want to efficiently query all orders by Status and sort them by OrderAmount. Which secondary index should you create and how?

hard

A. Create a Global Secondary Index with partition key Status and sort key OrderAmount.

B. Create a Local Secondary Index with partition key UserId and sort key Status.

C. Create a Global Secondary Index with partition key UserId and sort key Status.

D. Create a Local Secondary Index with partition key Status and sort key OrderAmount.

Solution

1. Step 1: Identify query requirements

   You want to query by Status (different from main partition key) and sort by OrderAmount.

2. Step 2: Choose index type and keys

   Since Status is different from main partition key, use a Global Secondary Index with Status as partition key and OrderAmount as sort key.

3. Final Answer:

   Create a Global Secondary Index with partition key Status and sort key OrderAmount. -> Option A

4. Quick Check:

   GSI allows different partition and sort keys [OK]

Hint: Use GSI when partition key differs from main table [OK]

Common Mistakes:

• Trying to use LSI with different partition key
• Swapping partition and sort keys incorrectly
• Choosing wrong index type for query pattern