DEA-C01 Data Operations and Support Practice Question

A data engineer is building an AWS Glue ETL job that reads from an Amazon S3 bucket containing CSV files and writes to an Amazon Redshift table. The job runs successfully but the Redshift table ends up empty. The engineer checks the AWS Glue job run metrics and sees that the job processed 0 rows. The S3 bucket contains files under the prefix 'data/'. The Glue crawler created a table with the correct schema. What is the MOST likely cause of the empty output?

⚠ Common exam trap

The trap here is assuming that a successful job run means data was processed, when in fact a filter can exclude all records.

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

✓

The Glue job's script is filtering out all records because of an incorrect partition predicate or a misconfigured pushdown predicate.

When an AWS Glue job completes successfully but processes zero rows, the issue is typically within the job's transformation logic rather than permissions or connectivity. A pushdown predicate or filter that does not match any data will cause the job to read no records. Checking the script for such filters is the first step.

Answer analysis

Option-by-option breakdown

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

✗
The Redshift table is in a different AWS Region than the S3 bucket.
Why it's wrong here
Cross-Region access is possible if permissions and network connectivity are configured. If the region mismatch caused a failure, the job would error out, not succeed with zero rows. Moreover, the job processed zero rows before writing to Redshift, so the write destination region is not the cause of empty input.
✗
The Glue job's output is written to a temporary S3 location instead of Redshift because the connection is misconfigured.
Why it's wrong here
If the connection were misconfigured, the job would fail when attempting to write to Redshift, not silently write to a temporary location. AWS Glue jobs write to the specified destination; there is no automatic fallback to S3. Thus, this does not explain the empty Redshift table.
✗
The Glue job's IAM role lacks s3:GetObject permission on the bucket.
Why it's wrong here
If the IAM role lacked s3:GetObject permission, the Glue job would fail with an access denied error rather than complete successfully with zero rows processed. The job metrics would show a failure, not a successful run with no data. Therefore, this is not the cause.
✓
The Glue job's script is filtering out all records because of an incorrect partition predicate or a misconfigured pushdown predicate.
Why this is correct
A common cause of a Glue job processing zero rows is that the job's script applies a filter that excludes all data, such as a pushdown predicate on a partition column that does not match any partition values. Since the job completed successfully but processed no rows, this is the most likely cause.

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