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.
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.