SY0-701 Security Program Management and Oversight 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.

• ✗

  Move the appliance onto the flat user VLAN so the team can monitor it with standard workstation tools.

  Why it's wrong here

  Moving the unsupported appliance onto the flat user VLAN eliminates existing security zone boundaries, placing a known-unpatchable system on the same broadcast domain as every user endpoint. Any malicious client or compromised workstation can then directly probe and attack the appliance, while the appliance itself—if breached—can pivot laterally to the entire user base. Standard workstation monitoring tools do not address the root cause of missing patches and actually add agent attack surface on an already fragile system.

• ✓

  Restrict network paths to only the required upstream and downstream systems through firewall allow-lists.

  Why this is correct

  Enforcing firewall allow-lists to permit only the specific upstream and downstream systems and required ports creates a strict micro-perimeter around the appliance. Because the unsupported OS cannot be patched, this drastically reduces the attack surface by blocking all other network traffic, including opportunistic scans and malware command-and-control attempts. If the appliance is compromised, the blast radius is limited to those allowed paths, making containment easier and providing an additional layer of defense in depth.

• ✗

  Declare the risk fully accepted and make no configuration changes until the replacement is ready.

  Why it's wrong here

  Declaring the risk fully accepted is a documentation exercise that does not alter the appliance's exposure—every unpatched vulnerability remains exploitable throughout the 60-day period. A risk acceptance form without supplemental mitigation still requires compensating controls to satisfy due-care obligations, and it shifts the stance from defense-in-depth to pure tolerance of an arbitrary compromise. It also provides no concrete plan for detection, response, or reduction of the attack surface in the interim.

• ✓

  Add compensating controls such as application allow-listing, enhanced logging, and SIEM alerting.

  Why this is correct

  Deploying application allow-listing confines the appliance to a known set of executables, so even if an attacker exploits a vulnerability, they cannot easily run arbitrary tools or persistent payloads without breaking the allow-list. Enhanced logging plus SIEM alerting creates a detective control that captures unusual process, network, or authentication activity and notifies the team in near real time. These compensating controls lower residual risk by making exploitation harder to execute and far more likely to be seen before substantial damage occurs.

• ✗

  Disable logging because the appliance is already at capacity and logs can slow it down.

  Why it's wrong here

  Disabling logging on an unsupported appliance removes the primary source of forensic and detection evidence exactly when that visibility is most needed, leaving the team blind to an ongoing intrusion. Without logs, security teams cannot determine whether a known exploit was used, what data was accessed, or which other systems may have been contacted, severely hampering incident response and containment. The correct approach is to configure log rotation and forward logs to a central collector so capacity is managed without losing the audit trail.

Go deeper

Related to this question