You configured an Amazon S3 event source to trigger an AWS Lambda function when objects are created or updated in a specific S3 bucket. The Lambda uses the bucket name and object key from the event to read the object and parse its contents, then writes parsed data to a DynamoDB table. The Lambda's execution role has permissions to read the S3 bucket and write to DynamoDB, but the function is not invoked when objects are added or modified. What fixes the issue?

The correct answer is to add a resource-based policy to the Lambda function that grants Amazon S3 permission to invoke the function for that bucket. For an S3 event notification to successfully trigger a Lambda function, S3 needs explicit permission to invoke that specific Lambda function. This permission is granted via a resource-based policy attached directly to the Lambda function. Adding an S3 bucket policy that grants S3 permission to invoke Lambda is incorrect because S3 itself doesn't need permission to invoke Lambda; rather, the S3 service principal needs permission to invoke a specific Lambda function. Configuring an SQS queue as an on-failure destination or as the target destination for S3 event notifications would change the event flow significantly and is not the direct solution to S3 failing to invoke the Lambda function in the first place. These options introduce additional components and complexity without addressing the core permission issue between S3 and Lambda.