Database passwords for a transit fare system still sit in SSM Parameter Store as plaintext String parameters. Which secrets-store improvement is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Plaintext parameters are sticky notes on the terminal—fine for non-secrets, terrible for fare-system passwords. Secrets Manager (or properly locked SecureString) plus rotation keeps the credential off the glass and on a schedule. Renaming the parameter does not encrypt it.
Full Explanation
Database passwords for a transit fare system stored as plaintext String parameters in SSM Parameter Store are insufficiently protected secrets. Migrating sensitive credentials to AWS Secrets Manager—or SecureString with strict IAM—and enabling rotation for supported secrets raises confidentiality and reduces static password lifetime. That improvement is appropriate because fare-system credentials deserve encryption at rest, tight retrieve permissions, and automated rotation where engines support it. Leaving plaintext parameters but renaming them with a Secure- prefix fails conceptually: naming is not encryption or access control. Printing passwords into CloudWatch dashboards so on-call can see them fails by broadcasting secrets into broadly readable telemetry. Sharing one password parameter across all environments to reduce rotation complexity fails least privilege and blast-radius isolation between dev and prod. Exam caveat: rotation needs application support for dynamic retrieval; hard-coded connection strings will break when Secrets Manager rotates—update apps first. Operational check: create Secrets Manager secrets for fare DB credentials, grant retrieve only to the runtime roles, enable rotation in nonprod, update apps to fetch at runtime, then cut over production and delete plaintext String parameters.