Overnight monitoring shows several thousand failed login attempts against a privileged database account, all from a single external IP address within two hours. No successful logins from that address are recorded. How should the DBA treat this event?

Monitoring failed and attempted connections is both a health signal and a security control. A burst of failed logins against a privileged account from one external address is a classic pattern of password guessing or credential stuffing. The appropriate response is to treat it as a potential security incident: notify the security team according to the escalation procedure, investigate the source and timeline, block or restrict the address at the firewall, confirm the account has a strong credential and lockout or throttling controls. Dismissing the event because no attempt succeeded ignores that the attacker may keep trying or switch accounts, and that exposure itself is a finding. Raising the maximum connection limit treats the event as a capacity problem; failed authentications are not a sign of insufficient connection slots, and raising the limit gives an attacker more room. An expired password produces failures from the legitimate application's hosts, typically with a specific error, not thousands of attempts from an unknown external address; resetting and resharing the password would also mishandle a credential. Exam caveat: connection monitoring distinguishes concurrent connections, a capacity metric, from failed or attempted connections, a security metric. Operational check: pull authentication logs for the period, confirm no success from that source, block it, review exposure of the listener, and document the incident.