LSI vs GSI comparison in DynamoDB - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Primary difference between LSI and GSI

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

A LSI can have a different partition key than the base table, but GSI must share the same partition key.

B LSI shares the same partition key as the base table, while GSI can have a different partition key.

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

D LSI and GSI are identical in structure and usage.

💡 Hint

Think about how the partition key is used in each index type.

An LSI uses the same partition key as the base table but allows a different sort key. A GSI can have a different partition key and sort key from the base table.

❓ query_result

intermediate

Query behavior difference between LSI and GSI

Given a DynamoDB table with both an LSI and a GSI, which query will always require specifying the partition key value?

A Querying the LSI requires specifying the partition key value.

B Querying the GSI requires specifying the partition key value.

C Neither LSI nor GSI require specifying the partition key value.

D Both LSI and GSI queries do not require partition key values.

💡 Hint

Consider how partition keys are used in queries for LSIs.

Queries on an LSI require the partition key because it shares the partition key with the base table. GSI queries require the partition key of the GSI, which can be different.

📝 Syntax

advanced

Correct syntax to create an LSI

Which option shows the correct syntax snippet to define a Local Secondary Index (LSI) in a DynamoDB table creation using AWS CLI JSON format?

A { "IndexName": "MyLSI", "KeySchema": [{"AttributeName": "UserId", "KeyType": "HASH"}, {"AttributeName": "Timestamp", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"} }

B { "IndexName": "MyLSI", "KeySchema": [{"AttributeName": "Timestamp", "KeyType": "HASH"}, {"AttributeName": "UserId", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"} }

C { "IndexName": "MyLSI", "KeySchema": [{"AttributeName": "UserId", "KeyType": "RANGE"}, {"AttributeName": "Timestamp", "KeyType": "HASH"}], "Projection": {"ProjectionType": "ALL"} }

D { "IndexName": "MyLSI", "KeySchema": [{"AttributeName": "Timestamp", "KeyType": "RANGE"}], "Projection": {"ProjectionType": "ALL"} }

💡 Hint

LSI must use the same partition key as the base table as HASH key.

LSI requires the partition key (HASH) to be the same as the base table's partition key. The sort key (RANGE) can be different. Option A correctly sets UserId as HASH and Timestamp as RANGE.

❓ optimization

advanced

Choosing between LSI and GSI for query flexibility

You want to query a DynamoDB table by multiple different partition keys and sort keys not defined in the base table. Which index type should you choose to maximize query flexibility?

A Local Secondary Index (LSI)

B Neither, use only the base table keys

C Both LSI and GSI equally support different partition keys

D Global Secondary Index (GSI)

💡 Hint

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

GSI allows a different partition key and sort key from the base table, enabling queries on multiple key combinations. LSI shares the partition key with the base table, limiting flexibility.

🔧 Debug

expert

Why does this LSI creation fail?

You try to create a DynamoDB table with an LSI where the LSI's partition key is different from the base table's partition key. What error will you encounter?

A ProvisionedThroughputExceededException: Throughput limit exceeded.

B ResourceInUseException: Table already exists.

C ValidationException: Local Secondary Index partition key must be the same as the base table partition key.

D ConditionalCheckFailedException: Condition check failed.

💡 Hint

LSI partition key must match base table partition key exactly.

LSI requires the partition key to be the same as the base table's partition key. If different, DynamoDB throws a ValidationException indicating this mismatch.