Skip to main content

Technical Lab: Perform a Failover to a Secondary Region by Using Site Recovery

Questions​

Question 1 — Multiple Choice​

An operations team needs to validate the recovery plan before an actual event. The production environment cannot be interrupted and the replicated VMs must remain protected at the end of the process.

Which type of Azure Site Recovery operation meets this requirement?

A) Planned failover, because it temporarily interrupts replication but preserves the source environment.

B) Test failover, because it executes the failover in an isolated network without affecting ongoing replication.

C) Unplanned failover, because it can be executed without confirmation and reverted immediately.

D) Failback, because it moves workloads back to the primary region without impact on replication.

Question 2 — Technical Scenario​

An administrator executes an unplanned failover of a critical VM to the secondary region. After confirming that systems are operational in the secondary region, they need to ensure that the VM from the primary region doesn't interfere with operations and that reverse replication is configured.

What is the correct sequence of actions after the successful failover?

A) Delete the VM from the primary region, reconfigure the vault, and create a new replication policy.

B) Execute "Commit" on the failover and then enable reverse replication to protect the VM in the new primary region.

C) Execute "Failback" immediately to the original region and then reactivate replication.

D) Execute "Re-protect" without first confirming the failover, since commit is optional in unplanned failovers.

Question 3 — True or False​

During a test failover in Azure Site Recovery, the virtual machines started in the secondary region use the same IP addresses as the production VMs, which can cause network conflicts if the test network is not isolated from the production network.

Question 4 — Technical Scenario​

An administrator configures a Recovery Plan in Azure Site Recovery to orchestrate the failover of a three-tier application: database, backend, and frontend. During a test failover, the frontend comes up before the database, causing startup failures.

Recovery Plan — current order:
  Group 1: frontend-vm
  Group 2: backend-vm
  Group 3: database-vm

What is the cause of the problem and how to fix it?

A) The Recovery Plan doesn't support more than two groups. The solution is to separate the application into two distinct plans.

B) The group order is inverted. The database should be in Group 1 to start first, followed by backend and frontend.

C) The problem is the absence of validation scripts. The group order doesn't influence the VM startup sequence.

D) Groups in a Recovery Plan are always executed in parallel, so the order cannot be controlled by this mechanism.

Question 5 — Multiple Choice​

After a successful failover to the secondary region, the team decides that the secondary region will be the new permanent production environment. Which statement correctly describes what happens with replication in this scenario?

A) The original replication automatically continues in the opposite direction, protecting the new primary region as soon as the failover is completed.

B) Replication is paused after failover and must be manually reactivated through the "Re-protect" operation, which reverses the direction of replication.

C) Replication is permanently terminated after failover commit and cannot be reestablished without recreating the vault.

D) The failover confirms the existing replication and keeps it active in the same direction, protecting the original primary region.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The test failover is the mechanism designed exactly for validation without impact. It creates VMs in the secondary region within an isolated network specified by the administrator, so that ongoing replication is not interrupted and the original production VM remains active and protected.

Planned failover (A) interrupts replication and shuts down the source VM before starting the failover, being indicated for controlled migrations. Unplanned failover (C) is intended for real disasters and, although it can be reverted via "Discard," it's not the approach for safe validation. Failback (D) assumes that a failover has already occurred and has the opposite direction to what the question describes.

Answer Key — Question 2​

Answer: B

After an unplanned failover, the correct flow is: first Commit, which finalizes the failover, discards previous recovery points and signals to Site Recovery that the secondary region is now active; then Re-protect (reverse replication), which starts replicating from the new primary region back to the original.

Alternative D represents a critical misconception: "Re-protect" can only be executed after commit. Without commit, the failover is in a pending state and reverse replication cannot be configured. Alternative C reverses the logic by proposing immediate failback before stabilizing the environment. Alternative A is destructive and unnecessary; the vault and policies don't need to be recreated.

Answer Key — Question 3​

Answer: True

This statement is true. By default, Site Recovery attempts to preserve VM IP addresses during failover. If the network used in test failover is not isolated from the production network, there will be IP conflicts, potentially causing instability in both VMs. Therefore, Microsoft recommends always creating a dedicated and isolated virtual network for failover testing. This behavior is a point of attention frequently overlooked in environments where the test network is not properly planned.

Answer Key — Question 4​

Answer: B

In a Recovery Plan, groups are executed sequentially: Group 1 starts first, then Group 2, and so on. The presented configuration places the frontend in Group 1, making it come up before the database, which generates the described failures. The correction is to reorganize the groups by placing the database in Group 1, the backend in Group 2, and the frontend in Group 3.

Alternative C denies the fundamental functioning of groups, which do control the order. Alternative D confuses the behavior of groups with the behavior of VMs within the same group, which come up in parallel. Alternative A is factually incorrect; Recovery Plans support multiple groups.

Answer Key — Question 5​

Answer: B

After committing a failover, replication is stopped. Azure Site Recovery does not reverse the direction automatically. The administrator needs to execute the Re-protect operation, which reconfigures replication in the reverse direction, i.e., from the new primary region to the old one. Without this action, the VM that became production in the secondary region is not protected against failures.

Alternative A represents the most common misconception: assuming that Site Recovery manages replication reversal automatically. Alternative C is wrong because the vault and replication capability are preserved after commit. Alternative D contradicts the actual behavior, as the original replication is terminated at the moment of commit.