Database passwords for the permits API were pasted into plaintext Lambda environment variables that broad IAM roles can read in the console. What is the preferred remediation?
Select an answer to reveal the explanation.
Short Explanation
A password sitting in a plaintext Lambda env var is a sticky note on the monitor — anyone with console rights can read it. Pull secrets from Secrets Manager (or encrypted parameters), not cleartext env configuration.
Full Explanation
Database passwords for a permits API must not live as plaintext Lambda environment variables readable by broad console IAM roles. Preferred remediation is to move the secret into AWS Secrets Manager or SSM Parameter Store SecureString (or at least use KMS-encrypted environment variables with tightly scoped decrypt rights) and retrieve it at runtime with the function's execution role. Municipal permit systems often inherit sticky-note secrets from early prototypes; DVA-aligned remediation restores least privilege and supports rotation without editing function configuration in the console.
Widening IAM roles so every developer can rotate plaintext values fails because it expands who can read the secret rather than removing the anti-pattern. Base64-encoding the password fails conceptually—encoding is not encryption and is trivially reversible. Moving the password into the Lambda function name fails because it still places the secret in a widely visible configuration attribute and pollutes naming.
Exam caveat: encrypted env vars still expose decrypt capability to principals who can update function configuration and decrypt with the key; Secrets Manager with rotation is usually the stronger long-term pattern. Operational check: remove plaintext env values, grant secretsmanager:GetSecretValue (or ssm:GetParameter with decryption) only to the permits function role, and verify console viewers without that permission cannot read the password.