At 02:00 during a restore, a nightly automation holding a stale password hammers the appliance with failed logins, and the account the on-call engineer now needs gets locked out. The outage was survivable; the surprise was not. What should have happened before go-live?
Select an answer to reveal the explanation.
Short Explanation
The stale automation password that locks you out at two in the morning is the oldest trap in operations. Machines shouldn't carry passwords at all - give the automation its own key-authenticated identity and write the unlock procedure down before the incident you can already predict. Lockout is configured behavior; the chaos around it is optional.
Full Explanation
Lockouts triggered by stale automation passwords are the most common avoidable 2 a.m. incident on storage platforms, and they are by-design behavior on any system that respects failed-login policy - repeated bad attempts pause the door. The pre-go-live plan: automations should not carry passwords at all, because key-authenticated machine identities eliminate the stale-password class; the lockout threshold and window should be an agreed, documented configuration rather than a default accident; and the runbook must name who can unlock an account and how. Disabling lockout entirely trades a manageable inconvenience for an open invitation to credential guessing, and it would not survive the review that mandated lockout. Routing automations through the built-in administrative account concentrates both the outage risk and the accountability failure: scripts authenticating as the shared superuser identity is the pattern the named-account model was built to retire. Vault-backed auto-rotation lowers stale-secret frequency but cannot eliminate the race between rotation and long-running jobs, and it still has machines authenticating with human credentials - the wrong model even when it works. Exam caveat: lockout parameters deserve an explicit signed decision - threshold, duration, automatic versus manual release. Operational check: simulate wrong-password attempts until lockout, recover using only what the runbook says, and confirm the automation now authenticates by key.