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