A Secrets Manager rotation schedule for an Aurora cluster started failing right after the team moved the rotation function into a different subnet. Logs show timeouts connecting to the database endpoint, with no authentication errors. What is the most probable cause?
Show answer and explanation
Answer: D
A rotation Lambda that runs inside a VPC must reach both the database endpoint and the Secrets Manager endpoint. Moving it to a different subnet can break routing or leave it behind a security group that no longer permits traffic on the database port. Timeouts without authentication errors point to network reachability rather than to credentials or key problems.
Why the other options are wrong
- A. A KMS key rotation does not block reads of an existing secret. Decryption continues with the key material that remains available, so the failing component is elsewhere in the chain.
- B. Scheduled rotation runs without human approval once it is configured. Manual triggers are optional and are not a required step in each cycle.
- C. The runtime version of a rotation function has no required relationship to the database engine version. Network-layer timeouts are not caused by the age of the runtime.