At midnight every application connection to a production database began failing with TLS handshake errors. The DBA finds that the server certificate reached its expiry date, issues a replacement, and restores service. Which practice would best prevent a repeat of this outage?
Select an answer to reveal the explanation.
Short Explanation
Certificates are like milk: they have a printed expiry date, and nobody's surprised when it goes off, unless nobody looked. You fix this with inventory and alerts that warn you weeks ahead so renewal is routine. Don't fall for 'just ignore expiry'; that's turning off the smoke alarm because it beeped.
Full Explanation
Every X.509 certificate carries a validity period, and clients that validate certificates refuse a handshake once the not-after date passes. The outage was caused by an unmanaged lifecycle, not by a technical fault, so the durable fix is lifecycle management: keep an inventory of certificates used by database servers, monitor their expiry dates, alert the responsible team well before expiry, and renew and deploy the replacement in a planned change, automating renewal where the CA supports it. Configuring drivers to ignore expiry errors keeps connections working by weakening validation, which accepts certificates that should no longer be trusted and usually requires disabling checks that also guard against impersonation. A self-signed certificate with a multi-decade validity period trades one problem for a worse one: clients will not trust it without manual trust-store changes, and a long-lived key that is never rotated increases exposure if it is compromised. A nightly service restart only reloads whatever certificate is installed; it does not obtain a new one, so the expired certificate would still be rejected. Exam caveat: renewal must be planned before expiry, not discovered by an outage. Operational check: list every database certificate with its expiry date, confirm an alert fires at the chosen lead time, and record the renewal owner.