DEA-C01 Data Ingestion and Transformation Practice Question

A data engineer needs to run an AWS Glue ETL job that reads from an Amazon S3 bucket in another AWS account. The bucket owner has granted cross-account access, and the Glue job runs with an IAM role in the engineer's account. The job fails with an access denied error when reading the source objects. Which change is required to allow the Glue job to read the cross-account S3 data?

⚠ Common exam trap

The trap here is assuming a Glue catalog resource link also grants data access, when it only shares metadata and never authorizes S3 object reads.

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

✓

Add an S3 bucket policy in the source account that grants the Glue job's IAM role s3:GetObject and s3:ListBucket on the bucket.

S3 authorization evaluates both identity-based policies in the caller's account and resource-based policies on the bucket. Because the Glue job's role lives in a different account than the bucket, the bucket owner must attach a bucket policy granting s3:GetObject and s3:ListBucket to that role. Catalog sharing and service-role policies do not extend to cross-account object reads.

Answer analysis

Option-by-option breakdown

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

✓
Add an S3 bucket policy in the source account that grants the Glue job's IAM role s3:GetObject and s3:ListBucket on the bucket.
Why this is correct
Cross-account S3 access requires both the caller's IAM role to allow the S3 actions and the bucket owner to grant those actions through a bucket policy. Since the role already runs in the engineer's account, the missing piece is the resource-based policy in the source account. Adding s3:GetObject and s3:ListBucket for that role resolves the denial.
✗
Recreate the Glue job in the source account so it uses a role owned by the bucket owner.
Why it's wrong here
Moving the job into the source account would work but is a drastic architectural change and not a required configuration fix. The scenario states the bucket owner already granted cross-account access, implying a bucket policy is the intended mechanism. Recreating the job adds operational overhead and duplicates resources unnecessarily.
✗
Attach the AWSGlueServiceRole managed policy to the Glue job's IAM role in the engineer's account.
Why it's wrong here
AWSGlueServiceRole grants Glue service permissions for resources in the same account and does not include cross-account S3 object access. The role already has its in-account permissions; the denial originates from the source bucket lacking a policy for this principal. Adding a broader managed policy in the consumer account cannot override the source account's resource policy.
✗
Enable AWS Glue Data Catalog cross-account sharing by creating a resource link to the source account's catalog.
Why it's wrong here
Resource links share catalog metadata such as table definitions between accounts; they do not grant permission to read the underlying S3 objects. The failure is an S3 access denial, not a catalog lookup problem. Creating a resource link would let the job see table metadata but the S3 read would still be denied.

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