A private application reaches S3 through a gateway endpoint, and the route to the S3 prefix list is in place. The IAM role allows s3:GetObject. Gets of one bucket still return Access Denied. The gateway endpoint policy does not allow that bucket. What is denying the call?
Select an answer to reveal the explanation.
Short Explanation
You have a valid route and IAM permission, but the endpoint’s policy still leaves this bucket off the list. Allow the bucket there; adding a route or making the bucket public won’t fix that endpoint denial.
Full Explanation
A gateway endpoint policy is a resource policy on the endpoint. It can limit which buckets and actions may pass, even when the route to the S3 prefix list exists and the caller’s IAM role allows s3:GetObject. Because the endpoint policy does not allow this bucket, it denies the call. The missing-route explanation does not fit: the route is already in place. A public ACL is not required for an endpoint or for an IAM allow to work, and adding one could expose the bucket. Disabled CloudTrail does not block gateway endpoint calls; it affects logging, not authorization. Exam caveat: allowing the bucket in the endpoint policy may not be sufficient if the bucket policy separately denies the role, so a continuing Access Denied can indicate a later policy check. Practical check: confirm the endpoint policy allows s3:GetObject on the bucket’s ARN, then retry from the private instance without adding a public route. The default endpoint policy allows all, so a custom policy may have introduced the restriction. Add the bucket ARN under the GetObject permission or broaden an overly narrow Resource. If the endpoint policy already allows the bucket and the call still fails, check IAM and the bucket policy as the next authorization layers.