AZ-900 · Describe Cloud Concepts · Updated August 7, 2026
High Availability, Reliability, and SLAs in Azure
High availability means an application stays accessible and operational for a defined, high percentage of time, minimizing downtime. Reliability is the broader ability of a system to recover from failures and keep functioning as expected, of which high availability is one outcome. A Service Level Agreement (SLA) is Microsoft’s formal, published commitment to a specific uptime percentage for a given service, along with the service credits owed if that commitment isn’t met. Together these three concepts describe how confident you can be that an Azure-hosted workload will keep running. See the full AZ-900 study guide for how this topic fits into all three exam domains.
Reliability, high availability, and fault tolerance are related but distinct
Reliability is the umbrella concept: a system’s capacity to recover from failures and continue functioning as expected. It covers everything from a single component failing over automatically to an entire application surviving a regional disaster.
High availability is a specific, measurable expression of reliability — keeping a service accessible for an agreed-upon percentage of time, commonly expressed as an SLA. A financial application distributed across multiple Azure regions so it survives an outage in any one region is a reliability design choice whose measurable result is high availability.
Fault tolerance is the mechanism underneath both: the ability of a system to keep operating correctly even when one or more of its components fail, typically achieved through redundancy — extra disks, extra network paths, extra running instances. Fault tolerance doesn’t mean a component never fails; it means the system absorbs that failure without going down.
Redundancy is what makes fault tolerance possible: duplicating critical components or data — running multiple VM instances, replicating storage — so that losing one copy doesn’t take the application with it. Azure VM Scale Sets and Availability Sets are the specific mechanisms that implement that redundancy for virtual machines.
Building high availability with Availability Zones and regions
Azure gives you two layers of geographic redundancy, and picking the right one is a constant exam theme.
Availability Zones are physically separate datacenters within a single Azure region, each with independent power, cooling, and networking. Distributing VMs across multiple Availability Zones protects an application against a single datacenter failure without the cost or complexity of deploying to a second region — and failover between zones is typically fast, often automatic, with near-zero data loss. See Azure Availability Zones explained for the zone-count details and typical exam wording around them.
Region pairs protect against something Availability Zones can’t: the loss of an entire region. Azure pairs each region with a designated partner region, and Microsoft prioritizes restoring at least one region of a pair first during a broad outage. Replicating an application and its data to the paired region using a service like Azure Site Recovery is the standard way to survive a regional disaster.
The two aren’t substitutes — they solve different failure scopes, and picking the wrong one is exactly what the exam likes to test:
| Single datacenter, no redundancy | Availability Zones (single region) | Multi-region (paired region) | |
|---|---|---|---|
| Survives datacenter failure | No | Yes | Yes |
| Survives full region outage | No | No | Yes |
| Relative cost | Lowest | Moderate | Highest |
| Typical use case | Non-critical, cost-sensitive workloads | Most production workloads needing datacenter-level resilience | Mission-critical workloads that must survive a regional disaster |
A regulated organization that must keep data within one country but still needs resilience typically lands in the middle column: Availability Zones inside the single approved region satisfy both the residency requirement and a strong availability target, without the added cost of a cross-region design it may not be permitted to use anyway.
Beyond redundant infrastructure, load balancers play a direct role in availability: distributing incoming traffic across multiple healthy instances so no single instance is overwhelmed or becomes a single point of failure. Autoscale and virtual machine scale sets work alongside load balancing here — scaling out for capacity and load balancing for resilience are two sides of the same horizontal-scaling design.
Understanding SLAs and how they combine
An Azure SLA is a contractual, financially backed commitment describing a guaranteed uptime percentage — 99.9%, 99.95%, and so on — for a given service, along with the service credits Microsoft owes the customer if actual uptime falls short. It is not a promise of zero downtime; a 99.9% SLA still permits roughly 43 minutes of downtime a month by design. It’s also not a security liability transfer, a monitoring tool, or a pricing discount — those are separate Azure capabilities entirely.
SLAs get more interesting, and more testable, when services depend on each other. If an application’s front end has a 99.9% SLA and it depends on a backend database also covered by a 99.9% SLA, and the application only works when both are up, the composite availability is lower than either individual SLA — because the combined probability is the product of the two: 0.999 × 0.999 is slightly less than 0.999. Chaining dependent services together doesn’t add redundancy; it adds points where the whole system can fail, so composite availability degrades every time you add another required dependency to the chain.
To stay ahead of incidents that could affect an SLA, Azure Service Health provides personalized alerts about service incidents and planned maintenance affecting the specific resources a team actually uses, distinct from Azure Monitor’s metrics and alerting.
How the AZ-900 exam tests this
- Matching the failure scope to the design. A scenario describing protection against “a single datacenter failure” wants Availability Zones; a scenario describing surviving “an entire region becoming unavailable” wants a paired region and cross-region replication. Using the wrong one — Availability Zones alone for a full regional disaster, or an unnecessary multi-region design for a datacenter-only requirement — is a common wrong answer.
- SLA math and composite systems. When a stem describes two dependent services that both need to be up, expect a question testing whether you know composite availability is lower than either component’s SLA, not equal to it and not higher.
- What an SLA actually guarantees. The exam likes wrong answers claiming an SLA guarantees zero downtime, covers customer application bugs, or discounts every invoice automatically. An SLA guarantees a measurable uptime target with defined service credits as the remedy — nothing more.
- Reliability vs. cost tradeoffs. A scenario about a non-mission-critical application choosing a slightly lower but still strong SLA tier to save cost is testing whether you understand that reliability and cost predictability can be balanced deliberately, not that higher SLA is always the correct choice.
- Distinguishing reliability from unrelated benefits. A design goal like “keep running through a hardware failure” is reliability, not elasticity, consumption-based pricing, or governance — those show up as plausible-sounding distractors precisely because they’re real cloud benefits, just not the one being tested.
To lock this in before exam day, work through AZ-900 practice questions built around these exact Availability Zone, region-pair, and SLA scenarios.
Quick reference
- Reliability = the umbrella: recovering from failure and continuing to function.
- High availability = a measurable, high-percentage-of-time expression of reliability.
- Fault tolerance = continuing to operate despite component failure, achieved through redundancy.
- Availability Zones protect against a single datacenter failure within one region.
- Region pairs (with services like Azure Site Recovery) protect against a full regional outage.
- An SLA guarantees an uptime percentage and defines service credits owed if Microsoft misses it — it never guarantees zero downtime.
- Composite availability for dependent services is the product of their individual SLAs, so it’s always lower than any single component’s SLA.
- Load balancers distribute traffic across healthy instances so no single instance becomes a point of failure.