Scan vs Query performance comparison in DynamoDB - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Scan vs Query in DynamoDB

Which statement best describes the main difference between a Scan and a Query operation in DynamoDB?

A Scan reads all items in a table and filters results, while Query finds items based on primary key values.

B Scan only reads items with a specific attribute, Query reads all items.

C Scan and Query both read all items but Query is faster because it uses indexes.

D Query reads all items in a table and filters results, while Scan finds items based on primary key values.

💡 Hint

Think about how each operation accesses data and what keys they use.

A Scan reads every item in the table and then applies filters, which can be slow. A Query uses the primary key or an index to find matching items quickly.

❓ query_result

intermediate

Result count difference between Scan and Query

Given a DynamoDB table with 1000 items, 100 of which have a partition key value of 'user123'. What is the expected number of items returned by a Query with partition key 'user123' vs a Scan with a filter for 'user123'?

A Query returns 100 items; Scan returns 1000 items.

B Query returns 1000 items; Scan returns 100 items.

C Query returns 100 items; Scan reads 1000 items but returns 100 after filtering.

D Query returns 1000 items; Scan reads 1000 items but returns 100 after filtering.

💡 Hint

Consider how many items each operation reads and returns.

The Query directly fetches the 100 matching items. The Scan reads all 1000 items and then filters to return 100.

📝 Syntax

advanced

Identify the correct Query syntax in DynamoDB

Which of the following DynamoDB Query API calls is syntactically correct to fetch items with partition key 'user123'?

DynamoDB

const params = {
  TableName: 'Users',
  KeyConditionExpression: 'userId = :uid',
  ExpressionAttributeValues: {
    ':uid': 'user123'
  }
};

const result = await dynamodb.query(params).promise();

A FilterExpression: 'userId = :uid', ExpressionAttributeValues: { ':uid': 'user123' }

B KeyConditionExpression: 'userId == :uid', ExpressionAttributeValues: { ':uid': 'user123' }

C KeyConditionExpression: 'userId = user123', ExpressionAttributeValues: { ':uid': 'user123' }

D KeyConditionExpression: 'userId = :uid', ExpressionAttributeValues: { ':uid': 'user123' }

💡 Hint

Check the syntax for KeyConditionExpression and how values are referenced.

KeyConditionExpression uses a single equals sign and placeholders like ':uid' must be defined in ExpressionAttributeValues. Option D follows this correctly.

❓ optimization

advanced

Improving Scan performance with filters

You want to reduce the read capacity units consumed by a Scan operation that filters items by an attribute 'status'. Which approach will improve performance?

A Use a FilterExpression in Scan to filter 'status' and enable Parallel Scan with segments.

B Use Query instead of Scan without any indexes.

C Remove the FilterExpression and scan the entire table sequentially.

D Use Scan with FilterExpression and set ConsistentRead to true.

💡 Hint

Think about how to reduce the amount of data scanned and speed up the operation.

FilterExpression reduces returned items but does not reduce read units. Parallel Scan divides the table into segments scanned concurrently, improving speed.

🔧 Debug

expert

Diagnosing slow Query performance

A DynamoDB Query on a large table is unexpectedly slow. The Query uses a partition key but no sort key condition. Which is the most likely cause?

A The Query uses a FilterExpression instead of KeyConditionExpression, causing a syntax error.

B The Query returns too many items because no sort key condition limits results, causing high latency.

C The table has no provisioned throughput, so Query is throttled.

D The partition key is missing from the KeyConditionExpression, causing a full table scan.

💡 Hint

Consider how the absence of a sort key condition affects the number of items returned.

Without a sort key condition, the Query returns all items with the partition key, which can be many and slow the response.

Practice

1. Which DynamoDB operation is generally faster when you know the partition key of the item you want to retrieve?

easy

A. Scan

B. UpdateItem

C. Query

D. DeleteItem

Solution

1. Step 1: Understand Query operation

   Query uses the partition key to directly find matching items, making it efficient.

2. Step 2: Compare with Scan operation

   Scan reads the entire table, which is slower and less efficient.

3. Final Answer:

   Query -> Option C

4. Quick Check:

   Query is faster for known keys [OK]

Hint: Use Query when you know the partition key for speed [OK]

Common Mistakes:

• Thinking Scan is faster because it reads all data
• Confusing Query with Scan
• Assuming UpdateItem is for reading data

2. Which of the following is the correct syntax to perform a Query operation in DynamoDB using AWS SDK for JavaScript?

easy

A. dynamoDbClient.query({ TableName: 'MyTable', KeyConditionExpression: '#pk = :pkval', ExpressionAttributeNames: { '#pk': 'PartitionKey' }, ExpressionAttributeValues: { ':pkval': '123' } })

B. dynamoDbClient.scan({ TableName: 'MyTable', KeyConditionExpression: 'PartitionKey = 123' })

C. dynamoDbClient.query({ TableName: 'MyTable', FilterExpression: 'PartitionKey = 123' })

