AZ-305 Design business continuity solutions Practice Question
A company runs a three-tier application on Azure VMs in the West US region. They want to enable disaster recovery to East US using Azure Site Recovery. The application requires that the web tier starts first, then the application tier, and finally the database tier after a consistency check. They also need to be able to perform non-disruptive DR drills. Which Azure Site Recovery capabilities should they use together?
⚠ Common exam trap
Many candidates confuse general Azure automation or networking features (like runbooks or network mapping) with the specific ASR capabilities required for ordered startup and drills, overlooking that Recovery Plan and Test Failover are the exact ASR features designed for these purposes.
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 Plan with pre/post actions and Test Failover
A Recovery Plan in Azure Site Recovery allows you to define the startup order of tiers (web, app, database) using pre-actions and post-actions, which can invoke Azure Automation runbooks or scripts to perform the consistency check. Test Failover enables non-disruptive DR drills by creating an isolated copy of the replicated VMs in East US without impacting the production environment. Together, these capabilities meet both the ordered startup and drill requirements.
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 Plan with pre/post actions and Test Failover
Why this is correct
An Azure Site Recovery Recovery Plan is the only construct that explicitly determines failover behavior across multiple VMs: you group VMs into ordered groups, and attach pre/post actions via Azure Automation runbooks or custom scripts to stop or start tiers in dependency order (for example, database before middleware before web). The Test Failover feature then executes that exact plan against an isolated Azure Virtual Network, validating scripts, IP assignments, and application startup without affecting the production endpoint. This combination directly addresses both the startup sequencing requirement and the need for periodic non-disruptive drills.
- ✗
Network mapping and IP customization
Why it's wrong here
Network mapping and IP customization configure the target network topology and address translation for replicated VMs—network mapping binds the source VNet/subnet to a target VNet/subnet, while IP customization assigns static addresses to failover replicas so they can communicate on the destination network. These settings are necessary for reachability and DNS after a failover, but they are static configuration values: they neither dictate the order in which application services start across tiers nor provide a built-in method to run a safe drill against an isolated environment. Without a Recovery Plan, failover remains an ad hoc collection of individual VMs coming online with no dependency awareness.
- ✗
Replication policy with crash-consistent snapshots
Why it's wrong here
Replication policy settings define the recovery point objective (RPO) and consistency guarantee for each replicated VM; crash-consistent snapshots capture the disk state at the instant of a crash, equivalent to pulling the power plug, so no in-memory data or pending I/O is included. This policy ensures the VM can be rebooted with a bootable disk, but it says nothing about application-level consistency—and more importantly, it applies per VM, so cross-tier startup ordering is entirely unaddressed. It also offers no mechanism to execute an isolated test failover; the policy only controls how replication copies data, not how recovered workloads are orchestrated or validated.
- ✗
Azure Automation runbooks and Azure Monitor alerts
Why it's wrong here
While Azure Automation runbooks are commonly embedded as pre/post actions inside a Recovery Plan, runbooks by themselves are just executable scripts—they lack the sequencing engine that knows which VM/tier must start first, and they cannot conduct a failover drill because they are not tied to Site Recovery's Test Failover lifecycle. Azure Monitor alerts are useful for detecting workload degradation or triggering an incident response, but monitoring is unrelated to the core requirement of deterministic startup order and safe testing. Selecting only these components omits the Recovery Plan container and Test Failover action, so you get automation and notification tooling without the disaster-recovery orchestration that the scenario explicitly requires.
Go deeper
Related to this question
Learn chapter
Designing Backup and Recovery
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.
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.
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.