A company creates an interface VPC endpoint for a supported AWS service and attaches a custom endpoint policy that restricts access to a specific IAM role. A developer using that role also has an identity-based IAM policy that denies the same action. What is the net effect, and how do these policy layers relate?
- The endpoint policy always overrides identity-based and resource-based policies, so the action is allowed regardless of the IAM deny
- The endpoint policy does not override or replace identity-based or resource-based policies; it is an additional resource-based control layer, so an explicit IAM deny still blocks the action even though the endpoint policy would otherwise permit it
- Endpoint policies only apply to gateway endpoints, so this interface endpoint ignores the attached policy entirely
- Since no endpoint policy was ever explicitly required, AWS denies all access to the endpoint by default until one is attached
Why B? And why not the others?
Correct answer: B. The endpoint policy does not override or replace identity-based or resource-based policies; it is an additional resource-based control layer, so an explicit IAM deny still blocks the action even though the endpoint policy would otherwise permit it
AWS states directly that 'an endpoint policy does not override or replace identity-based policies or resource-based policies' — it's an additional, independent authorization layer attached to the endpoint itself, alongside identity-based IAM policies and any resource policies (like an S3 bucket policy). Standard IAM evaluation logic still applies across all applicable policies: an explicit deny in any evaluated policy, including an identity-based one, blocks the action even if every other applicable policy would allow it. Option A inverts this relationship; the endpoint policy is not a trump card over other policy types. Option C is wrong because endpoint policies apply to both interface and gateway endpoints, just with slightly different principal-specification rules (gateway endpoints require the Principal element to be '*' and use a condition key instead). Option D is wrong because AWS attaches a default endpoint policy that grants full access if you don't provide a custom one, rather than denying everything.
Source: AWS PrivateLink docs: Control access to VPC endpoints using endpoint policies