A fintech startup stores 80 database passwords and third-party API keys in code and needs encrypted storage, distinct access control, and automatic 30-day rotation without code changes. Which secrets management design meets encrypted storage and automatic rotation requirements?

The correct design works because Secrets Manager encrypts each secret with KMS, supports distinct resource policies for granular least-privilege access to all 80 credentials, and natively schedules Lambda rotation every 30 days with versioned retrieval through API calls so no code change is needed. The Parameter Store SecureString design fails on automation because despite providing KMS encryption and IAM-based access control suitable for many workloads, it natively rotates only limited AWS services and otherwise requires manual value replacement, leaving the automatic rotation requirement unmet and creating operational burden at scale. The consolidated single-secret design fails on isolation because although KMS encryption and scheduled Lambda rotation are preserved, combining all credentials into one object enforces shared access, prevents per-application policies, widens blast radius, and breaks auditability required for distinct control. The encrypted environment variable design fails on seamless operations because although KMS-encrypted variables with IAM policies are common and secure, every rotation forces configuration updates plus redeploy or restart, violating the without-code-changes and fully automatic goals. As an exam caveat, SecureString versus Secrets Manager is a classic distractor and automatic third-party rotation is the decisive signal for Secrets Manager with Lambda. As a practical check, validate the KMS key and resource policies, inspect the rotation schedule and Lambda permissions, perform a trial rotation on a test secret, and monitor CloudTrail and CloudWatch for success and application retrieval without restarts.