Why secondary indexes enable flexible queries in DynamoDB - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

How do secondary indexes improve query flexibility?

In DynamoDB, what is the main reason secondary indexes allow more flexible queries compared to querying only the primary key?

A They encrypt the data to improve security during queries.

B They automatically replicate the entire table data to another region for faster access.

C They compress the data to reduce storage costs.

D They allow queries on attributes other than the primary key without scanning the entire table.

💡 Hint

Think about how you can search by different columns without reading everything.

Secondary indexes let you query the table using different keys than the primary key, so you don't have to scan the whole table to find items.

❓ query_result

intermediate

Query result using a Global Secondary Index (GSI)

Given a DynamoDB table with a Global Secondary Index on the attribute 'Category', what will this query return?

Query on GSI where Category = 'Books'

A All items in the table regardless of Category.

B All items where the Category attribute equals 'Books'.

C All items where the primary key equals 'Books'.

D An error because GSIs cannot be queried.

💡 Hint

Remember what a GSI lets you do with attributes.

A GSI allows querying items based on the indexed attribute, here 'Category'. So the query returns all items with Category 'Books'.

📝 Syntax

advanced

Identify the correct syntax for querying a Local Secondary Index (LSI)

Which of the following DynamoDB query commands correctly queries a Local Secondary Index named 'DateIndex' on the attribute 'Date'?

A query({ TableName: 'Orders', IndexName: 'DateIndex', KeyConditionExpression: 'OrderId = :id and Date = :date', ExpressionAttributeValues: { ':id': '123', ':date': '2024-01-01' } })

B query({ TableName: 'Orders', KeyConditionExpression: 'DateIndex = :date', ExpressionAttributeValues: { ':date': '2024-01-01' } })

C query({ TableName: 'Orders', IndexName: 'DateIndex', KeyConditionExpression: 'Date = :date', ExpressionAttributeValues: { ':date': '2024-01-01' } })

D query({ TableName: 'Orders', IndexName: 'DateIndex', KeyConditionExpression: 'OrderId = :id', ExpressionAttributeValues: { ':id': '123' } })

💡 Hint

Remember that LSIs share the same partition key as the main table but have a different sort key.

LSIs require the partition key and the indexed sort key in the KeyConditionExpression. Option A correctly includes both.

❓ optimization

advanced

Choosing between Global and Local Secondary Indexes for flexible queries

You want to query a DynamoDB table by a non-primary key attribute that changes frequently and is not part of the primary key. Which index type should you use for best flexibility and why?

A Neither, because secondary indexes cannot be used for frequently changing attributes.

B Local Secondary Index, because it shares the partition key and is better for frequently changing attributes.

C Global Secondary Index, because it allows a different partition key and sort key than the main table and supports frequent attribute changes.

D Use a scan operation instead of any index for flexibility.

💡 Hint

Think about which index type allows different partition keys and supports attribute updates.

Global Secondary Indexes allow different partition and sort keys and can index attributes that change frequently, making them more flexible for such queries.

🔧 Debug

expert

Why does this query on a secondary index fail?

You run this DynamoDB query on a Global Secondary Index named 'StatusIndex' but get an error:

query({ TableName: 'Tasks', IndexName: 'StatusIndex', KeyConditionExpression: 'Status = :s', ExpressionAttributeValues: { ':s': 'Pending' } })

What is the most likely cause of the error?

A The KeyConditionExpression must include the partition key of the GSI, not just any attribute.

B The ExpressionAttributeValues are missing a required attribute for the primary key.

C The IndexName is misspelled and does not exist.

D DynamoDB does not support querying GSIs.

💡 Hint

Remember what must be included in the KeyConditionExpression when querying an index.

When querying a GSI, the KeyConditionExpression must include the GSI's partition key attribute. Using just 'Status' may be incorrect if 'Status' is not the partition key of the GSI.