A critical vulnerability is found in a production web service. A vendor patch exists, but applying it requires a maintenance window. The service owner worries about downtime, and the security team wants the risk reduced quickly. Which approach best balances vulnerability closure with service availability?
Select an answer to reveal the explanation.
Short Explanation
Think of patching production like surgery: you can't just cut because the risk looks scary, and that trap is why uncontrolled changes cause outages. You submit a change request, schedule a window, test the fix, and keep a rollback plan ready. That way you close the vulnerability without blowing up availability.
Full Explanation
Controlled change management is correct because production remediation must balance risk reduction with service availability. The analyst routes the patch through a formal change request so it is risk-assessed, tested, scheduled in an approved maintenance window, and supported by rollback. If immediate patching is unsafe, compensating controls such as segmentation or WAF rules reduce exposure while the change proceeds. Immediate production deployment is wrong because bypassing change control can cause an outage or regression that harms availability more than the vulnerability. Waiting for the next quarterly cycle is wrong because critical vulnerabilities should not be deferred without documented risk acceptance or compensating controls. A temporary exception that only delays remediation is wrong unless it includes formal acceptance, controls, ownership, and an expiration date. Exam caveat: CS0-004 expects the governance process that makes remediation safe, not the fastest technical action. Operational check: submit a change ticket with the vulnerability ID, affected asset, CVSS or KEV context, patch, maintenance window, rollback plan, and interim controls.