RDS credentials in Secrets Manager rotate every 30 days. The grants API caches the secret in memory and must keep serving traffic when rotation occurs. What should the application implement?
Select an answer to reveal the explanation.
Short Explanation
Rotation day should feel like a pit stop, not a tow truck. When the old password stops working, grab the fresh secret and retry — no citywide outage required.
Full Explanation
When RDS credentials in Secrets Manager rotate every 30 days, a grants API that caches the secret in memory must detect authentication failures after rotation, refresh the secret from Secrets Manager, and retry without requiring downtime. Client-side refresh-on-failure (or proactive refresh near rotation) keeps municipal traffic flowing while AWSCURRENT moves to a new password. This is the expected application behavior alongside managed rotation rather than pinning forever or coordinating fleet restarts by calendar.
Pinning the first-fetched password forever and disabling rotation fails because it abandons the security control auditors expect for database credentials. Restarting the entire Auto Scaling group only on a fixed calendar day fails conceptually—rotation timing, failed restarts, and mid-day rotations can still strand tasks with stale passwords. Storing both current and previous passwords in a public Parameter Store String parameter fails because it publishes credentials and invents an insecure failover channel.
Exam caveat: retries must be bounded and keyed to auth failures to avoid masking unrelated DB outages as rotation events. Operational check: force a secret rotation in a test account, confirm in-memory clients refresh and reconnect, and verify no prolonged 5xx spike requiring an ASG bounce.