Bird
Raised Fist0
AWScloud~20 mins

Scan vs query performance in AWS - Practice Questions

Choose your learning style10 modes available
Challenge - 5 Problems
🎖️
DynamoDB Scan vs Query Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
🧠 Conceptual
intermediate
2:00remaining
Understanding Scan vs Query in DynamoDB

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

ABoth Scan and Query read all items but Query is slower due to filtering.
BScan reads items based on primary key and is faster; Query reads all items and is slower.
CScan reads all items in a table and is slower; Query reads items based on primary key and is faster.
DScan and Query have identical performance because they both use indexes.
Attempts:
2 left
💡 Hint

Think about how many items each operation reads from the table.

❓ service_behavior
intermediate
2:00remaining
Result Count Differences Between Scan and Query

You perform a Scan and a Query on a DynamoDB table with 1000 items. The Query uses a partition key that matches 50 items. How many items will each operation read?

AScan reads 1000 items; Query reads 50 items.
BScan reads 50 items; Query reads 1000 items.
CBoth Scan and Query read 1000 items.
DBoth Scan and Query read 50 items.
Attempts:
2 left
💡 Hint

Consider what each operation scans or queries in the table.

❓ Architecture
advanced
2:30remaining
Optimizing DynamoDB Access Patterns

You want to design a DynamoDB table to minimize the use of Scan operations for better performance. Which design choice helps achieve this?

AUse a well-defined partition key and sort key to enable efficient Query operations.
BAvoid using any keys and rely on Scan for all data retrieval.
CUse only Scan operations with filters to reduce data read.
DStore all data in a single partition to simplify access.
Attempts:
2 left
💡 Hint

Think about how keys help DynamoDB find data quickly.

❓ security
advanced
2:30remaining
Security Implications of Scan vs Query

Which security risk is higher when using Scan operations compared to Query operations in DynamoDB?

AScan operations are encrypted by default, Query operations are not.
BScan may expose more data than intended because it reads the entire table.
CQuery exposes more data because it uses keys.
DThere is no difference in security risks between Scan and Query.
Attempts:
2 left
💡 Hint

Consider how much data each operation accesses.

✅ Best Practice
expert
3:00remaining
Choosing Between Scan and Query for Large Tables

You manage a DynamoDB table with millions of items. You need to retrieve items matching a specific attribute that is not part of the primary key. Which approach is best to maintain performance?

AUse Scan with a filter expression on the attribute to find matching items.
BExport the table data and search externally to avoid Scan or Query.
CAdd the attribute to the primary key and use Query on the main table.
DCreate a Global Secondary Index (GSI) on that attribute and use Query on the GSI.
Attempts:
2 left
💡 Hint

Think about how to query non-key attributes efficiently.

Practice

(1/5)
1. Which AWS DynamoDB operation is faster when you know the exact primary key of the item you want to retrieve?
easy
A. Update
B. Scan
C. Query
D. Delete

Solution

  1. Step 1: Understand Query operation

    Query retrieves items by specifying the primary key, making it fast and efficient.
  2. Step 2: Compare with Scan operation

    Scan reads the entire table, which is slower and more costly when you know the key.
  3. Final Answer:

    Query -> Option C
  4. Quick Check:

    Known key = Query [OK]
Hint: Use Query for known keys, Scan reads all data [OK]
Common Mistakes:
  • Thinking Scan is faster for known keys
  • Confusing Update or Delete with data retrieval
  • Assuming Query reads the whole table
2. Which of the following is the correct syntax to perform a Query operation in AWS DynamoDB using the AWS CLI?
easy
A. aws dynamodb query --table-name MyTable --key-condition-expression 'Id = :id' --expression-attribute-values '{":id":{"S":"123"}}'
B. aws dynamodb scan --table-name MyTable --key-condition-expression 'Id = :id' --expression-attribute-values '{":id":{"S":"123"}}'
C. aws dynamodb get-item --table-name MyTable --key '{"Id":{"S":"123"}}'
D. aws dynamodb update-item --table-name MyTable --key '{"Id":{"S":"123"}}'

