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.

• ✗

  Make the change directly during business hours without documentation

  Why it's wrong here

  Directly editing ACLs on a production firewall during peak hours without any change record eliminates the ability to compare pre- and post-change rule sets, making rollback a manual, error-prone reverse-engineering effort. If the SaaS integration misbehaves, there is no governance trail to identify which rule was changed or who approved it, violating the separation of duties and auditability principles required in regulated environments. Furthermore, business-hours implementation needlessly risks a denial of service for all users on the firewall if a syntax error or logic flaw is introduced, whereas a formal window allows for staged testing and immediate remediation.

• ✓

  Follow formal change management with approval, testing, and rollback planning

  Why this is correct

  Formal change management ensures that the ACL modification is vetted against security policy, tested in a non-production environment or with a peer review to catch ordering errors or unintended broad access. It provides a documented change window, an escape plan to revert the firewall to a known-good configuration, and post-implementation validation that the SaaS integration works without weakening the firewall posture. This aligns with ITIL and NIST change management practices, ensuring auditability and accountability for a production network change.

• ✗

  Disable logging temporarily so the firewall change applies faster

  Why it's wrong here

  Disabling logging on a production firewall during a change removes the very telemetry needed to detect whether the new ACL is misrouting traffic or allowing unauthorized access; the firewall is already processing packets quickly, so logging rarely affects the speed of applying a rule. More importantly, this workaround completely sidesteps the need for change approval and rollback planning, and it introduces a new risk: if the admin forgets to re-enable logging, the security team loses critical audit records for all traffic, potentially violating compliance requirements like PCI DSS or SOC 2. The change itself is still unapproved and untested, so the core failure remains.

• ✗

  Ask the vendor to modify the firewall remotely without internal review

  Why it's wrong here

  Allowing a SaaS vendor to directly connect to the production firewall and modify ACLs bypasses the organization's change control processes, meaning no internal validation of the exact rule syntax, source/destination IP ranges, or ports being opened. This creates a supply-chain risk because the vendor's credentials could be compromised, and any misconfiguration becomes an unapproved, undocumented drift that is exceptionally difficult to trace during incident response. Even if the vendor is trusted, remote external changes violate the principle of least privilege and negate the firewall administrator's ability to maintain a controlled baseline and test the change against internal security policies.

Go deeper

Related to this question