DEA-C01 Data Ingestion and Transformation Practice Question

A company uses AWS Glue to transform data in S3. The transformation job reads Parquet files, filters rows, and writes to another S3 bucket. The job takes longer than expected. Which change would MOST likely reduce the job execution time?

⚠ Common exam trap

Many exam-takers assume optimizing file format or output partitioning will always improve performance, but for a compute-bound transformation job, increasing parallelism via DPUs is the most direct solution.

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 allocated to the Glue job.

Increasing the number of DPUs (Data Processing Units) allocated to the Glue job directly increases the parallelism of the Apache Spark-based execution environment. Since the job reads Parquet files, filters rows, and writes output, a bottleneck in compute capacity is the most likely cause of prolonged execution time. More DPUs allow Spark to distribute the workload across more executors, reducing overall runtime.

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 single large file instead of multiple small files.
Why it's wrong here
Consolidating into one large file removes parallelism: Glue splits work by file and block, so a single object limits concurrent task slots and skews processing onto fewer executors. This suits archival or sequential streaming writes, but for distributed filter-and-write jobs many moderate files enable parallel scans.
✗
Reduce the number of partitions in the output data.
Why it's wrong here
Reducing output partitions lowers write parallelism, so fewer tasks run concurrently and the job takes longer. It is tempting because fewer, larger files cut S3 request overhead, and would be correct when the bottleneck is many tiny output files rather than the filter and transform stages.
✗
Convert the input files from Parquet to CSV format.
Why it's wrong here
CSV is row-oriented, uncompressed plain text, so Glue must scan every column and parse delimiters, increasing I/O and CPU versus Parquet's columnar, compressed encoding with predicate pushdown. CSV suits simple interchange or ingestion by tools lacking Parquet support, not filter-heavy analytical reads where column pruning matters.
✓
Increase the number of DPUs allocated to the Glue job.
Why this is correct
Glue distributes work across DPUs, so adding DPUs increases parallel task capacity and shortens the filter-and-write job's runtime. This directly addresses the execution-time constraint, provided the job is not bottlenecked by a single small input partition.

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