The business-license renewal Lambda must obtain RDS credentials at runtime with managed rotation, not from a checked-in .env file in the repository. Which approach meets that requirement?
Select an answer to reveal the explanation.
Short Explanation
Checked-in .env files are yesterday's USB stick under the keyboard. Let the Lambda ask Secrets Manager for the current RDS password when it runs, with rotation doing the heavy lifting.
Full Explanation
The business-license renewal Lambda should obtain RDS credentials at runtime from AWS Secrets Manager with managed rotation, using the function's IAM role to call GetSecretValue. Secrets Manager is designed for this municipal pattern: credentials are not checked into repositories, rotation can integrate with RDS, and every invocation can receive the current secret version. That meets the requirement of managed rotation without a checked-in .env file and keeps production passwords out of SAM build contexts.
Committing a production .env to a private Git branch and loading it during SAM build fails because the secret still enters version control and build artifacts. Hard-coding the password in the handler and rotating by editing source fails conceptually—source edits are not managed rotation and leave history full of old passwords. Emailing the DBA password to on-call chat after each deploy fails because chat logs become an uncontrolled secret store.
Exam caveat: the execution role needs least-privilege access to the specific secret ARN (and KMS decrypt if a CMK encrypts the secret); wildcards invite lateral movement. Operational check: enable rotation on the RDS secret, confirm the Lambda retrieves AWSCURRENT at runtime, and ensure no .env or hardcoded password remains in the deployment package.