SY0-701 Security Operations Practice Question

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.