A municipal API architecture uses a resource-based policy on an Amazon SQS queue so only a named Lambda execution role can consume messages. What principle does this apply?
Select an answer to reveal the explanation.
Short Explanation
The queue can hang a sign that says “only PermitLambdaRole may pull messages.” That resource policy works with the role’s identity policy—both doors need to line up. It is not limited to S3, and same-account callers still get evaluated.
Full Explanation
A resource-based policy on an Amazon SQS queue that allows only a named Lambda execution role to consume messages applies the principle that resource policies restrict which principals may act on a resource, complementing identity-based policies. The queue policy can Allow sqs:ReceiveMessage (and related APIs) for the Lambda role ARN and Deny or omit others. The Lambda execution role still needs matching identity permissions; explicit Deny wins. Same-account callers are still evaluated—resource policies are not ignored merely because both sides share an account ID.
Claiming only bucket policies exist as resource policies is false; SQS, SNS, Lambda, KMS, Secrets Manager, and others support resource-based policies. Claiming resource policies are ignored for same-account callers is incorrect. Claiming any principal in the Organization can consume the queue regardless of policy invents an Org-wide bypass that does not exist without explicit grants.
Exam caveat: for Lambda event source mappings, both the queue policy and the execution role permissions must align; cross-account consumers need the queue policy to trust the external role. Prefer least-privilege action lists over sqs:*. Operational check: invoke the permitted Lambda and confirm messages are received; attempt ReceiveMessage with a different role and expect AccessDenied; review the queue policy Principal ARNs after every role rename or recreation.