A company uses Amazon EMR with Spark to process data daily. The job reads from S3 and writes to S3. Recently, the job started failing with 'S3AccessDenied' errors. The IAM role used by EMR has not changed. What is the MOST likely cause?
Bucket policies can deny access even if IAM allows.
Why this answer
The IAM role used by EMR has not changed, but the S3 bucket policy can be updated independently to deny access to that specific role. An explicit deny in a bucket policy overrides any allow in the IAM policy, causing the 'S3AccessDenied' error even though the role itself remains unchanged. This is the most likely cause because the job was previously working and only the bucket policy could have been modified without touching the EMR configuration.
Exam trap
The trap here is that candidates assume the IAM role is the only factor in access control, overlooking that S3 bucket policies can be modified independently and can explicitly deny access to a specific role, causing 'AccessDenied' errors even when the role itself is unchanged.
How to eliminate wrong answers
Option A is wrong because security groups control network traffic, not IAM authorization; an outbound block would cause a timeout or connection failure, not an 'S3AccessDenied' error. Option C is wrong because deleting and recreating a bucket with the same name would result in a 'NoSuchBucket' error, not an access denied error, and the bucket name would need to be globally unique. Option D is wrong because rotating the EMR service role would change the role's credentials or ARN, which would break the job entirely (e.g., 'AssumeRole' failures), not produce an 'S3AccessDenied' error; the question states the IAM role used by EMR has not changed.