The part that stands out is treating credential rotation as a state transition rather than a secret update. Changing the database password, updating consumers, and then verifying the running system are three different states, and skipping the last one is where “successful” rotations turn into delayed outages.

One thing I’d add is making the verification itself part of the rotation procedure: test an actual read/write path from each dependent service, not just container health. That catches cases where the container restarted successfully but is still using stale configuration, a different secret source, or a connection pool that never re-authenticated. The real success criterion is restored application behavior, not just a changed password.