A voter-registration Lambda must PutItem new registrations and Query by voter ID in DynamoDB while running under the function's execution role. How should the developer implement this?
Select an answer to reveal the explanation.
Short Explanation
The Lambda role is the badge that opens DynamoDB—no stuffed-in access keys required. Use the AWS SDK for PutItem and Query, and keep the role scoped to just those actions on that table. Nightly CSV dumps and console clicks are not how an Associate developer integrates from code.
Full Explanation
A voter-registration Lambda that must PutItem new registrations and Query by voter ID should call DynamoDB through the AWS SDK in the handler, relying on the Lambda execution role for credentials and least-privilege permissions. The SDK signs requests with temporary credentials from the execution environment; IAM grants only the needed PutItem and Query actions on specific table and index ARNs. That is the standard secure data-plane pattern for election-adjacent workloads that demand tight auditability and no long-lived keys on disk.
Embedding long-lived IAM user access keys in the deployment package and calling DynamoDB over unsigned HTTP fails security and request-signing requirements. Exporting the table to CSV nightly and parsing files from /tmp abandons online Put/Query semantics the application needs. Granting AdministratorAccess and using the DynamoDB console from inside the function is neither programmatic nor least-privilege.
Exam caveat: encrypt at rest, restrict IAM by resource ARN, and avoid logging full voter payloads. Conditional writes can enforce uniqueness on voter ID. Prefer Secrets Manager only when secrets exist—DynamoDB access itself should be role-based, not key-based.
Operational check: attach a least-privilege execution role; implement PutItem/Query via SDK; verify missing permissions fail closed; confirm no static keys in the package; and review CloudTrail for unexpected DynamoDB APIs from the function role.