An S3 bucket event cannot invoke a redaction Lambda because the function's resource-based policy does not allow the bucket's principal. What should the developer fix?
Select an answer to reveal the explanation.
Short Explanation
S3 is buzzing the doorbell, but Lambda’s resource policy never listed the bucket as a guest. Add the invoke permission for the S3 principal—don’t rip out IAM or hope weekly email is a trigger.
Full Explanation
When an S3 bucket event cannot invoke a redaction Lambda because the function’s resource-based policy does not allow the bucket’s principal, add an invoke permission on the Lambda resource-based policy (or equivalent event-source permission) that allows the S3 bucket service principal to call the function. Event sources need explicit permission on the function resource; execution roles alone do not grant S3 the right to invoke. This is a common municipal “trigger configured but never fires” failure mode.
Removing the Lambda execution role so the function runs without IAM and can be invoked by anyone breaks the function’s own AWS API access and is not how resource policies work. Putting Deny:* in a Lambda environment variable and expecting S3 to honor it as a resource policy confuses config with IAM. Replacing the S3 event trigger with weekly manual invokes abandons automation.
Exam caveat: permissions should scope to the specific bucket ARN/source account to avoid confused-deputy risks. If using EventBridge with S3, ensure the rule target permissions are also correct. CloudTrail can show InvokeFunction denied events for diagnosis.
Operational check: add lambda:InvokeFunction permission for s3.amazonaws.com with source ARN conditions; retry a test PutObject; confirm invoke appears in metrics; and remove any overly broad principal wildcards from review findings.