Microsoft AZ-104: Backup and Recovery

Backup and recovery sit inside the “Monitor and maintain Azure resources” portion of the current AZ-104 blueprint. Microsoft expects administrators to create Recovery Services and Backup vaults, configure backup policies, perform backup and restore operations, configure Azure Site Recovery, fail over to a secondary region, and interpret backup reports and alerts. The AZ-104 exam therefore tests more than whether you know that Azure has a backup service; it tests which recovery mechanism matches the business requirement and how to operate it.

The central distinction is between restoring protected data and maintaining workload continuity. Backup gives you recoverable copies and restore points. Site Recovery orchestrates replication and failover for supported workloads. High availability can keep a service running through some component failures, but it does not automatically protect against deletion, corruption, or a regional disaster. Mixing these ideas is one of the easiest ways to choose the wrong answer.

Start with the recovery requirement

Before selecting a service, identify what must be recovered and how quickly. A deleted file, a corrupted virtual machine, and a regional outage are different incidents. The business may care about how much data can be lost, how long service can remain unavailable, and whether recovery must occur in the same region or another one.

This is where recovery point objective and recovery time objective become useful planning language. RPO concerns acceptable data loss measured in time. RTO concerns acceptable outage duration. AZ-104 does not require a full business-continuity architecture exercise, but understanding these concepts helps explain why a daily backup may be inadequate for one workload while entirely reasonable for another.

Do not assume the most elaborate recovery technology is automatically correct. The exam often prefers the simplest Azure feature that satisfies the stated recovery target.

Understand vault roles instead of memorizing names

The current blueprint names both Recovery Services vaults and Azure Backup vaults. Candidates should recognize that Azure Backup protects different workload types through supported vault experiences and policies. Rather than memorizing a long historical product matrix, focus on the resource in the scenario and the supported backup configuration for that resource.

A vault is a management and protection boundary. Backup policy determines schedule and retention behavior for protected items. The administrator then needs to know how to enable protection, confirm jobs are succeeding, and perform a restore when required.

Operationally, vault configuration should be treated as critical infrastructure. Permissions, network access, deletion protection, and monitoring all matter because an attacker or administrator error that compromises the recovery system can magnify the impact of an incident.

Build backup policies around restore needs

A backup policy is useful only if its recovery points match the business requirement. Frequency affects how much recent data could be lost. Retention affects how far back the organization can recover. Longer retention consumes more storage and may be required by policy or regulation. Administrators should be able to explain why a policy exists rather than copy a generic schedule across every workload.

Testing is part of backup quality. A job marked successful proves that the backup operation completed; it does not prove that the organization can restore the application within its required time. Recovery exercises expose missing dependencies, permissions, documentation, and network requirements before an actual incident.

When the exam asks for the control that protects against accidental deletion or corruption, a recoverable backup is usually more relevant than adding another availability instance. Redundancy and recoverability solve different failure modes.

Restore is a workflow, not a checkbox

Restoring a workload can mean recovering a full resource, selected files, disks, or application data depending on the protected service. Administrators should identify the target recovery point, restore destination, access requirements, and any post-restore validation. A successful restore that reconnects to the wrong network or uses stale credentials can still leave the service unusable.

For exam questions, look for clues about the scope of loss. If only a file is missing, restoring an entire system may be excessive. If a virtual machine is corrupted beyond repair, a broader restore can make sense. If the entire region is unavailable, local restore alone does not solve the continuity requirement.

This is also why change documentation matters. Recovery is much easier when teams know the application dependencies and the configuration state that existed before the failure.

Use Site Recovery for continuity and failover scenarios

Azure Site Recovery is associated with replication, recovery plans, and failover rather than ordinary point-in-time backup. The current AZ-104 objective explicitly requires administrators to configure Site Recovery for Azure resources and perform a failover to a secondary region. That makes the scenario easy to identify when the requirement is workload continuity during a larger outage.

The general distinction between availability, fault tolerance, and disaster recovery is worth understanding. A comparison such as high availability versus disaster recovery illustrates why keeping a service running through a local host failure is not the same as orchestrating recovery after a site-level event.

Failover should also be tested. A recovery plan that has never been exercised may contain incorrect boot order, missing dependencies, or networking assumptions. Real resilience comes from validated recovery, not from the existence of a replication object.

Monitor the protection system itself

The blueprint includes backup reports and alerts because silent protection failure is dangerous. A workload can appear healthy for weeks while its backup jobs fail, leaving the organization without a usable recovery point when an incident finally occurs. Administrators should monitor job success, vault health, policy compliance, and relevant alerts.

Escalation matters. A failed backup alert needs an owner and a response path, just like a performance or security alert. Repeated failures should trigger investigation into permissions, connectivity, capacity, configuration, or service limits rather than being acknowledged indefinitely.

Good reporting also supports governance. It helps answer whether critical resources are protected, whether retention matches policy, and whether restore testing is occurring on schedule.

Keep backup, replication, and architecture decisions separate

Architecture design for AZ-305 may ask broader questions about regional strategy, availability patterns, and business continuity. AZ-104 focuses on operating the Azure protection mechanisms selected for the environment. That means configuring vaults and policies, performing restores, working with Site Recovery, and responding to protection alerts.

Do not choose Site Recovery just because the word “recovery” appears, and do not choose backup just because a resource is important. Map the failure to the required outcome. Restore deleted data from a recovery point. Replicate and fail over when continuity in another location is required. Use high-availability features when the requirement is to withstand local component failure without a recovery event.

This separation makes exam questions far easier because each technology has a distinct purpose.

Practice with failure stories

Write short scenarios and force yourself to name the failure first. A user deletes important data. A VM becomes corrupted. A backup job has failed for three nights. A region becomes unavailable. An application must be recovered with minimal data loss. Each story points to a different combination of policy, monitoring, restore, or failover.

Then add constraints. The organization needs a secondary-region recovery plan. The restore must preserve a private network design. Backup failures must notify the operations team. A policy requires long retention. These details help you practice selecting the smallest set of controls that meets the stated requirement.

Backup and recovery questions are ultimately about matching a protection mechanism to a failure mode. Once you stop treating every outage as the same problem, the AZ-104 objectives in this area become straightforward and operationally useful.

Protect the recovery system from the same incident

Backups are valuable only if the incident that damages production cannot easily destroy the recovery copies as well. Administrators should think about permissions, separation of duties, deletion protection, secure credentials, network restrictions, and monitoring around vault operations. A ransomware event is much harder to recover from if the compromised identity can also remove the usable backups.

This is another reason least privilege matters. The people and automation that manage production workloads do not always need unrestricted authority over recovery infrastructure. Separating operational roles can reduce the chance that one credential compromise becomes both a production outage and a recovery failure. Audit trails and alerts around protection changes help detect suspicious or accidental activity early.

Recovery security should also include restoration testing with clean credentials and known-good procedures. If the only documented recovery process depends on systems or accounts that are unavailable during the disaster, the backup may exist but still be operationally useless. Treat recovery access as part of the design, not a detail to discover during an emergency.

Document dependencies before a recovery event

A restored virtual machine is not a recovered business service if DNS, identities, secrets, storage, network routes, or dependent APIs are still unavailable. Recovery planning should record these dependencies and their restoration order so the team can rebuild a usable application rather than a collection of isolated resources.

This is why recovery plans benefit from application owners as well as infrastructure administrators. The infrastructure team can restore compute and data, while the application owner can validate configuration, credentials, and functional behavior. AZ-104 focuses on Azure operations, but the best operational decisions recognize that technical restore and business recovery are related without being identical.