Design business continuity solutions →mediumMultiple Choice

AZ-305 Design business continuity solutions Practice Question

Exhibit

{
  "properties": {
    "provisioningState": "Succeeded",
    "recoveryServicesProvider": "HyperVSiteRecovery",
    "replicationHealth": "Normal",
    "currentRecoveryPoint": "2026-02-15T10:30:00Z",
    "primarySite": "OnPremises",
    "recoverySite": "EastUS"
  }
}

Refer to the exhibit. You are reviewing the replication health of an on-premises Hyper-V VM replicated to Azure using Azure Site Recovery. The JSON output shows the properties of the replicated item. The replication health is 'Normal', but the last recovery point is from 2 hours ago. You need to ensure the Recovery Point Objective (RPO) of 15 minutes is met. What is the most likely cause of the issue?

⚠ Common exam trap

Candidates often assume 'Normal' health means all replication settings are optimal, overlooking that the replication frequency is a separate configurable parameter that directly controls the RPO, and a 2-hour gap can occur even with healthy replication if the frequency is set too high.

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

✓

The replication frequency is set to 30 minutes or more.

The replication frequency for Hyper-V replication to Azure using Azure Site Recovery (ASR) can be set to 30 seconds, 5 minutes, or 15 minutes. If the last recovery point is 2 hours old despite 'Normal' health, the replication frequency is likely configured to 30 minutes or more, which directly prevents meeting a 15-minute RPO. ASR's replication frequency setting controls how often changes are sent to Azure, and a value exceeding 15 minutes would cause the observed gap.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The VM's application-consistent snapshot is failing.
Why it's wrong here
The replication health status in Azure Site Recovery aggregates issues from the replication engine, including VSS snapshot failures. If the application-consistent snapshot were failing, the portal would display a warning or critical alert with an error code from the VSS writer, not a 'Normal' health state. The exhibit shows a normal health state with a 2-hour-old recovery point, which is an RPO (recovery point objective) issue rather than a snapshot failure. Additionally, app-consistent snapshot failures typically generate a specific event in the Site Recovery job history, which would be visible if present.
✗
The target region is not correctly configured in the recovery plan.
Why it's wrong here
The target region for Hyper-V replication is configured at the policy level or when enabling protection, not within the recovery plan itself. The exhibit explicitly shows the recovery site as EastUS, which indicates the target location is correctly set and the replication is actively running to that region. If the target region were misconfigured, enabling replication would fail or the replicated item would display a configuration error, rather than showing a healthy replication with a stale recovery point. The recovery plan is only a sequencing container for failover, so it does not dictate the target region for replication.
✗
The Hyper-V host is not registered with the Recovery Services vault.
Why it's wrong here
For Hyper-V to Azure replication, the Hyper-V host must have the Azure Site Recovery Provider installed and registered to the Recovery Services vault. The exhibit displays the 'recoveryServicesProvider' property, which is populated only after a successful registration of the host. If the host were unregistered, the protected item would not be listed as 'Normal' — it would show as 'Not protected' or the replication would have never been enabled. The provider registration is a prerequisite for replication, and the presence of a recovery point confirms the provider is functioning.
✓
The replication frequency is set to 30 minutes or more.
Why this is correct
Azure Site Recovery generates recovery points based on a configured replication frequency, which for Hyper-V can be 30 seconds, 5 minutes, 15 minutes, or a custom interval. The exhibit shows the latest recovery point is 2 hours old, while the health is 'Normal' — this combination implies the replication policy's frequency is set to 30 minutes or more, allowing the RPO to be met. If the frequency were 15 minutes, the latest recovery point would be within 15 minutes of current time under healthy conditions. Therefore, the stale recovery point is a direct consequence of a long replication frequency, not an error.

Go deeper

AZ-305 Design business continuity solutions Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question