D. dynamoDbClient.getItem({ TableName: 'MyTable', Key: { PartitionKey: '123' } })

Solution

1. Step 1: Identify correct Query syntax

   Query requires KeyConditionExpression with placeholders and attribute names/values.

2. Step 2: Check options for correct usage

   dynamoDbClient.query({ TableName: 'MyTable', KeyConditionExpression: '#pk = :pkval', ExpressionAttributeNames: { '#pk': 'PartitionKey' }, ExpressionAttributeValues: { ':pkval': '123' } }) uses KeyConditionExpression and ExpressionAttributeNames/Values correctly.

3. Final Answer:

   dynamoDbClient.query({ TableName: 'MyTable', KeyConditionExpression: '#pk = :pkval', ExpressionAttributeNames: { '#pk': 'PartitionKey' }, ExpressionAttributeValues: { ':pkval': '123' } }) -> Option A

4. Quick Check:

   Query needs KeyConditionExpression [OK]

Hint: Query needs KeyConditionExpression, not FilterExpression [OK]

Common Mistakes:

• Using FilterExpression instead of KeyConditionExpression for Query
• Using scan method with KeyConditionExpression
• Confusing getItem with query syntax

3. Given a DynamoDB table with 1000 items, what will be the main difference in performance between these two operations?
dynamoDbClient.scan({ TableName: 'MyTable' })
and
dynamoDbClient.query({ TableName: 'MyTable', KeyConditionExpression: '#pk = :pk', ExpressionAttributeNames: { '#pk': 'PartitionKey' }, ExpressionAttributeValues: { ':pk': '123' } })

medium

A. Scan reads all 1000 items; Query reads only matching items, so Query is faster.

B. Scan is faster because it reads all items at once; Query is slower due to filtering.

C. Both operations have the same speed because they access the same table.

D. Query reads all items; Scan reads only matching items.

Solution

1. Step 1: Understand Scan operation

   Scan reads every item in the table, so it processes all 1000 items.

2. Step 2: Understand Query operation

   Query uses the partition key to read only matching items, which is faster.

3. Final Answer:

   Scan reads all items; Query reads only matching items, so Query is faster. -> Option A

4. Quick Check:

   Scan reads all; Query reads matching [OK]

Hint: Scan reads whole table; Query reads only matching keys [OK]

Common Mistakes:

• Thinking Scan is faster because it reads all data at once
• Confusing Query reading all items
• Assuming both have same speed

4. You wrote this DynamoDB Query code but it returns no results:

const params = { TableName: 'MyTable', KeyConditionExpression: 'PartitionKey = :pk', ExpressionAttributeValues: { ':pk': '123' } };
const data = await dynamoDbClient.query(params);

What is the most likely error?

medium

A. Missing ExpressionAttributeNames for reserved word PartitionKey

B. Using Scan instead of Query

C. TableName is misspelled

D. Incorrect KeyConditionExpression syntax; should use #pk = :pk

Solution

1. Step 1: Check KeyConditionExpression syntax

   KeyConditionExpression requires placeholders for attribute names like #pk defined in ExpressionAttributeNames.

2. Step 2: Identify missing ExpressionAttributeNames

   The code uses 'PartitionKey' directly without ExpressionAttributeNames, causing no matches.

3. Final Answer:

   Incorrect KeyConditionExpression syntax; should use #pk = :pk -> Option D

4. Quick Check:

   Reserved words need placeholders in KeyConditionExpression [OK]

Hint: Use placeholders for reserved words in KeyConditionExpression [OK]

Common Mistakes:

• Not using ExpressionAttributeNames for reserved words
• Confusing Scan and Query methods
• Misspelling TableName

5. You want to retrieve all items where the attribute 'Status' equals 'Active' from a large DynamoDB table. The table's partition key is 'UserId'. Which approach is best for performance and cost?

hard

A. Use Query with KeyConditionExpression on 'UserId' and FilterExpression on 'Status' = 'Active'.

B. Create a Global Secondary Index (GSI) on 'Status' and Query the GSI for 'Active' items.

C. Use Scan with a FilterExpression on 'Status' = 'Active' to get all matching items.

D. Use Scan without any filters to get all items and then filter in application code.

Solution

1. Step 1: Understand limitations of Scan and Query

   Scan reads entire table and is costly; Query requires partition key, but 'Status' is not the partition key.

2. Step 2: Use GSI for efficient querying

   Creating a GSI on 'Status' allows Query on 'Status' attribute efficiently without scanning.

3. Final Answer:

   Create a Global Secondary Index (GSI) on 'Status' and Query the GSI for 'Active' items. -> Option B

4. Quick Check:

   GSI enables efficient queries on non-key attributes [OK]

Hint: Use GSI to query non-key attributes efficiently [OK]

Common Mistakes:

• Using Scan with filters on large tables
• Trying to Query without partition key
• Filtering in application instead of database