A payment service stores 150 database and API credentials in AWS, requires automatic rotation every 30 days, must avoid code changes for new passwords, and needs audit trails for each retrieval. Which secrets design should the architect implement to manage rotation without application redeploys?

Secrets Manager with scheduled Lambda rotation is right because it is purpose-built for database and API credentials, supports rotation schedules for RDS and custom secrets to meet the 30-day requirement, and lets applications fetch the current value at runtime through caching clients. New passwords can therefore take effect without code changes or redeploys, and CloudTrail records retrievals for audit trails. SecureString parameters in Parameter Store provide KMS encryption, versioning, runtime SDK retrieval, and operational logging, but have no built-in rotation engine; reliably rotating 150 secrets on schedule requires custom orchestration. Baking secret values into application images couples credential lifecycle to artifact lifecycle: every rotation then forces a rebuild and redeploy, despite rotation occurring centrally. Encrypted DynamoDB storage with KMS, scheduled Lambda rotation, and in-memory caching can be cost-effective, but does not provide centralized per-secret retrieval auditing and rotation metadata. Exam caveat: when automatic rotation, runtime retrieval without redeployment, and per-retrieval auditing appear together, Secrets Manager is usually the intended service rather than Parameter Store or a custom encrypted store. Practical check: test the rotation Lambda against a staging secret, verify its schedule, CloudTrail events, and caching TTL behavior, and use least-privilege IAM so workloads can retrieve secrets but cannot manage them.