Examkin

Soru

Zorluk: ZorData Store Operations with Amazon DynamoDB

A developer is designing a corporate desk-booking application. The DynamoDB table uses `DeskId` as the partition key and `BookingDate#Slot` (e.g., `2026-08-01#Morning`) as the sort key. The application must support two new access patterns:

1. Retrieve all bookings for a specific employee (`EmployeeId`) sorted by date.
2. Retrieve only the bookings that are currently marked as "PendingApproval" (representing less than 1%1\% of all bookings) to run a daily cleanup cron job.

Which two options should the developer implement to satisfy these requirements with the lowest consumption of Read Capacity Units (RCUs)?

  1. Create a Global Secondary Index (GSI) with `EmployeeId` as the partition key and `BookingDate#Slot` as the sort key.Cevap
  2. B
    Create a Local Secondary Index (LSI) with `EmployeeId` as the sort key.
  3. Create a GSI using a sparse attribute `PendingApprovalStatus` (which is only populated when a booking is pending approval) as the partition key.Cevap
  4. D
    Perform a `Scan` operation on the base table using a `FilterExpression` to retrieve bookings where the status attribute equals "PendingApproval".
  5. E
    Create a Local Secondary Index (LSI) with `PendingApprovalStatus` as the partition key.

Cevap

Create a Global Secondary Index (GSI) with `EmployeeId` as the partition key and `BookingDate#Slot` as the sort key, and create a GSI using a sparse attribute `PendingApprovalStatus` (which is only populated when a booking is pending approval) as the partition key.
The correct strategy involves two parts. First, to query across different partition keys (desks) by employee ID, a Global Secondary Index (GSI) with the employee ID as the partition key and the booking date/slot as the sort key must be created. Second, to retrieve the small fraction of bookings pending approval, a sparse GSI should be used. In DynamoDB, if an item does not contain the GSI's partition key attribute, it is not indexed. By populating a status attribute only when a booking is pending approval and setting it as the GSI's partition key, the index remains highly compact, and querying it consumes very few RCUs.

Adım Adım Çözüm

1
Analyze the first access pattern requirement.
The requirement is to retrieve bookings by `EmployeeId` sorted by date. Since the base table partition key is `DeskId`, querying by `EmployeeId` across different desks requires a Global Secondary Index (GSI) with `EmployeeId` as the partition key. Because the GSI sort key can be `BookingDate#Slot`, the items will be returned in sorted order.
An LSI would require the same partition key as the base table (`DeskId`), which cannot query across multiple desks for a single employee.
2
Analyze the second access pattern requirement.
The requirement is to retrieve only "PendingApproval" bookings, which constitute less than 1%1\% of total items. Creating a GSI using an attribute that is only present when the booking is in this status (a sparse GSI) ensures that the index size is extremely small.
Querying a sparse GSI only scans the relevant pending items, whereas scanning the base table with a filter expression would consume RCUs for every single item in the table.

Anahtar Kavram

Optimizing DynamoDB queries using Global Secondary Indexes (GSIs) and Sparse Indexes to minimize Read Capacity Unit (RCU) consumption.
Bu soruyu puanla

Konular

Data Store Operations with Amazon DynamoDB

Bu konudan daha fazla soru