Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.
A
Distractor review
Keep s3:ListBucket allowed on arn:aws:s3:::customer-data, but restrict s3:GetObject to arn:aws:s3:::customer-data/exports/acme/*.
Restricting GetObject prevents reads outside the prefix, but allowing ListBucket on the whole bucket still lets the role enumerate object keys (for other tenants), which violates the tenant-isolation requirement.
B
Best answer
Allow s3:ListBucket on arn:aws:s3:::customer-data only when s3:prefix equals "exports/acme/" (for example, using a StringEquals condition on s3:prefix). Also allow s3:GetObject only on arn:aws:s3:::customer-data/exports/acme/*.
ListBucket must be authorized at the bucket ARN level, then scoped using a Condition on the request prefix (so only the approved listing prefix is allowed). GetObject is authorized at the object ARN level and is restricted to exports/acme/*, preventing reads outside the prefix.
C
Distractor review
Allow s3:ListBucket only on arn:aws:s3:::customer-data/exports/acme/* and allow s3:GetObject on arn:aws:s3:::customer-data/*.
s3:ListBucket does not accept an object-style ARN as its resource. It must be granted on the bucket ARN. The GetObject scope in this option is overly broad and would allow reads outside exports/acme/.
D
Distractor review
Add a Deny statement for s3:GetObject outside arn:aws:s3:::customer-data/exports/acme/*, but keep s3:ListBucket unrestricted on arn:aws:s3:::customer-data.
Even if GetObject is blocked for other tenants, unrestricted ListBucket still exposes object keys and folder names for other tenants, which is disallowed by the security requirement.