SY0-701 Security Operations Practice Question
After restoring a virtualized file server from backup, users can log in but the accounting application returns database consistency errors. What should you do next?
⚠ Common exam trap
A common mix-up: candidates assume a successful VM boot and user login equate to a complete restore, overlooking the need to validate application-level data integrity and permissions in an isolated test environment.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Verify the restore in an isolated environment and confirm application-level integrity and permissions.
The restore process must be validated beyond basic boot and login functionality. Database consistency errors indicate that the application-level data integrity was compromised during the restore, likely due to missing or inconsistent database files, permissions, or transaction logs. Verifying the restore in an isolated environment allows you to test application-specific integrity checks (e.g., DBCC CHECKDB for SQL Server) and confirm that file permissions and security descriptors are intact before returning the server to production.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Declare the restore successful because the virtual machine boots and users can sign in.
Why it's wrong here
A successful boot and interactive sign-in only prove the guest OS started and the hypervisor can present the virtual disk; they do not validate that the restored file server's underlying data files, NTFS/Share permissions, shadow copies, or application services (e.g., FSRM, DFS, or a database backend) are consistent. Users being able to sign in simply means the OS and authentication stack came up, but the actual reason the restore was performed—such as recovering a damaged file share or enforcing ACLs—may still be broken. Without checking file-level integrity, ACL inheritance, or the status of dependent roles, declaring success is premature and risks replicating the original corruption into production.
- ✓
Verify the restore in an isolated environment and confirm application-level integrity and permissions.
Why this is correct
This is the best next step because a restore is only useful if the data and application work as expected. Testing in an isolated environment lets you confirm database consistency, file permissions, application dependencies, and any version mismatches without risking production impact. That approach also helps determine whether the backup itself is valid or whether a separate application or storage issue is causing the errors.
- ✗
Increase the backup retention period and wait for the next scheduled full backup.
Why it's wrong here
Increasing the backup retention period only preserves more historical copies; it does nothing to validate or repair the current restore. Waiting for the next scheduled full backup ignores the fact that the current restore may have failed due to corruption, an incomplete catalog, or a missing application-consistent state, and the next backup may simply capture the same faulty data. A retention policy change cannot fix a failed restore or prove that the recovered file server's data, permissions, and application dependencies are intact—it merely delays the decision and leaves users without a working file server.
- ✗
Delete the backup set to prevent confusion with the restored data.
Why it's wrong here
Deleting the backup set eliminates the only known-good recovery source and would permanently remove the ability to re-restore the original data if the current restore is later found to be flawed. Confusion about which copy is authoritative is best resolved by labeling or isolating the restored environment, not by destroying backups. This action also violates the 3-2-1 backup rule and removes the ability to roll back to a previous known-good state, directly jeopardizing the organization's recovery point objectives (RPOs) in the event the current restore is unusable.
Go deeper
Related to this question
Learn chapter
Incident Response Process
Key term
Accounting
Accounting in IT identity and access management is the process of tracking and logging what authenticated users do on a system or network.
Key term
SQL
SQL is a standard programming language used to manage, query, and manipulate relational databases by issuing commands like SELECT, INSERT, UPDATE, and DELETE.
About these practice questions
One of 1,013 original SY0-701 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.