A SaaS startup stores database passwords and third-party API keys in environment variables, needs encrypted storage, automatic rotation every 30 days without code changes, and audit trails of retrieval. Developers share secrets manually. Which secrets management design enables encrypted storage with automatic rotation for the credentials?
Select an answer to reveal the explanation.
Short Explanation
You moved secrets out of sticky notes into a vault. Secrets Manager handles encryption and hands-free swaps through rotation, so apps just ask for the current value by name.
Full Explanation
The correct design succeeds because AWS Secrets Manager stores passwords and API keys encrypted with KMS, schedules native 30-day rotation with Lambda functions that update the secret and protected resource, and lets apps reference secrets by ARN so no code changes are needed, while CloudTrail logs each retrieval to satisfy auditing and remove manual sharing. The SecureString Parameter Store approach fails on automation because although it provides KMS encryption and CloudTrail logging, it lacks a native rotation engine and still needs manual updates or custom automation. The KMS with CI/CD redeployment approach fails on decoupling because although values stay encrypted and refresh on schedule, each rotation bakes new ciphertext into versioned environment variables that require rebuilds and redeploys. The S3 with SSE-KMS and Lambda rotation approach fails on auditability because although encryption, versioning, and automated refresh are sound, bucket logging cannot provide centralized per-secret retrieval trails with caller identity. An exam caveat is to never confuse KMS key rotation, which rotates the encryption key, with secret rotation, which changes the password or key value. As a practical check, enable a 30-day schedule in staging, force a rotation, verify the app uses the new value without restart, and confirm CloudTrail shows retrievals under least-privilege IAM.