DEA-C01 Data Ingestion and Transformation Practice Question

A data engineering team uses AWS Glue ETL jobs to process data daily. They notice that job run times are increasing as data volume grows. Which action will most effectively improve performance without changing the code?

⚠ Common exam trap

The trap is thinking that job bookmarks or file splitting will improve performance for growing data; candidates might overlook that scaling DPUs directly addresses compute needs.

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

✓

Increase the number of DPUs for the Glue job.

Increasing the number of DPUs (Data Processing Units) for the Glue job directly scales the compute resources allocated to the job, which can improve performance and reduce run times as data volume grows. This does not require code changes. Job bookmarks help skip already processed data but do not address increasing data volume. Smaller instance types and more files in S3 may not effectively improve performance.

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 a smaller instance type for the Glue job.
Why it's wrong here
A smaller instance type reduces available vCPU and memory per worker, worsening the slowdown as volume grows. Larger worker types or more workers raise parallel processing capacity. Smaller instances suit light, low-volume jobs where cost matters, not a workload already constrained by growing data volume.
✗
Enable job bookmark to skip previously processed data.
Why it's wrong here
Bookmarks track previously processed S3 objects, so they cut redundant reads only when reruns reprocess old data. Here each daily run handles new data, so the growing volume still passes through unchanged; bookmarks cannot parallelise or accelerate that work. They suit incremental ingestion pipelines, not this scenario.
✗
Split the data into more files in S3.
Why it's wrong here
Splitting into more files does not help when the bottleneck is per-worker compute; Glue already reads many files in parallel, and excessive small files add listing and open overhead. Compaction into fewer, larger files is the usual remedy. More files suit skewed, oversized single-file inputs, not this scenario.
✓
Increase the number of DPUs for the Glue job.
Why this is correct
Increasing DPUs adds more Apache Spark executors, raising parallel task capacity so each stage processes partitions faster. This directly addresses the growing data volume constraint while requiring no code changes, since Glue scales worker allocation automatically. It outperforms alternatives that alter code or partitioning logic.

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