Courseiva
Security OperationseasyMultiple ChoiceObjective-mapped

SY0-701 Security Operations Practice Question

Before applying a critical patch to a production application server, which action best reduces the risk of extended downtime if the patch fails?

⚠ Common exam trap

A common mix-up: candidates think immediate patching (Option A) is always the best security practice, but the question specifically asks about reducing the risk of extended downtime if the patch fails, not about security speed, so the correct answer focuses on recovery preparedness.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Create a verified backup or rollback plan before making the change.

Creating a verified backup or rollback plan before applying a critical patch ensures that if the patch causes unexpected failures or incompatibilities, the system can be restored to its previous stable state quickly. This directly reduces the risk of extended downtime by providing a reliable recovery path, which is a fundamental principle of change management and risk mitigation in production environments.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Apply the patch immediately without testing so the system is protected sooner.

    Why it's wrong here

    Applying a critical patch without testing in a staging environment that mirrors production can introduce unexpected conflicts with existing configurations, custom code, or third-party dependencies, potentially causing an outage far more damaging than the vulnerability being patched. Change management best practice requires validating the patch in a representative environment, confirming rollback procedures, and scheduling the deployment during a maintenance window to control risk. Immediate deployment may temporarily reduce a known risk, but it trades that benefit for unqualified operational risk, which is unacceptable for a critical production application.

  • Create a verified backup or rollback plan before making the change.

    Why this is correct

    A verified backup or rollback plan is the best safeguard because it gives the team a way to recover quickly if the patch causes instability. In patch management, resilience matters as much as speed. Planning for restoration before the change reduces downtime, supports change control, and helps the business continue operating if the update introduces problems.

  • Disable logging so the patch process uses fewer resources.

    Why it's wrong here

    Disabling logging to conserve resources during a patch installation eliminates the very visibility needed to detect and diagnose failures such as failed services, file permission errors, or privilege escalations that can occur during the change. Logs serve as an historical audit trail for change control and security monitoring, providing evidence of what transpired so issues can be traced and reverted efficiently. In practice, patch processes consume negligible resources compared to the value of operational telemetry, and sacrificing that visibility during a sensitive change makes troubleshooting more difficult and slower.

  • Postpone the patch indefinitely until all business users request it.

    Why it's wrong here

    Indefinitely postponing a security patch leaves known vulnerabilities exposed to exploitation, which is particularly dangerous for a production application that may hold sensitive data or be internet-facing. Patch decisions should be driven by risk assessment, threat severity, and exploit availability, not by waiting for every business user to explicitly request the update—many users may never voice an opinion, but the organization still bears the risk. A reasonable approach is to schedule patch deployment through a defined change window, communicate the impact in advance, and balance availability needs against the security imperative rather than kicking the decision down the road.

About these practice questions

Courseiva writes every SY0-701 question from scratch — 1,013 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.