AZ-305
Deep Dive
RTO and RPO are the language the business uses to express how much downtime and how much data loss it can tolerate. The AZ-305 will give you numbers ("RTO 1 hour, RPO 5 minutes") and expect you to translate them into the cheapest technology that meets them.
Contents
RTO — Recovery Time Objective
HOW LONG can the service be down?
RPO — Recovery Point Objective
HOW MUCH DATA (in time) can be lost?
MTTR / MTBF
MTTR (Mean Time To Recover): the real average recovery time — should be ≤ RTO. MTBF (Mean Time Between Failures): expected failure frequency — feeds into redundancy design.
Conceptual trap
Asynchronous geo replication (GRS, geo-replication, ASR) never gives RPO 0 — there are always seconds/minutes in flight. If RPO 0 is asked for between distant regions, it doesn't exist: you have to renegotiate the requirement or accept synchronous writes with the latency that implies (zones do allow it).
⏱️Espectro RTO / RPO — estrategias de DR
Selecciona un tier para ver tecnologías y tip de examen
| Objectives | Strategy | Azure technologies |
|---|---|---|
| RTO days / RPO 24h | Backup + restore | Azure Backup GRS, SQL geo-restore |
| RTO hours / RPO 1h | Geo backup + IaC redeploy (cold standby) | Backup + CRR, Bicep/Terraform, geo-restore |
| RTO ~1h / RPO minutes | Warm standby with replication | ASR for VMs, read replicas |
| RTO minutes / RPO seconds | Hot standby + native replication | SQL failover groups, multi-region Cosmos, App Service x2 + Front Door |
| RTO ≈0 / RPO ≈0 | Active-active | Front Door + active regions + Cosmos multi-write; real RPO 0 only with synchrony (zones) |
Lowering RTO/RPO gets exponentially more expensive: going from hours to minutes multiplies the cost (replicas running); from minutes to near-zero multiplies it again (everything duplicated and active). The correct architect picks the cheapest option that MEETS the target — over-designing is an incorrect answer on the exam.
Classify workloads by criticality
Hidden costs to consider
| The question says... | Conclude... |
|---|---|
| "Up to 24h of data can be lost" | RPO 24h → daily backups are enough |
| "At most 15 minutes of data lost" | RPO 15 min → continuous replication or log backups every 15 min |
| "The service must be back in 1 hour" | RTO 1h → warm standby; a mass restore barely fits |
| "No data loss" + same region | RPO 0 → synchronous replication across zones |
| "No data loss" + between distant regions | Conflict: geo replication is asynchronous — the requirement needs to be revisited |
| "At the lowest possible cost" + generous RTO/RPO | The cheapest option that meets it (backup + IaC), not the most robust |
| "Test the plan without affecting production" | Isolated test failover / DR drill |
Did you get this topic?
Test what you just learned
For an internal reporting app, the business defines: RTO of 8 hours and RPO of 24 hours, at the lowest possible cost. The app runs on 2 VMs with a SQL database on a VM. What DR strategy do you design?
Put what you learned to the test with original AZ-305 exam questions.
Start AZ-305 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.