AZ-305 Design business continuity solutions Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Use crash-consistent replication, recovery plans with manual ordering, and target network with same IP address range

  Why it's wrong here

  Crash-consistent replication captures a point-in-time snapshot of the VM without quiescing the operating system or application, so transactions that are in flight or buffered are lost and the replicated data cannot guarantee a database-consistent recovery point within the required 5-minute RPO. Manual ordering of recovery steps introduces human latency and error, which is insufficient for automated disaster recovery when multiple tiers must start in a specific sequence. While keeping the same IP address range on the target is a step toward IP retention, this option does not specify static IP assignment in failover settings, so the target VM may still receive a new address and the underlying consistency flaw remains.

• ✓

  Use app-consistent replication, recovery plans with pre/post scripts for ordering, and static IP address assignment in failover settings

  Why this is correct

  App-consistent replication uses VSS on Windows or equivalent application quiescing on Linux to flush memory and pending I/O, producing a recovery point that is both VM-consistent and application-consistent, which is essential for a mission-critical database and supports an RPO of seconds. Recovery plans with pre/post scripts automate the ordering of failover steps, such as starting dependent applications or running validation scripts, eliminating manual sequencing delays. Static IP address assignment in the failover settings republishes the original private IPs on the target subnet, satisfying the explicit IP-retention requirement without DNS changes. This combination delivers the required data integrity, automated orchestration, and network continuity.

• ✗

  Use multi-VM consistency groups, recovery plans with automation runbooks, and Azure Traffic Manager to redirect traffic

  Why it's wrong here

  Multi-VM consistency groups ensure that all VMs in the group are failed over together and share a common recovery point, but they do not provide application-level quiescing or manage the IP addressing of recovered VMs. Recovery plans with automation runbooks can orchestrate failover steps, yet Azure Traffic Manager is a DNS-based routing service that directs client traffic at the domain level; it cannot preserve the original private IP addresses of the virtual machines. Because the requirement is specifically to retain IP addresses, the lack of static IP assignment on the target network means this solution fails the core networking constraint even though orchestration and cross-VM consistency are addressed.

• ✗

  Use application-consistent replication, recovery plans with pre/post scripts for ordering, and target network with different IP address range and DNS updates

  Why it's wrong here

  This option correctly adopts application-consistent replication and pre/post scripts to achieve transactional database consistency and automated failover ordering, so those aspects meet the stated RPO and orchestration needs. However, configuring the target network with a different IP address range directly violates the requirement to retain the source VM's IP addresses, and relying on DNS updates to redirect clients does not restore network-level identity. Changing the IP range also breaks hardcoded addresses, connection strings, and firewall rules that depend on the original private IPs, and Azure DNS updates would not satisfy the explicit static IP retention mandate.

Go deeper

Related to this question