Q69 — AWS DVA-C02 Ch.2

Question 69 of 100 | ← Chapter 2

There is a table named 'artists' and another named 'songs'. The 'artists' table uses 'ArtistName' as its partition key. The 'songs' table uses 'songName' as its partition key and 'artistName' as its sort key. The access pattern includes retrieving multiple songs and their corresponding artists in a single database operation. A developer wants the solution that minimizes network traffic and delivers optimal application performance when retrieving this information. Which solution meets these requirements?

• A. Perform a BatchGetItem operation to retrieve items from both tables. Use a list of songName/artistName keys for the songs table and a list of artistName keys for the artists table. ✓
• B. Create a local secondary index (LSI) on the songs table using artistName as the partition key. Perform query operations on the songs table for each artist name and filter by song name list. Perform query operations on the artists table for each artist name.
• C. Perform a BatchGetItem operation on the songs table using songName/artistName keys. Perform a BatchGetItem operation on the artists table using ArtistName as the key.
• D. Perform scan operations on each table, filtering by the list of song names and artist names in the songs table and the list of artist names in the artists table.

Correct Answer: A. Perform a BatchGetItem operation to retrieve items from both tables. Use a list of songName/artistName keys for the songs table and a list of artistName keys for the artists table.

Explanation

This scenario requires optimizing cross-table retrieval with minimal network round trips and high efficiency. Option A uses BatchGetItem to fetch items from both tables in a single operation: songName/artistName keys for songs and artistName keys for artists. This reduces network overhead and improves performance. Option B requires multiple queries per artist, increasing round trips. Option C treats the two tables separately but still achieves batched retrieval—however, it doesn’t explicitly coordinate keys across tables like A does, and A is more precise for correlated lookups. Option D uses scans, which are inefficient and costly for large datasets due to full-table reads and filtering. Thus, option A best satisfies the requirement for single-operation, low-network, high-performance retrieval.