AZ-305 Design business continuity solutions Practice Question
A company deploys a critical multi-tier application on Azure VMs. The application includes a database tier that must be recovered to the same point in time as the application tier after a disaster. They use Azure Site Recovery (ASR) for disaster recovery to a secondary region. They also need to run a custom script after failover to update connection strings. Which ASR feature should they use?
⚠ Common exam trap
Many exam-takers confuse multi-VM consistency groups (which ensure crash-consistent recovery across VMs) with the ability to run post-failover scripts, but only recovery plans provide the orchestration layer for custom actions like updating connection strings.
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
✓
Recovery plans with pre-actions and post-actions
Recovery plans in Azure Site Recovery allow you to define pre-actions and post-actions, which can run custom scripts (e.g., PowerShell) after failover to update connection strings. This ensures the application tier can connect to the recovered database tier, meeting the requirement for a custom script execution after failover. The other options do not provide the ability to run custom scripts as part of the failover sequence.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Recovery plans with pre-actions and post-actions
Why this is correct
Recovery plans with pre-actions and post-actions are the correct answer because Azure Site Recovery's recovery plans provide orchestrated failover beyond simple replication. They allow you to group VMs into fault domains and specify a sequence for failover, ensuring critical tiers come online before dependent ones. Pre-actions and post-actions execute custom scripts or Azure Automation runbooks automatically at specific points in the sequence, enabling tasks such as changing connection strings, updating DNS, or health checks. This combination of ordering and automated script execution is exactly what the company needs to recover a multi-tier application cohesively.
- ✗
Replication policies with application-consistent snapshots
Why it's wrong here
Replication policies with application-consistent snapshots are incorrect because these policies control only the frequency and type of replication data captured by Azure Site Recovery. While application-consistent snapshots ensure that the guest OS, apps, and file systems are in a consistent state at the point of snapshot, they do not manage the order in which VMs start during failover. They also lack the ability to execute custom scripts or runbooks as part of the failover flow. Thus, they address data consistency but not the orchestration required to bring up a multi-tier application in the correct order.
- ✗
Multi-VM consistency groups
Why it's wrong here
Multi-VM consistency groups are incorrect because, although they replicate a set of VMs together to ensure they fail over to the same recovery point, they do not provide any sequencing or script automation. This feature of Azure Site Recovery is valuable for workloads that crash-consistently or application-consistently need to be at the same point in time to avoid split-brain or data corruption. However, it does not allow you to define the startup order of VMs or run pre- and post-failover scripts. Therefore, it solves cross-VM consistency but not the orchestration of startup ordering and operational tasks.
- ✗
Azure Backup with cross-region restore
Why it's wrong here
Azure Backup with cross-region restore is incorrect because Azure Backup is fundamentally a backup and restore service, not a disaster recovery orchestration tool. While cross-region restore can restore backed-up VMs to a paired region in the event of a regional outage, it does not support defining failover groups, sequencing startup of VMs, or executing scripts as part of a recovery plan. Restoring from backup involves manual steps or separate automation that is not integrated with recovery plan actions. Thus, it is unsuitable for achieving automated, ordered recovery of a multi-tier application.
Go deeper
Related to this question
Learn chapter
Disaster Recovery Patterns: Active-Active vs Active-Passive
Key term
Disaster Recovery Design
Disaster Recovery Design is the process of planning and implementing strategies to restore IT systems and data after a catastrophic failure, ensuring business continuity with minimal downtime and data loss.
Key term
Azure Site Recovery
Azure Site Recovery is a Microsoft Azure service that keeps your business applications and data running by automatically replicating them to a secondary location and failing over if the primary site goes down.
About these practice questions
One of 795 original AZ-305 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 AZ-305 practice question is part of Courseiva's free Microsoft 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 AZ-305 exam.