Study Azure AZ-305 Backup and DR: key concepts, common traps, and exam decision cues.
Continuity questions in AZ-305 usually become easier once you force the stem to answer two things: how quickly the system must recover and how much data loss is acceptable. Those are RTO and RPO. If you skip them, you can easily choose backup for a failover problem or choose active replication for a slower restore problem.
Review RTO, RPO, and Recovery Objectives, Backup vs Replication, and Recovery Strategy Patterns for the portable design model. This page then maps that model to Azure Backup, Azure Site Recovery, service-native replication, and AZ-305 scenario cues.
RTO: Recovery time objective. The maximum acceptable downtime after an incident.
RPO: Recovery point objective. The maximum acceptable amount of data loss measured in time.
| Need | Strongest first fit | Why |
|---|---|---|
| recover deleted or corrupted data | backup and restore pattern | the primary need is point-in-time recovery |
| recover workloads in another region after a major outage | disaster recovery pattern | the primary need is regional failover or rebuild |
| keep serving traffic during smaller failures | high availability pattern | the primary need is uptime, not restore |
| preserve long retention and compliance copies | backup vault and retention design | retention is different from immediate availability |
The exam often mixes these together on purpose. The correct move is to identify which need dominates the scenario.
RTO and RPO| Scenario clue | What it usually means |
|---|---|
| “can tolerate hours of downtime” | restore-based recovery may be acceptable |
| “must fail over quickly” | look for replication and DR architecture, not just backups |
| “almost no data loss” | the RPO is tight, so asynchronous backups alone may be too weak |
| “must retain data for months or years” | retention design matters even if availability pressure is low |
| Pattern | What it solves | What it does not guarantee |
|---|---|---|
| backup | recover historical data state | immediate service continuity |
| disaster recovery | restore service in another site or region | zero downtime by itself |
| high availability | keep the service available during local failures | long-term retention or historical restore |
Strong answers keep those three lanes separate. A backup copy can support DR, but backup alone is not automatically a DR design.
| Azure signal | Architecture use |
|---|---|
| Azure Backup | protected backup and restore for supported workloads |
| Azure Site Recovery | orchestrated replication and failover for DR scenarios |
| geo-redundant storage or geo-replication options | cross-region durability or recovery support |
| failover groups and service-native replication | application or data failover with tighter recovery goals |
The product name matters less than the architecture role. Microsoft is testing whether you can justify why restore, replication, or failover is the correct answer.
| Trap | Better rule |
|---|---|
| choosing Azure Backup because the word “protect” appears | protection can mean backup, replication, or HA; classify it first |
| answering a strict low-downtime scenario with restore from backup | restore is often too slow for tight RTO targets |
| designing DR without considering data-loss tolerance | cross-region recovery answers still need a realistic RPO story |
| overbuilding active-active designs when the business tolerates slower recovery | continuity should match business tolerance, not maximum possible complexity |
RTO and RPORTO and RPO first.