DEA-C01 Data Ingestion and Transformation Practice Question

A data engineer must ingest data from an Amazon DynamoDB table into an Amazon S3 bucket for analytics. The table receives continuous writes, and the ingestion must capture changes with minimal latency. The engineer wants a fully managed solution that requires no server provisioning. Which approach should the engineer use?

⚠ Common exam trap

The trap here is assuming that AWS DMS or Kinesis Data Firehose can directly capture DynamoDB changes with low latency, when actually DynamoDB Streams is the native change capture mechanism.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Enable DynamoDB Streams on the table, and use AWS Lambda to read the stream and write the data to Amazon S3.

DynamoDB Streams provides a time-ordered sequence of item-level changes, and Lambda can process these events in near real time. Writing to S3 from Lambda is a common serverless pattern that requires no server management and scales automatically. This combination meets the latency and managed-service requirements without the overhead of provisioning or full-table scans.

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 AWS Database Migration Service (AWS DMS) with ongoing replication to replicate the DynamoDB table to Amazon S3.
Why it's wrong here
AWS DMS supports DynamoDB as a source and S3 as a target, but it is designed for database migration and replication, not for low-latency change data capture from a continuously written table. DMS introduces replication instance provisioning and may not provide the near real-time latency required. It is also less efficient for small, frequent changes.
✓
Enable DynamoDB Streams on the table, and use AWS Lambda to read the stream and write the data to Amazon S3.
Why this is correct
DynamoDB Streams captures item-level changes in near real time, and Lambda can process these events without managing servers. This serverless pattern provides low-latency ingestion into S3. The engineer does not need to provision or scale any infrastructure, and the solution automatically scales with the stream volume, making it ideal for continuous writes.
✗
Use Amazon Kinesis Data Firehose to read directly from DynamoDB and deliver to Amazon S3.
Why it's wrong here
Kinesis Data Firehose cannot read directly from DynamoDB; it requires a streaming source such as Kinesis Data Streams or direct PUTs. Firehose is a delivery service, not a change capture mechanism. To use Firehose with DynamoDB, you would need an intermediary like Lambda to push changes, which adds complexity and is not a direct integration.
✗
Schedule an AWS Glue job to run every minute, reading the entire DynamoDB table and writing to Amazon S3.
Why it's wrong here
AWS Glue jobs are batch-oriented and not designed for minute-level scheduling with low latency. Reading the entire table each minute is inefficient and does not capture changes incrementally. This approach would miss intermediate updates and incur high costs due to full scans. It also requires provisioning DPUs and is not serverless in the sense of automatic scaling.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DEA-C01 Data Ingestion and Transformation Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question