DEA-C01 Data Ingestion and Transformation Practice Question

A data engineer is using AWS Glue to transform data from Amazon S3 and load it into Amazon Redshift. The job uses the write_dynamic_frame.from_jdbc_conf method. The engineer notices that the job is slow and sometimes fails due to connection timeouts. Which action should the engineer take to improve performance and reliability?

⚠ Common exam trap

The trap here is assuming that increasing DPUs or tweaking timeouts will solve JDBC write performance issues, when the real solution is to use the Redshift COPY command.

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

✓

Use the Amazon Redshift COPY command via a staging area in Amazon S3 instead of JDBC.

For large data loads into Amazon Redshift, the COPY command is significantly faster and more reliable than JDBC. AWS Glue can write transformed data to Amazon S3 and then invoke the COPY command to load it into Redshift. This approach leverages Redshift's parallel processing, reduces connection overhead, and avoids timeouts. Other options do not address the fundamental performance issue.

Answer analysis

Option-by-option breakdown

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

✗
Increase the number of DPUs for the Glue job to provide more parallelism.
Why it's wrong here
Adding DPUs increases compute capacity, but the bottleneck is likely the JDBC connection to Redshift. More DPUs may not help if the connection is the limiting factor. It could also increase the number of concurrent connections, potentially worsening timeouts. The root cause is the JDBC write method, not insufficient compute.
✗
Enable job bookmarks to avoid reprocessing previously loaded data.
Why it's wrong here
Job bookmarks help with incremental loads by tracking processed data, but they do not address performance or connection timeouts during the write phase. The issue is the JDBC write method, not reprocessing. Bookmarks are useful for reducing data volume but do not solve the underlying inefficiency.
✓
Use the Amazon Redshift COPY command via a staging area in Amazon S3 instead of JDBC.
Why this is correct
The COPY command is the most efficient way to load large datasets into Redshift. It parallelizes the load and uses Redshift's massively parallel processing. Writing to S3 first and then using COPY reduces JDBC overhead and connection timeouts. This is the recommended best practice for bulk loads into Redshift from Glue.
✗
Increase the JDBC connection timeout and retry settings in the Glue job script.
Why it's wrong here
Adjusting timeout and retry settings may temporarily mitigate failures but does not improve performance. The job will still be slow because JDBC writes are not optimized for bulk loads. This is a workaround, not a solution. The better approach is to use the COPY command for bulk data transfer.

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