A Lambda that only writes to one DynamoDB table was given AdministratorAccess to unblock a sprint. What should replace that policy?
Select an answer to reveal the explanation.
Short Explanation
Admin on a single-table writer is a skeleton key for a locker that only needs one padlock. Swap it for a role that can Put/Update that table—and nothing else. Root keys in env vars make it worse.
Full Explanation
A Lambda that only writes to one DynamoDB table but was given AdministratorAccess to unblock a sprint should replace that policy with a least-privilege execution role allowing only the required DynamoDB write actions on that table resource. Broad admin roles turn a simple fee-posting function into a blast-radius nightmare if code or dependencies are compromised. Municipal security reviews expect resource-scoped actions (for example dynamodb:PutItem/UpdateItem on arn:aws:dynamodb:region:acct:table/fees) and nothing else.
Keeping AdministratorAccess and adding a second FullAccess managed policy for redundancy doubles the mistake. Embedding root account credentials in environment variables marked “secure” is catastrophic credential handling. Granting s3:* on all buckets because “DynamoDB eventually stores data in S3-compatible APIs” is both false as an access model and wildly over-privileged.
Exam caveat: least privilege also means separating read and write roles when feasible, denying iam:* from application roles, and preferring AWS managed policies only when they are already narrow enough—which AdministratorAccess never is for app functions.
Operational check: draft a table-scoped write policy; attach it and remove AdministratorAccess; run negative tests proving S3/IAM calls fail; scan all function roles for Admin/FullAccess; and require security sign-off before the next production promote.