A pet insurer's policy-admin system keeps policy records in an Amazon DynamoDB table that serves customer and agent traffic all day. The analytics team needs a full daily copy of the table in Amazon S3 in a format that Athena can query, and the export must not slow the production traffic.
The table already has point-in-time recovery turned on for backups.
Which approach meets these requirements?
Choose one answer.
AA. Use the DynamoDB table export feature to write the table to S3 from point-in-time recovery data, using no read capacity.
BB. Run an AWS Glue job every night that scans the whole table with the DynamoDB connector, and writes the results to S3.
CC. Run an AWS Lambda function every hour that calls Scan on the table with a small page size, and appends each page to a file in S3.
DD. Query the table from Amazon Athena with a federated query connector every morning, and write the results to a new S3 table.
B. Wrong: A full scan consumes read capacity from the same table that serves production traffic, so it can slow customers and agents. The option is the pattern the team wants to avoid.
C. Wrong: Hourly paged scans still use the table's read capacity many times over the day, and they run slowly for a full copy. The option keeps the production impact the team wanted to avoid.
D. Wrong: A federated query against a DynamoDB table reads the table directly and uses its read capacity. The option has the same production impact as a scan.
Explanation
DynamoDB table export writes a full copy to S3 from point-in-time recovery data, so production read capacity stays free for customers and agents. Scans, paged reads and federated queries all read the live table and compete with production traffic.
Want more on DynamoDB data modeling? The 5 full-length practice sets have 10 more DynamoDB data modeling questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →