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.

• ✗

  Mark the restore complete because the file server is reachable

  Why it's wrong here

  The file server responding to network requests only proves that the operating system, network stack, and basic services like SMB are running. It does not verify that the restore populated the correct files, retained NTFS/Share permissions, or that the accounting application's databases and transaction logs are internally consistent. A missing or corrupted file may go unnoticed until a user tries to access it, which is not a valid success criterion.

• ✓

  Verify the restore in an isolated test environment and compare application data consistency

  Why this is correct

  Restoring into an isolated lab environment allows you to boot the recovered virtual machine without affecting production traffic, then run application-level integrity checks on the accounting data. Compare database row counts, checksums, or last transaction timestamps against a known-good baseline, and validate that transaction logs are consistent with the application's journal. This confirms the backup is not just restorable, but that the application can operate on the recovered data, making it the only definitive validation of a successful restore.

• ✗

  Immediately run a new full backup over the restored server

  Why it's wrong here

  Immediately launching a full backup over the restored server may capture an incomplete or inconsistent state and overwrite the last known-good backup media, leaving you without a recovery point if the restore is later found faulty. Backup software does not validate the logical integrity of application data; it simply copies bytes, so a corrupt state becomes your new backup baseline. Wait until the restore is verified as consistent, then consider taking a new full backup to establish a clean baseline.

• ✗

  Disable the accounting application permanently to prevent further inconsistency

  Why it's wrong here

  The data inconsistency stems from an incomplete or non-atomic restore of the accounting application's database files, not from the application process itself. Disabling the application permanently prevents users from issuing new transactions but does not repair the restored data or confirm that previously recorded transactions are intact, and it needlessly halts business operations. The correct response is to restore from a known-good backup, possibly with transaction log replay, and then validate data consistency.