DVA-C02 Development with AWS Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use the order ID as the partition key and create a global secondary index on customer ID

  Why this is correct

  This design effectively supports two distinct access patterns: retrieving a specific order by its unique order ID using a highly efficient GetItem operation, and querying all orders associated with a particular customer ID. By establishing a Global Secondary Index (GSI) with customer ID as its partition key, DynamoDB can efficiently retrieve all items matching that customer, optimizing performance and minimizing read capacity unit consumption for both primary and secondary query types.

• ✗

  Use the customer ID as the partition key and order ID as the sort key

  Why it's wrong here

  Using customer ID as the partition key and order ID as the sort key would create a composite primary key. While this allows efficient retrieval of all orders for a specific customer, or a specific order for a specific customer, it makes retrieving an order solely by its order ID highly inefficient. Without knowing the customer ID, DynamoDB cannot directly locate the item, forcing a full table Scan or an exhaustive Query across all customer partitions, which is not scalable.

• ✗

  Use the order ID as the partition key and scan the table for customer ID queries

  Why it's wrong here

  While order ID as the partition key enables very fast lookups for individual orders, relying on a Scan operation to find orders by customer ID is fundamentally flawed for anything beyond trivial datasets. A Scan reads every single item in the table, consuming significant read capacity units (RCUs), incurring high costs, and resulting in unacceptable latency as the table grows. This approach is not suitable for any regular or even occasional query pattern involving customer ID.

• ✗

  Use the customer ID as the partition key and create a local secondary index on order ID

  Why it's wrong here

  A Local Secondary Index (LSI) shares the same partition key as its base table, meaning it can only provide an alternate sort key for items within the same partition. Therefore, even with an LSI on order ID, you would still need to provide the customer ID (the base table's partition key) to query the LSI. Retrieving an order solely by order ID without knowing the customer ID would still necessitate a full table Scan or an inefficient Query across all partitions, as the LSI cannot be queried independently.