Because the Lambda function is successfully triggered by the S3 event notification, the invocation path (S3 → Lambda) is working correctly. The failure occurs specifically when the function tries to write to DynamoDB, which strongly indicates an authorization problem rather than an invocation, scaling, or infrastructure issue.
In AWS, a Lambda function interacts with other services by using its execution role (an IAM role). AWS documentation explains that a Lambda function must have explicit IAM permissions to call downstream services such as DynamoDB. To write items, the role typically needs actions like dynamodb:PutItem (and sometimes dynamodb:UpdateItem, dynamodb:BatchWriteItem, depending on code behavior) on the target table resource ARN. If these permissions are missing or scoped incorrectly, DynamoDB returns an AccessDeniedException (or similar) and the function fails at the write step.
Option A is unlikely because exceeding concurrency would typically prevent invocation or cause throttling at the Lambda service level, not selectively fail only at DynamoDB write time after the function begins executing.
Option B is incorrect: DynamoDB does not require a GSI to support writes. GSIs are for alternate query access patterns, not mandatory for write operations.
Option D is incorrect because DynamoDB is a regional service, not tied to a single Availability Zone, and Lambda does not need to be “in the same AZ” to access it.
Therefore, the most likely cause is that the Lambda execution role lacks the necessary IAM permissions to perform DynamoDB write operations.
