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.

• ✗

  Install the patch on all servers immediately without testing

  Why it's wrong here

  Installing a critical patch fleet-wide without any pre-deployment validation bypasses the change management controls that exist precisely to catch conflicts with existing software, driver, or configuration states. Production environments often host interdependent applications, and an untested patch can introduce service interruptions, data corruption, or security regressions (e.g., breaking authentication modules). The 'speed' of immediate deployment is illusory if it forces an emergency rollback under duress, and it violates the fundamental patch management principle of test before deploy.

• ✓

  Use the emergency change process with testing, approval, and a rollback plan

  Why this is correct

  The emergency change process is the correct path because it preserves the essential safeguards of testing, stakeholder approval, and a defined rollback plan while compressing the timeline for a critical vulnerability. This process typically involves a CAB (Change Advisory Board) or emergency CAB, where the risk of not patching is weighed against the potential impact of the patch itself. Testing on a representative non-production system, even in abbreviated form, validates compatibility and reduces the chance of introducing an outage. A documented rollback procedure ensures that if the patch fails in production, the organization can quickly revert to a known-good state without prolonged downtime.

• ✗

  Wait until the next quarterly maintenance window to avoid any risk

  Why it's wrong here

  Delaying a known critical patch until the next quarterly maintenance window leaves the fleet exposed to active exploitation for weeks or months, which is an unacceptable risk posture for a vulnerability with a known exploit. Many real-world breaches occur within days or even hours of a public vulnerability disclosure, and threat actors actively scan for unpatched systems. While change windows help manage routine maintenance, critical security patches require an expedited process; the quarterly window is a schedule convenience, not a security control. Waiting also allows the vulnerability to propagate laterally across the network if one host is compromised before patching occurs.

• ✗

  Patch only one production server and assume the rest will be fine

  Why it's wrong here

  Patching only one production server is ineffective because it leaves the overall environment with inconsistent security postures, and attackers will simply target the remaining vulnerable hosts. This approach also creates a false sense of security, as the 'patched' server may still be reachable from compromised unpatched peers, allowing lateral movement. Furthermore, a single test in production is not a substitute for controlled testing in a staging environment—it validates nothing about scalability, dependencies, or fleet-wide behavior. Proper remediation requires comprehensive coverage; partial patching is a common cause of residual risk and audit findings.

Same concept, more angles

1 more way this is tested on SY0-701

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.