Technical Lab: Configure Azure Site Recovery for Azure resources
Questions
Question 1 — Multiple Choice
An operations team needs to configure Azure Site Recovery (ASR) to replicate virtual machines from a primary region to a secondary region. After enabling replication, the engineer realizes that the organization's target RPO (Recovery Point Objective) is 30 minutes. Which statement correctly describes how ASR handles this requirement?
A) ASR replicates synchronously, guaranteeing zero-second RPO by default, regardless of the distance between regions.
B) ASR replicates asynchronously and maintains recovery points with granularity of up to 1 hour, making it impossible to achieve RPO lower than 60 minutes.
C) ASR replicates asynchronously and can achieve RPO of approximately 30 seconds for Azure VMs, but the actual RPO depends on the frequency of recovery point submission and network conditions.
D) ASR requires the engineer to manually configure replication frequency in 15-minute multiples, and the minimum configurable value is 15 minutes.
Question 2 — Technical Scenario
An administrator enabled replication of an Azure VM with ASR and now needs to perform a test failover without impacting the production environment. He executes the test, but the test VM starts in a production virtual network shared with other critical workloads.
What is the error made in this configuration?
A) The test failover should not have been initiated without first executing a planned failover, as ASR requires this sequence.
B) During the test failover configuration, the administrator did not select an isolated virtual network; ASR allows choosing the destination network at this step, and the best practice is to use a separate VNet to avoid affecting production.
C) Test failover in ASR always uses the destination virtual network configured in replication and does not allow overriding this configuration during execution.
D) The error is in the absence of a Network Security Group associated with the test VM, because without it ASR blocks startup in production environments.
Question 3 — True or False
Statement: When executing an unplanned failover in Azure Site Recovery, ASR automatically stops reverse replication and requires the administrator to manually execute the re-protect operation before starting failback to the primary region.
True or False?
Question 4 — Technical Scenario
An engineer configures ASR to replicate Azure VMs and observes the following behavior in the portal:
Replication status: Critical
Alert: Replication health is degraded.
Detail: Upload pending to cache storage account
exceeds acceptable limit. Recovery points may
be outdated.
The source VM consistently shows disk write spikes above 50 MB/s. What is the most likely cause of this behavior and the correct action?
A) ASR does not support disks with write rates above 25 MB/s; the solution is to migrate the VM to a lower IOPS SKU before re-enabling replication.
B) The mobility agent installed on the VM is outdated and needs to be updated to support higher throughput rates.
C) The VM's data churn rate exceeds the capacity of the configured cache storage account; the administrator should verify if the churn limits supported by ASR are being respected and consider optimizing the workload or reviewing disk SKU limits.
D) The problem is caused by the absence of peering between the VNets of the primary and secondary regions, blocking the sending of replicated data.
Question 5 — Multiple Choice
In the context of Azure Site Recovery, what is the functional difference between a Recovery Plan and executing failover directly on an individual VM?
A) The Recovery Plan is mandatory for Azure VM failover; without it, ASR does not allow starting the failover process.
B) The Recovery Plan allows orchestrating failover of multiple VMs in a defined order, including execution of scripts and manual actions between groups, while individual failover does not offer this sequence control and automation.
C) The Recovery Plan applies only to physical machines or VMware replicated to Azure; for Azure VMs, only individual failover is available.
D) The difference is exclusively in execution time: the Recovery Plan parallelizes failovers, while individual failover is always sequential.
Answer Key and Explanations
Answer Key — Question 1
Answer: C
ASR uses asynchronous replication for Azure VMs between regions. This means there is a lag window between data at the source and the replica. ASR is designed to achieve RPO of approximately 30 seconds under ideal network conditions, but the actual RPO depends on the volume of changed data, available bandwidth, and the frequency of recovery point creation.
The main conceptual error in the distractors is confusing synchronous with asynchronous replication (alternative A) and underestimating ASR's actual granularity (alternative B). Alternative D confuses ASR's behavior with Azure Backup, where frequencies are manually configured by the user at fixed intervals.
Choosing A in production would be especially dangerous: designing architecture assuming zero RPO would lead to unrealistic continuity plans.
Answer Key — Question 2
Answer: B
During a test failover execution, ASR allows the administrator to explicitly select the destination virtual network for test VMs. Microsoft's recommended best practice is to use an isolated VNet, without connectivity to production, precisely to validate failover without operational risk.
The error made was not changing the default selection or having incorrectly selected the production VNet at this step. Alternative C is the most dangerous distractor: it reverses ASR's actual behavior, leading the reader to believe there is no network control during testing. Alternative A confuses the test flow with the planned failover flow, which are independent operations.
Answer Key — Question 3
Answer: True
After an unplanned failover, the original replication is interrupted because the source VM may be unavailable or in an inconsistent state. ASR does not automatically configure replication in the reverse direction (from the secondary region back to the primary). The administrator needs to execute the re-protect operation on the VM already in failover, which reverses the replication direction and starts data synchronization back to the primary region. Only after re-protect is completed is it possible to execute failback in a controlled manner.
This behavior is frequently confused with planned failover, where ASR can facilitate more steps automatically. Ignoring the re-protect step and attempting failback without it would result in error or data loss.
Answer Key — Question 4
Answer: C
The alert indicates that data is accumulating in the cache storage account without being transferred to the destination region at the necessary speed. This is a classic symptom of high churn, meaning the rate of data changes on VM disks exceeds the capacity that ASR can process and transfer continuously.
ASR has documented churn limits per disk and per VM. When these limits are consistently exceeded, recovery points stop being created at the expected frequency, degrading the actual RPO.
Alternative D is the most sophisticated distractor: VNet peering is necessary for general network connectivity, but ASR replication transits through the service data plane and does not depend on peering between region VNets. Alternative B is plausible in other contexts, but an outdated mobility agent typically generates distinct alerts, not related to cache account upload rate.
Answer Key — Question 5
Answer: B
The Recovery Plan is ASR's mechanism that allows treating a set of VMs as a coherent recovery unit. Its differential lies in three capabilities: definition of failover groups with execution order, inclusion of automated scripts (via Azure Automation Runbooks), and insertion of manual actions between groups for intermediate validations.
Individual VM failover does not offer any of these controls. In architectures with dependencies between tiers (for example, database before application, application before load balancer), the Recovery Plan is indispensable to ensure failover respects the correct sequence.
Alternative A is an important distractor: the Recovery Plan is a best practice and frequently recommended, but it is not mandatory to start a failover. Alternative D incorrectly simplifies the difference by reducing it only to parallelism, ignoring the entire orchestration and automation layer that the Recovery Plan offers.