Solution

  1. Step 1: Identify Query command syntax

    The Query operation uses 'aws dynamodb query' with key-condition-expression and expression-attribute-values.
  2. Step 2: Check other options

    Scan reads the entire table (and does not support --key-condition-expression), get-item retrieves a single item by exact key, update-item modifies items, so only the Query syntax is correct.
  3. Final Answer:

    aws dynamodb query --table-name MyTable --key-condition-expression 'Id = :id' --expression-attribute-values '{":id":{"S":"123"}}' -> Option A
  4. Quick Check:

    Query syntax uses 'query' command [OK]
Hint: Query uses 'aws dynamodb query' command [OK]
Common Mistakes:
  • Using Scan command instead of Query
  • Confusing GetItem with Query
  • Incorrect expression-attribute-values format
3. Given a DynamoDB table with 1000 items, what will be the main difference in performance between these two operations?
1. Query with KeyConditionExpression on partition key
2. Scan without any filter
medium
A. Both read the same number of items and have similar speed
B. Scan reads fewer items and is faster; Query reads all items and is slower
C. Both read all items but Query is slower due to filtering
D. Query reads fewer items and is faster; Scan reads all items and is slower

Solution

  1. Step 1: Analyze Query operation

    Query uses the partition key to directly find matching items, reading fewer items and faster.
  2. Step 2: Analyze Scan operation

    Scan reads every item in the table, making it slower and more expensive.
  3. Final Answer:

    Query reads fewer items and is faster; Scan reads all items and is slower -> Option D
  4. Quick Check:

    Query = fewer reads, Scan = full table [OK]
Hint: Query targets keys, Scan reads whole table [OK]
Common Mistakes:
  • Assuming Scan is faster than Query
  • Thinking Query reads all items
  • Ignoring cost differences
4. You wrote this DynamoDB Scan command but it is very slow:
aws dynamodb scan --table-name Users

What is the best way to improve performance if you only want users with UserId = '123'?
medium
A. Replace Scan with Query using KeyConditionExpression on UserId
B. Add a FilterExpression to the Scan command
C. Increase the Read Capacity Units of the table
D. Use UpdateItem to modify the UserId

Solution

  1. Step 1: Identify problem with Scan

    Scan reads all items, causing slowness when filtering after reading.
  2. Step 2: Use Query for known key

    Query with KeyConditionExpression on UserId reads only matching items, improving speed.
  3. Final Answer:

    Replace Scan with Query using KeyConditionExpression on UserId -> Option A
  4. Quick Check:

    Known key = Query, not Scan [OK]
Hint: Use Query with key condition, not Scan with filter [OK]
Common Mistakes:
  • Adding filter to Scan instead of using Query
  • Increasing capacity without optimizing query
  • Using UpdateItem unrelated to read performance
5. You have a DynamoDB table with 1 million items. You need to retrieve all items where the attribute 'Status' equals 'Active'. The table's primary key is 'UserId'. Which approach gives the best performance and cost efficiency?
hard
A. Use Scan with FilterExpression 'Status = Active' to get all matching items
B. Create a Global Secondary Index (GSI) on 'Status' and use Query on the GSI
C. Use Query on the primary key 'UserId' with FilterExpression 'Status = Active'
D. Use Scan without any filter and filter results in your application code

Solution

  1. Step 1: Understand Scan with filter

    Scan reads all 1 million items, filtering after reading, which is slow and costly.
  2. Step 2: Use GSI for efficient querying

    Creating a GSI on 'Status' allows Query to directly find 'Active' items efficiently.
  3. Step 3: Evaluate other options

    Query on primary key can't filter by 'Status' efficiently; scanning without filter wastes resources.
  4. Final Answer:

    Create a Global Secondary Index (GSI) on 'Status' and use Query on the GSI -> Option B
  5. Quick Check:

    GSI + Query = best performance for non-key attribute [OK]
Hint: Use GSI and Query for non-key attribute filtering [OK]
Common Mistakes:
  • Using Scan with filter on large tables
  • Querying primary key with filter instead of GSI
  • Filtering in application after full Scan
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard