Azure Site Recovery is easiest to misunderstand when “replication” and “recovery” are treated as the same thing. Replication gets workload state to a recovery location. Recovery requires the target compute, networking, identity, DNS, dependency order, and validation steps to work when the primary environment is unavailable.
For AZ-104, the durable mental model is a state machine: protect the workload, maintain replication, choose a recovery point, start the workload in the target, validate it, commit the recovery, and later reprotect for the next direction. A failover is not just a button; each transition changes what the system expects next.
Consider a three-tier application with web servers, an API tier, and a database. Replication is healthy, but the recovery region has no matching DNS records, the web tier starts before the database is ready, and a firewall rule still points to the primary subnet. The replication dashboard can be green while the application recovery is unusable.
Replication health is necessary, but dependency readiness determines service recovery
Site Recovery continuously protects supported workloads by replicating changes to the recovery target. That process creates recoverable state, but it does not automatically understand every application dependency. If a database must start before an API, or an identity service must be reachable before users can sign in, those dependencies need to be represented in the recovery plan and surrounding runbook.
The architecture should therefore begin with the application graph. List which components are replicated, which are rebuilt from automation, which managed services already have their own regional capabilities, and which external dependencies must be re-pointed. Failover planning is the act of turning that graph into an executable sequence.
Recovery points trade data freshness against application consistency
A real failover requires a recovery-point choice. The latest processed point minimizes data loss but may represent crash-consistent state. An application-consistent point can provide a cleaner transactional boundary for supported workloads but may be older. The correct choice depends on what the application can tolerate and what state it can reconcile after startup.
This is where recovery-point objective becomes concrete. A stated RPO of five minutes is not merely a policy number; it implies that the replication process, application consistency behavior, and recovery-point selection all support losing no more than that amount of accepted data. If the only usable application-consistent point is thirty minutes old, the design and the objective are misaligned.
Recovery plans turn infrastructure failover into application sequencing
Recovery plans group protected machines and define the order in which groups start. They can include manual actions and automation tasks so the runbook can coordinate steps such as updating DNS, validating a database, or pausing until a dependency is available. This is how Site Recovery moves from VM replication toward application recovery.
The sequence should be short enough to understand under pressure. Excessive automation can hide critical assumptions; excessive manual work can make recovery slow and inconsistent. A useful plan automates deterministic steps and makes human checkpoints explicit where judgment or external coordination is required.
This operational sequencing is closely related to disaster-recovery architecture. The recovery plan should not be written only by the Azure team. Application owners need to identify startup dependencies, network owners need to validate routing and security, and service owners need to define what proves the application is actually ready.
Test failover is where the plan becomes evidence
Azure Site Recovery provides test failover specifically so teams can validate recovery without committing a production failover. The safest pattern uses an isolated test network so recovered systems do not collide with production addresses, identities, or services. Replication continues while the test is running.
A test should validate more than whether VMs boot. Check that the right recovery point was used, applications start in order, DNS and routing behave as expected, identity dependencies are reachable, data is internally consistent, monitoring works, and the cleanup process removes temporary resources. Record the time spent at each step.
Testing is what connects Site Recovery to business continuity. A recovery objective is credible only when the organization has measured the path that achieves it. If the test takes three hours but the business expects a one-hour RTO, the result is a design finding, not a documentation problem.
Planned, unplanned, and test failovers answer different operational questions
A test failover asks “can we recover?” without disrupting production. A planned failover is used when the primary environment is still available and the team can coordinate a controlled transition. An unplanned failover addresses outage conditions where the primary side may be unavailable. The preparation for each scenario overlaps, but the available synchronization and coordination options differ.
Operators should avoid treating a successful test failover as proof that every real outage will be identical. A regional failure can remove services that were available during the drill, and a cyber incident can make the latest replicated state unsafe. The recovery plan needs decision points for the actual failure mode.
Failback is part of the lifecycle, not an afterthought
After service runs in the recovery location, the organization still has to decide how to return or establish a new steady state. Reprotection changes the replication direction so the recovered side can become the source for future synchronization. Capacity, network path, and maintenance windows can all influence the failback plan.
A runbook that stops at “application is online in secondary region” is incomplete. It should also describe who owns the recovered environment, how backups and monitoring continue, when the primary region is considered trustworthy again, and how the next recovery capability is restored before the incident is declared closed.
Good Site Recovery design makes dependencies visible before the outage
The most important design artifact is not the replication policy. It is the explicit dependency map: protected resources, target network, address plan, DNS changes, security rules, startup groups, recovery-point choice, validation probes, manual approvals, and failback sequence. Any dependency discovered for the first time during failover is operational debt.
For architects designing recovery and administrators working within the Azure Administrator Associate path, the same principle applies: Site Recovery is a mechanism for executing a recovery design. The design succeeds only when a tested sequence turns replicated state into a usable application within the recovery objectives the organization has committed to meet.
Failover planning has to include the services that replication does not move for you
Application recovery often depends on components outside the replicated virtual machines. DNS records may need to change, traffic managers or load balancers may need a different backend, secrets and certificates must be available, firewall policy must permit the recovered path, and identity services must remain reachable. A failover plan that starts and ends with replicated compute can therefore produce healthy VMs that no user can reach.
The safest way to expose these dependencies is to build and test a service recovery sequence. Identify what must be available before the first application VM starts, what can recover in parallel, which dependencies have data-consistency requirements, and what health check proves each stage is ready. Recovery plans and automation can help encode parts of the sequence, but human decision points should remain explicit where business state or data integrity must be evaluated.
The exercise also clarifies when Azure Site Recovery is the wrong primary tool. Some cloud-native services have their own replication or regional recovery patterns, and some stateless components are better redeployed from code than replicated as machines. The architecture should combine the recovery mechanism appropriate to each dependency into one service-level plan. That broader view connects Site Recovery to disaster-recovery planning without assuming every workload should fail over in the same way.
Capacity at the recovery site is another hidden dependency. Replication can remain healthy even if the target environment would not have enough quota, subnet capacity, service endpoints, licenses, or downstream throughput to run the full workload after failover. A test should therefore validate not only that machines start but that the recovered service can sustain representative demand and can reach every required dependency.
Operational communications belong in the technical plan as well. Someone must declare a failover, freeze conflicting changes, record the chosen recovery point, notify service owners, and decide when the recovered environment is authoritative. Without those decision rights, two technically valid environments can diverge while teams debate which one users should trust. Site Recovery automates infrastructure transitions; incident governance determines when those transitions become business reality.
Data consistency deserves a workload-specific decision. Crash-consistent recovery may be sufficient for some servers, while multi-tier applications may need coordinated application-consistent points or database-native replication to meet integrity expectations. Choosing the freshest recovery point without understanding transaction boundaries can produce a technically recent environment whose components disagree with each other.
That trade-off should be captured before an incident. The runbook can state which recovery-point types are acceptable, what validation the application owner must perform, and when a slightly older consistent point is preferable to a newer uncertain one. The decision is easier during a calm test than during an outage when every minute of recovery time is visible.
Finally, a successful test should generate work. Record manual steps, stale dependencies, slow operations, permission failures, and confusing decision points, then revise the plan and test again. A test failover that ends with “it eventually worked” is not a finished control. The objective is to make the next recovery more predictable and less dependent on the people who happened to be present during the last exercise.
The final design question is how often the assumptions are revalidated. Application dependencies, network paths, quotas, identities, and recovery priorities all change. A recovery plan that passed last year can become wrong without any Site Recovery configuration showing an error. Periodic tests should therefore be triggered not only by a calendar but also by significant architecture change.
