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.

• ✓

  Verify whether the backup included application-consistent data and transaction logs

  Why this is correct

  This is the essential first step because a file-level or crash-consistent backup of a virtual machine may capture the disk state but does not guarantee that applications like SQL Server or Exchange have flushed all committed transactions to disk. Application-consistent backups use VSS or equivalent mechanisms to quiesce the application, ensuring the data files and transaction logs are in a recoverable, synchronized state. Inspecting the backup's metadata and logs reveals whether it supports point-in-time recovery or whether you must fall back to a different recovery source.

• ✓

  Restore the missing records from the latest pre-incident application backup or log backup

  Why this is correct

  Once you have confirmed that the backup is application-consistent and that transaction logs are present, restoring the missing records requires replaying the latest full or differential backup followed by subsequent transaction log backups to roll the database forward to the point of failure. This is the proper recovery procedure, as it reconstructs the exact state of committed transactions that were lost from the primary storage. Without this step, any remaining gaps in the data will be unrecoverable, so the administrator should perform this restore after verifying the backup's consistency.

• ✗

  Leave the server as is because file shares are accessible

  Why it's wrong here

  File share accessibility only indicates that the SMB/NFS service is running and the file system is mounted; it says nothing about the logical completeness or integrity of the underlying application data. Users may be able to open files that appear intact but actually contain stale or missing records because the backup captured an inconsistent database state. Leaving the server as-is without validating the restored data not only ignores the reported loss but also allows users to work with incomplete information, which can lead to further data corruption or incorrect business decisions.

• ✗

  Delete the current backup set to avoid restoring the wrong version again

  Why it's wrong here

  Deleting the current backup set would destroy the only recovery point you have, eliminating the ability to inspect its transaction logs, verify its consistency, or use it as a fallback while you attempt an alternate recovery. The problem is not that the backup is the 'wrong version' but that it may lack application consistency, so removing it does not solve the root cause and instead increases business risk by removing all available recovery artifacts. Proper incident response preserves all backup sets and logs as evidence and as a safety net while you diagnose the restore failure.

• ✗

  Reimage the server immediately without checking the restore point

  Why it's wrong here

  Reimaging the server wipes the operating system and applications, but it does not address the reason the restored data is missing records; when you restore from the same faulty backup again, you will likely reproduce the exact same data loss. It also destroys any forensic evidence, such as application logs or transaction log files, that are necessary to determine what was lost and why the backup was inconsistent. The correct action is to verify the backup's application-consistent status and, if needed, restore from the most recent valid pre-incident application or log backup, not to blindly reapply the same problematic image.