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.

• ✗

  Keep the current backup schedule and shorten the documentation for the restore procedure.

  Why it's wrong here

  Improving documentation alone does not change the actual restoration mechanics: the backup still has to be read, transferred, and rebuilt onto the target system, which will still take longer than the 2-hour RTO. Shortening a runbook may shave minutes from operator decision time, but it cannot reduce the core recovery pipeline time, nor does it address the 30-minute RPO since the original backup schedule remains unchanged. This option treats the symptom of procedural slowness rather than the root cause of insufficient infrastructure for rapid failover.

• ✗

  Switch to weekly full backups and manually verify them after business hours.

  Why it's wrong here

  Weekly full backups directly violate the 30-minute RPO because any data created after the last full backup would be lost, meaning you could lose up to a week of billing transactions. Even with manual verification, the backup itself is a point-in-time snapshot that is not continuously updated, so restoration would still require loading and applying logs to reach a recent state. Additionally, a weekly full backup does not provide a hot or warm environment ready for instant failover, so RTO would still be unmet without a separate recovery system.

• ✗

  Store backups on the same production host so restores are faster.

  Why it's wrong here

  Storing backups on the same production host creates a single point of failure: if the host crashes, suffers a ransomware attack, or has a storage failure, both the production data and the only backup copies are destroyed simultaneously. While this might speed up the restore process by avoiding network transfer, it utterly undermines disaster recovery and does not provide a warm standby that can be brought online with minimal effort. Even if the host were fast, this approach cannot meet the RTO/RPO objectives because it does not offer near-continuous replication or a pre-staged application environment.

• ✓

  Use a warm standby replica with frequent log shipping or near-continuous replication.

  Why this is correct

  A warm standby with frequent log shipping is the best fit because it reduces both data loss and restoration time. The standby already has the operating system and application environment in place, so failover is much faster than rebuilding from scratch. Frequent log shipping narrows the recovery point to within the required 30 minutes, making the design aligned with both business objectives.

Go deeper

Related to this question