A parks reservation API currently stores database passwords in plaintext environment variables on its hosts. Which design best improves credential security?
Select an answer to reveal the explanation.
Short Explanation
Passwords taped to the monitor are fine—until someone walks by with a camera. Secrets Manager (or SecureString parameters) keeps DB credentials vaulted, IAM-gated, and rotatable instead of living in plaintext env vars. Git commits and laminated badges are just more sticky notes.
Full Explanation
Parks reservation APIs that currently store database passwords in plaintext environment variables should move those credentials into AWS Secrets Manager (or SSM Parameter Store SecureString), retrieve them at runtime with IAM-authorized access, and enable rotation where supported. Secrets leave host environment dumps and AMI snapshots as standing plaintext, and IAM controls plus rotation shrink the window if a host is compromised—appropriate for seasonal municipal systems with frequent staff and image churn.
Committing plaintext passwords to the application Git repository fails because source control becomes a distributed secret store with long retention and broad developer access. Printing passwords on laminated badges for seasonal staff fails conceptually: physical badges are shareable, photographable, and unrelated to machine-to-database authentication. Disabling IAM for the API role so the application must hard-code keys forever fails because it removes the authorization mechanism that makes dynamic secret retrieval possible and entrenches static credentials.
Exam caveat: fetching a secret into memory and then logging it, writing it back to an env file, or baking it into a new AMI re-creates the original problem. Operational check: create a rotated secret, grant only the API task/instance role secrets:GetSecretValue (and KMS decrypt if needed), remove plaintext env vars from launch templates, and prove a rotated password still allows the app to connect while old values fail.