SY0-701 Security Architecture 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.

• ✗

  Document the deviations and rely on manual checks after each maintenance window

  Why it's wrong here

  Documentation and manual checks after maintenance windows are inherently reactive and dependent on human follow-through. Configuration drift can occur at any time, not just during scheduled maintenance, and a manual review cannot continuously verify that all services, registry keys, and permissions remain at the hardened baseline. Even with a checklist, repeated inconsistencies across many servers will be missed, and documentation does not enforce or remediate insecure settings. This approach does not scale and leaves security controlled by memory and discipline rather than automation.

• ✓

  Deploy configuration management that enforces the hardened baseline continuously

  Why this is correct

  Continuous configuration management is the best answer because it can reapply the approved baseline and correct drift across many systems automatically. This approach does more than detect the problem; it helps prevent the same insecure settings from persisting after troubleshooting or emergency changes. It is the most effective way to standardize hardening at scale and keep the environment aligned to policy.

• ✗

  Run a vulnerability scan more often and close the findings in the ticketing system

  Why it's wrong here

  A vulnerability scanner provides a point-in-time snapshot of known weaknesses but cannot correct the underlying drift that allows insecure services or settings to persist. Closing findings in a ticketing system creates a manual remediation loop that still depends on an administrator to reapply the baseline, and the same issue will likely reappear after the next change. Additionally, scanners may miss configuration issues that do not map to a specific CVE, and they do not address the enforcement gap. The goal should be automated remediation, not just more frequent detection of the same recurring problems.

• ✗

  Increase storage capacity so the image can be rebuilt faster next time

  Why it's wrong here

  Increasing storage capacity does nothing to prevent or repair configuration drift because the problem is logical state, not disk space. Even if the image can be rebuilt faster, the new server will inherit the same insecure modifications unless the build process itself enforces the hardened baseline. A larger storage allocation only helps with backup or image placement, but it cannot reapply disabled security policies or re-enable blocked services. The root cause is the lack of continuous configuration enforcement, so improving storage architecture is orthogonal to the security failure.

Go deeper

Related to this question