A permit portal AWS Lambda function must read and write items in DynamoDB in the same account without embedding access keys. What should the architect attach?

An AWS Lambda function for a permit portal that must read and write DynamoDB in the same account should use a Lambda execution role with least-privilege DynamoDB actions (for example dynamodb:GetItem, PutItem, Query, UpdateItem on the specific table ARN). Lambda automatically receives temporary credentials from that role via STS; no long-lived keys belong in environment variables, layers, or source code. Least privilege keeps a compromised function from becoming a full-account administrator.

Hardcoding an IAM user access key pair in Lambda environment variables introduces standing secrets that appear in console views, templates, and often logs, and that survive long after rotation should have happened. Storing AWS account root access keys in Lambda layers is an extreme anti-pattern—root must never be an application identity. Mapping every citizen caller through a Cognito identity pool to AdministratorAccess conflates end-user identity with function permissions and grants catastrophic rights to anyone who can obtain those credentials.

Exam caveat: resource-based policies are less central for same-account DynamoDB than for cross-account access; identity policy on the execution role is the primary lever. Include only required keys/conditions (leading keys for Query) when possible. Operational check: invoke the function successfully against the permit table; temporarily remove dynamodb:PutItem and confirm write failures; scan environment variables and layers for AKIA keys and remove any found; review CloudTrail for the execution role ARN on DynamoDB calls.