An administrator plans to replace an expiring TLS certificate on a production web server. The web service loads certificates only when it starts. What should the change request account for?
Select an answer to reveal the explanation.
Short Explanation
Some software only reads its settings when it wakes up, like you checking your calendar first thing in the morning. Swap the certificate and the service won't notice until it restarts. Plan that restart, and the short blip it causes, into the change.
Full Explanation
Many services read configuration, including certificates and private keys, only at startup. Replacing the certificate file therefore has no effect until the service is restarted or reloaded, and a restart briefly interrupts connections. Change management treats service restarts and downtime as technical implications that must be planned: the request should state that a restart is required, estimate the interruption, schedule it in an approved maintenance window, and, where possible, use rolling restarts behind a load balancer to avoid customer impact. Reinstalling the operating system is a drastic action unrelated to certificate replacement; restarting the service is enough to load the new certificate. Clients do not need to be blocked for having seen the old certificate; they validate whatever certificate the server presents on each new connection, so a deny list is irrelevant. A certificate signing request is generated by the server that needs a certificate, not by each connecting client, and one CSR for the server is sufficient. Exam caveat: service restart, application restart, and downtime appear together in change management questions, and the expected answer usually involves scheduling them within an approved window. Operational check: after the restart, connect to the site and confirm the new certificate's validity dates and chain, and monitor for errors from clients that pin or cache certificate details.