AZ-900 Describe Azure architecture and services 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.

• ✓

  Create a Recovery Services vault, then enable replication for source VMs specifying target settings, then run a test failover, then monitor replication health.

  Why this is correct

  This is the only technically valid sequence for Azure Site Recovery. The Recovery Services vault must be created first because it acts as the central container for replication data, configuration, and recovery points. After the vault exists, you enable replication for the source VMs, specifying the target region and settings such as the replication policy and storage; this is what actually starts copying VM data. Then you run a test failover to validate the recovery plan in an isolated environment without disrupting production, confirming that failover will work. Finally, you monitor replication health to track RPO, sync status, and any errors that could jeopardize recovery.

• ✗

  Run a test failover, then create a Recovery Services vault, then enable replication, then monitor.

  Why it's wrong here

  This order is fundamentally invalid because a test failover requires an existing recovery configuration and active replication; you cannot fail over a VM that has no Recovery Services vault, no replication policy, and no replicated data. Placing the test failover first means there is no target site or recovery point to switch to, so the step would fail immediately. Even after creating the vault, the subsequent enable replication and monitor steps are out of order relative to the test failover, which must come only after replication is healthy.

• ✗

  Create a Recovery Services vault, then run a test failover, then enable replication, then monitor.

  Why it's wrong here

  This sequence fails because a test failover is dependent on replication being already configured and running for the source VMs. While creating the Recovery Services vault first is correct, running a test failover immediately afterward is impossible without a replication policy and a copy of the data in the target region; there is nothing to fail over yet. The test failover must be delayed until replication has been enabled and initial synchronization has completed, so that the test actually validates the replicated environment rather than an empty configuration.

• ✗

  Enable replication, then create a Recovery Services vault, then monitor, then run a test failover.

  Why it's wrong here

  This order violates the dependency between the Recovery Services vault and replication: you cannot enable replication until the vault exists because the vault provides the replication metadata and storage for recovery points. Additionally, placing monitoring before the test failover is incorrect because monitoring is meant to track ongoing replication health and validate the setup after you have confirmed via a test failover that recovery actually works. The correct flow is to create the vault, enable replication, run a test failover to verify, and only then continuously monitor the health of the replicated environment.

Go deeper

Related to this question