DEA-C01 Data Operations and Support Practice Question

A data engineer is troubleshooting an AWS Glue ETL job that fails with a 'java.lang.OutOfMemoryError: Java heap space' error. The job processes a 50 GB Parquet file from an S3 bucket. The job uses a G.1X DPU (16 GB memory) and default parameters. Which action should the engineer take to resolve the issue?

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

✓

Change the worker type to G.2X (32 GB memory).

Changing the worker type to G.2X (32 GB memory) doubles the memory per worker, directly addressing the Java heap space error. Option B is incorrect because increasing the number of workers does not increase memory per worker; each G.1X DPU still has only 16 GB. Option C is incorrect because increasing the batch size would increase the amount of data loaded into memory per worker, potentially worsening the memory issue. Option D is incorrect because converting from Parquet to JSON typically increases file size and memory usage due to lack of compression and columnar storage.

Answer analysis

Option-by-option breakdown

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

✓
Change the worker type to G.2X (32 GB memory).
Why this is correct
The OutOfMemoryError arises because each G.1X executor has only 16 GB of heap for the 50 GB Parquet dataset. Switching to G.2X doubles memory to 32 GB per worker, giving the JVM sufficient heap to process the partitions without exhausting memory during the shuffle.
✗
Increase the number of workers from 2 to 4.
Why it's wrong here
Adding workers distributes partitions across more executors, but each executor still holds its own heap; the driver-side or per-partition allocation causing the OutOfMemoryError remains unchanged. Horizontal scaling suits throughput-bound jobs with many small partitions, not a single oversized partition or driver collect.
✗
Increase the 'batch size' parameter in the DynamicFrame reader.
Why it's wrong here
Raising batch size enlarges each DynamicFrame read chunk, increasing heap pressure per executor and worsening the OutOfMemoryError. Batch size tuning suits streaming micro-batch latency control, not a 50 GB single-file read where partition sizing and worker memory govern heap consumption.
✗
Convert the input data from Parquet to JSON format.
Why it's wrong here
JSON is text-based and far larger than columnar Parquet, so parsing inflates heap usage and deepens the OutOfMemoryError. Converting to JSON suits downstream systems requiring line-delimited text, not memory-constrained Spark reads where Parquet's columnar encoding already reduces footprint.

Visual reference

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