A systems administrator has successfully performed a full failover disaster recovery test using a sandbox environment that is logically isolated from the production network. While the test validated the DR procedures and scripts, what is the MOST significant limitation the administrator should report to management regarding this approach?
The test was unable to provide a realistic recovery time objective (RTO) estimate.
The test could have caused an unintentional service outage for production users.
The test could not validate the integrity of the backup media or replicas used for the failover.
The test may not accurately reflect the complexities and dependencies of the live production environment.
The correct answer is that the test may not accurately reflect the complexities and dependencies of the live production environment. Non-production or sandbox environments are designed to be safe, isolated spaces for testing, which prevents impact on live services. However, this isolation is also their primary limitation. It is very difficult and expensive to create a non-production environment that is a perfect 1:1 replica of the production system. There can be subtle differences in hardware performance, network configurations, patch levels, software dependencies, or data volumes that are not present in the sandbox. These differences can lead to a false sense of security, as a real disaster might trigger issues that were not discovered during the isolated test.
A successful restoration and failover, even in a sandbox, inherently validates that the backup media or replicas are integral and usable.
Testing in an isolated sandbox environment is specifically done to prevent causing a service outage for production users, so this is an advantage, not a limitation.
While the recovery time objective (RTO) estimate from a sandbox test may be less precise than a live test, the test can still provide a valuable baseline RTO. It is not entirely unable to provide an estimate.