Backup policies, recovery points and regional failover answer different Azure resilience questions. This AZ-104 guide explains Recovery Services vaults, supported Backup vault workloads, Azure VM restore and Site Recovery drills through RPO/RTO decisions and evidence-based recovery acceptance.
A replicated VM is not the same as a recoverable workload
Azure administrators protect data against several different failure modes. An availability zone can keep a redundant application available when one zone fails. Backup can retain recoverable points in time after accidental deletion, corruption or ransomware. Disaster recovery replication can prepare a workload to run in a secondary location. These mechanisms overlap in some benefits, but they cannot substitute for one another without regard to recovery point, restoration process and data consistency.
The AZ-104 study guide includes Recovery Services vaults and Backup vaults, backup policies, Azure Backup and restore operations, Azure Site Recovery, regional failover, reporting and alerts. The distinction between Azure high availability and disaster recovery matters because an available replica is not necessarily a usable historical restore point. Here the focus is the administrator’s concrete tasks: choosing a supported vault for each workload, configuring protection scope, verifying recovery points and exercising a recovery plan.
Translate requirements into RPO and RTO
Recovery point objective (RPO) is the amount of data loss a business can tolerate, expressed as a period of time. Recovery time objective (RTO) is the time available to restore service after a failure. They are planning requirements, not automatic properties of choosing a replication button. A daily backup schedule cannot reasonably promise recovery of the last five minutes of writes. A quick regional failover may still leave a data consistency or identity problem.
For a fictitious invoice database, the business may tolerate losing no more than a defined interval of approved transactions and require operations to resume within a chosen deadline. Identify which components are needed to satisfy that promise: application VMs, source data, encryption keys, DNS, access roles, virtual networks, monitoring and business verification. Restoring one VM successfully does not necessarily restore the invoice service.
Document which datasets require application-consistent recovery, which may use crash-consistent points and which need independent database-native backup. A successful infrastructure restore can leave an in-flight business transaction in an uncertain state. Applications must handle reconciliation.
Choose the right vault for the workload
Azure Backup uses different vault resource types and workload capabilities. Recovery Services vaults protect supported services such as Azure VMs and relevant traditional backup scenarios, while Backup vaults are intended for other supported newer data sources and data protection capabilities. The names are not synonyms and don’t justify claiming a Backup vault can protect every resource accepted by a Recovery Services vault.
Before creating a vault, identify the workload, supported region, expected retention, cross-region restore requirements, encryption, identities and compliance obligations. The platform’s current capability matrix determines which vault, policy and permissions are necessary. Placing the vault in an arbitrary subscription can complicate delegated recovery and auditing; design the ownership scope intentionally.
Protect the backup infrastructure itself. Restrict who can change retention or disable protection, review security settings such as soft delete and multi-user authorization where supported, and keep the backup administrators distinct from people who merely need to view reports. A broad subscription Contributor role should not be given solely so someone can inspect backup status.
Backup policy controls the recovery window
A backup policy determines supported schedule, retention and protection behavior for the covered workload. Administrators must connect its frequency to the agreed RPO and its retention to actual organizational requirements. The newest successful backup may already be too old for a critical workload; report its age rather than assuming a green "protected" label means the target is met.
Retention design should also consider legal deletion obligations, storage costs, long-term recovery points and the need to resist accidental or hostile deletions. Azure Backup can offer security features to reduce the chance that a single compromised operator destroys all recovery copies; their availability differs by vault/workload. These features are important but do not remove the need for offline operational reviews.
For a fictional VM, enable a suitable backup policy in a test subscription, run a protected backup, identify the available recovery points and check alerts. No such real Azure action has been executed in this written example.
Restore operations require a recovery target
The word "restore" can hide several different operations. Restoring an entire Azure VM, recovering disks, recovering files and restoring an application database may follow different supported paths. The administrator should identify exactly which component is damaged and which recovery point contains the correct data. A complete VM restore can take longer or disturb more infrastructure than recovering a single missing configuration file.
Choose a safe restore destination. A test VM with a known name and isolated network is usually preferable to overwriting a healthy production resource during verification. Record dependencies on identity, keys, disk encryption and service configuration. If production data is sensitive, the restored test environment still needs the same privacy restrictions as the original.
After recovery, check actual application behavior, not just disk attachment or backup-job status. A restored service might have stale credentials, a broken DNS dependency or data that is consistent internally but lacks the last acknowledged customer change. Recoverable infrastructure is not automatically an accepted business result.
Azure Site Recovery is a distinct continuity mechanism
Azure Site Recovery coordinates replication and failover for supported workloads. It can help prepare Azure VMs for a regional outage by maintaining a recovery arrangement and facilitating failover to a secondary region under supported conditions. This is not the same as a scheduled independent backup history; replication may carry unwanted changes as well as legitimate ones.
A recovery plan should specify the target virtual network, VM configuration, storage, protection policies, startup ordering and external services. A replicated VM starting in another region does not prove the application has a reachable database, a correct DNS entry or authorization to use required secrets. The operator must verify the entire service dependency chain.
Azure Site Recovery resiliency depends on supported replication, failover and recovery configurations; the service’s reliability guidance describes important limitations. Check actual VM, storage and regional support for the proposed deployment. During an incident, administrators must confirm failover direction, replication state and the primary region’s condition; a slow portal response does not justify repeating a potentially consequential failover operation without a status check.
Test failover before depending on an emergency plan
A failover test is a controlled exercise of the recovery process. It should use an appropriately isolated network and avoid disrupting the protected production service. Define the expected startup sequence and acceptance checks, such as DNS reachability, database health and the ability to perform a harmless authorized transaction.
For the fictional invoice service, a test failover launches replica components in a separated environment. The administrator checks that the app can read the intended recovery data, that logging and access rules were recreated, and that the time to a useful state meets the stated RTO. If the test fails, record the missing dependency and repair the recovery plan before an actual outage.
Also test what happens when the replica is behind the latest expected recovery point. The correct business decision may be to reconcile missing transactions or delay reopening writes. A failover that boots quickly but silently loses acknowledged data can violate the true recovery objective.
Monitor backup and replication health
Set alerts for protection failures, stalled replication, aging recovery points and other supported health signals. Define who receives those alerts and what action is required. Do not assume an informational dashboard guarantees protection unless the recovery points and actual workload coverage have been checked.
The administrator should verify that every intended VM or data source is protected, the selected policy is assigned, jobs are succeeding and recoverability remains within the chosen window. Monitor vault security changes and deletion attempts where supported. A backup job failing because of access rights should be fixed by identifying the required permission, not by giving all operators unrestricted vault administration.
A good restore drill records backup identifier, restoration target, application validation, elapsed time and any data loss observed. Without real execution, report these as fields to collect, not claimed performance statistics.
Three independent failures to evaluate
Imagine three synthetic incidents. In the first, a user accidentally deletes a report from a VM. Choose the smallest supported backup restore that retrieves the correct approved version. In the second, an application update corrupts data but the primary Azure region is healthy. Select an appropriate recovery point and understand that regional replication alone may propagate the corruption. In the third, the primary region is unavailable and the business must activate a secondary environment. That scenario calls for a coordinated disaster recovery process and tested dependencies.
Add a fourth case where a backup policy was configured but no recent successful recovery point exists. The correct answer is to mark recovery readiness as a failed acceptance condition, not to invent a successful restore. Include an authorization failure where the operator can see backup status but lacks permission to restore; distinguish role assignment from backup data integrity.
For each case state the target RPO/RTO, which mechanism is appropriate, which system records the true outcome, and what evidence is needed before reopening the business application. The examples illustrate administrative reasoning, not actual tested services or exam questions.
What AZ-104 requires in practice
Reliable recovery must meet an explicit objective, not merely show that a vault exists. In a synthetic exercise, compare (1) an accidentally deleted file on a backed-up Azure VM, (2) corruption of a protected VM’s application volume and (3) a primary-region outage that requires a tested recovery environment. For each, choose and justify file recovery, disk or full-VM restoration, or a Site Recovery failover as supported by the workload and available points. Check permission to restore, recovered data consistency, application identity and dependencies before accepting the result. A third-party AZ-104 backup and disaster-recovery scenario is useful when its answer demonstrates which component was actually recovered and which failure the selected mechanism cannot solve. These are hypothetical checks, not a claim of an executed Azure restore or failover.
Work from the business outcome backward: which data must be correct, how much loss is tolerable, what time to recovery is required, and which service dependencies must survive. That is the difference between enabling a backup feature and demonstrating an operational recovery plan.