A critical vulnerability on a production web server has a vendor patch, but the change must be regression-tested before release. The service must remain available during business hours. Which patch action best balances risk reduction with availability?
Select an answer to reveal the explanation.
Short Explanation
Think of patching like changing a tire on a moving bus: you don't yank it off, but you don't ignore the leak either. Stage it, prove it works, then swap it in during a planned stop. If you skip validation or wait a quarter, you trade availability for chaos or risk.
Full Explanation
A controlled patch cycle uses a promotion path: apply the fix in a non-production environment that mirrors the workload, run functional and regression tests, then deploy to production during an approved maintenance window. This preserves availability while reducing exposure because validation catches compatibility failures before they affect live users. For critical vulnerabilities, the cycle may be compressed—staging can be a ring, canary, or limited pilot—but it should not be eliminated. Deploying immediately to all servers is wrong because untested changes can trigger outages, rollback costs, or security-control breakage; urgency lowers acceptable testing depth, not the need for change control. Delaying to a quarterly cycle is wrong because it ignores risk-based prioritization and leaves a known exploitable weakness exposed for an unacceptable period. Patching one production node without testing is wrong because it uses production as a test target and can create inconsistent configurations or a partial outage. Exam caveat: CS0-004 expects you to balance remediation speed with operational impact, not chase the fastest possible patch. Operational check: confirm the patch package, staging validation record, rollback plan, and maintenance-window approval exist before production deployment.