Study Azure AZ-305 High Availability: key concepts, common traps, and exam decision cues.
High availability is about staying online through expected failure modes. AZ-305 usually tests whether you can match the failure boundary to the right architecture level: host, rack, datacenter, zone, or region. If you treat every outage the same way, your answer tends to be either underpowered or unnecessarily expensive.
Use Availability, Durability, and Recoverability to separate system qualities, then Failure Domains and Blast Radius and Active-Active and Active-Passive to reason about placement and topology. This lesson keeps the Azure implementation and AZ-305 decision layer.
| Failure concern | Strongest first design instinct |
|---|---|
| local host or rack issue | built-in service redundancy or availability set style pattern |
| datacenter-level issue inside a region | availability zones or zonally aware services |
| full regional outage | cross-region continuity pattern |
| database or state-platform outage | service-native HA and replication features |
The exam wants you to ask: what exactly am I trying to stay available through?
| Azure compute situation | Strongest first fit | Why |
|---|---|---|
| custom VM workload needing protection from localized failures | availability sets or zones, depending on region and requirement | distribute instances across failure boundaries |
| managed platform app with built-in scaling and resilience | App Service or other managed compute HA features | managed platforms often reduce the need for custom VM-level design |
| container workload with stricter orchestration needs | zonal or regional container architecture | uptime depends on both orchestration and cluster placement |
| Data pattern | Strongest first reasoning move |
|---|---|
| managed relational platform | inspect service-native HA and failover options first |
| globally distributed or multi-region read/write need | evaluate service replication and region model, not just backup |
| storage account durability concern | choose the redundancy model that matches the required failure boundary |
Backup and HA are related but different. A backed-up database can still be offline longer than the business allows.
| Trap | Better rule |
|---|---|
| answering every availability question with multi-region active-active | use the smallest failure boundary that satisfies the requirement |
| ignoring whether the service is already managed and redundant | managed platforms often solve parts of HA for you |
| treating zonal design and regional DR as interchangeable | zones reduce intra-region failure risk; regions address larger disasters |
| using backup to satisfy uptime requirements | backup protects history, not always continuous service |