DEA-C01 Data Operations and Support Practice Question

A data engineering team notices that an AWS Glue ETL job, which processes hourly data from an S3 bucket, is taking progressively longer to run. The job reads Parquet files partitioned by date and hour. Which action is MOST likely to improve the job's performance?

⚠ Common exam trap

DEA-C01 often tests the misconception that adding more DPUs is always the answer to performance issues, but the exam expects candidates to identify data pruning and predicate pushdown as the primary optimization for partitioned data.

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 pushdown predicate filtering on the job's data source.

Pushdown predicate filtering allows AWS Glue to push filter conditions down to the data source, so only the relevant partitions and rows are read from S3. Since the data is partitioned by date and hour, predicate pushdown minimizes the amount of data scanned, reducing I/O and improving job performance. This is especially effective for Parquet, which supports columnar pruning and predicate pushdown.

Answer analysis

Option-by-option breakdown

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

✓
Enable pushdown predicate filtering on the job's data source.
Why this is correct
Pushdown predicates filter partitions and row groups at the S3/Parquet source, so Glue reads only matching date and hour data instead of scanning the full dataset. This cuts I/O and shuffle volume, directly addressing the growing runtime.
✗
Convert Parquet files to CSV to improve read performance.
Why it's wrong here
CSV is row-based and uncompressed, so Spark must scan every column and parse text, increasing I/O and CPU rather than reducing it. Parquet's columnar layout with predicate pushdown already exploits the date and hour partitions. CSV conversion suits interoperability with tools that cannot read columnar formats.
✗
Increase the number of DPUs for the job.
Why it's wrong here
Adding DPUs scales compute, but the slowdown stems from reading ever more small partitions as data accumulates; the job's bottleneck is S3 listing and per-file overhead, not CPU or memory. DPUs are the right lever for genuinely compute-bound jobs, such as heavy aggregations or skewed shuffles.
✗
Switch from Spark to Python shell for simpler processing.
Why it's wrong here
A Python shell job runs single-threaded on one instance and cannot distribute work across a cluster, so it would worsen runtime as data grows. Glue's Spark engine parallelises partitioned reads. Python shell suits small, lightweight transformations that fit comfortably within a single driver's memory and time limits.

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 Operations and Support Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question