Microsoft AZ-305: High Availability, Disaster Recovery and Business Continuity — Study Guide

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Part of the Microsoft Azure Solutions Architect Expert AZ-305 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

High availability (HA), disaster recovery (DR), and business continuity (BC) in Azure require deliberate design across compute, data, and networking layers. Resiliency starts with clear recovery time objective (RTO) and recovery point objective (RPO) targets, then composes platform capabilities—Availability Zones, global routing, data replication, backup, and failover orchestration—into a tested, automated strategy. Azure provides zone and region fault isolation, DNS and anycast-based global distribution, multi-region data durability, and policy-driven backup/restore to meet stringent objectives while controlling cost and operational complexity.

RTO/RPO-Driven Architecture and Zonal/Global Resiliency

Design begins with RTO and RPO. RTO dictates how quickly service must resume after a fault; RPO dictates the maximum acceptable data loss. Meeting low RTO requires automated failover and pre-provisioned capacity; meeting low RPO requires synchronous or near-synchronous replication and frequent consistent recovery points.

Availability Zones are independent datacenter fault domains within a region. Zonal services (for example, Virtual Machines, managed disks, Standard public IPs) are pinned to a single zone. Zone-redundant services (for example, Azure Load Balancer Standard zone-redundant frontends, zone-redundant storage offerings, and zone-redundant Azure SQL tiers) span zones automatically. A typical resilient pattern deploys zonal VMs in at least two zones, places them in a single virtual network, and exposes a zone-redundant load balancing frontend. This eliminates single-zone failure as a cause of downtime.

At the global edge, choose between DNS-based and anycast-proxy load distribution:

Azure Traffic Manager is DNS-based. It directs clients to endpoints using routing methods: Performance (lowest latency), Weighted (A/B testing and gradual traffic shifts), Priority (active/passive failover), Geographic (serve users from regionally compliant endpoints), MultiValue (returns multiple healthy IPv4/IPv6 records for simple clients), and Subnet (map client IP ranges to specific endpoints). Because it is DNS-based, Traffic Manager does not accelerate content or proxy traffic; clients connect directly to the chosen endpoint and obey local DNS caching behavior.
Azure Front Door (Standard/Premium) is a global anycast HTTP/HTTPS reverse proxy with intelligent routing, TLS offload, and integrated web application firewall (WAF). Routing rules match on domain, path, method, and headers, then route to origin groups; rule engine actions can rewrite URLs/headers and enforce redirects. Health probes continuously evaluate origin health on a configurable path and protocol; unhealthy origins are removed from rotation. Origin groups support priority (active/passive) and weighted distribution across regions. WAF policies attach at the endpoint or route, with managed rulesets, custom rules, and rate limiting to mitigate OWASP threats and abusive clients. Use Front Door when you need global load balancing with acceleration, edge security, and application-aware failover; combine it with Traffic Manager only when you need non-HTTP endpoints or DNS-level control.

At layer 4, Azure Load Balancer provides ultra-low latency load distribution for TCP/UDP. Standard Load Balancer supports zonal and zone-redundant frontends, HA ports, outbound rules, and secure-by-default behavior (explicit NSG and backend pool configuration). Health probes (TCP/HTTP) determine backend health; failure removes instances from rotation. Basic Load Balancer lacks zone awareness, advanced features, and an SLA—avoid it for production. Cross-region Load Balancer adds a global anycast frontend that balances across regional Standard load balancers, enabling active/active multi-region designs for non-HTTP workloads and providing fast regional failover based on health.

Data Protection and Disaster Recovery: Azure Backup and Site Recovery

Azure Backup provides point-in-time recovery; Azure Site Recovery (ASR) provides workload replication and orchestrated failover. They address complementary needs and are often combined.

Azure Backup vault options:

Recovery Services vault protects Azure VMs, SQL Server in Azure VMs, SAP HANA in Azure VMs, Azure Files, and MARS/MABS agents. It integrates with Backup policies defining schedules, retention, and application-consistent backups where supported.
Backup vault is the modernized vault for newer workloads such as Azure Disks backup and Azure Blobs backup, offering granular RBAC and zone-redundant vault storage in supported regions. Choose the vault type aligned with the workload and governance model.

Backup policies govern when backups run, their retention tiers (daily/weekly/monthly/yearly), and consistency settings. Soft delete adds a safety window during which deleted backup items can be undeleted, protecting against accidental or malicious deletion. Cross-region restore enables restores from the secondary region when vault storage uses geo-redundant options; it must be enabled and is subject to regional feature support and data-plane readiness.

Azure Site Recovery replicates workloads across zones or regions and orchestrates end-to-end DR:

Replication policies define snapshot frequency, retention of recovery points, app-consistent snapshot cadence, and RPO alert thresholds. Policies balance replication bandwidth, storage costs, and recovery precision.
Recovery plans provide ordered failover of multi-tier applications with groups (e.g., database, API, web), pre/post steps, and automation via Azure Automation runbooks, scripts, or manual actions. Integrate DNS changes, Traffic Manager/Front Door endpoint updates, and application configuration in the plan.
Test failover runs an isolated recovery using a non-production VNet or a test network to validate runbooks, boot order, and application health without impacting production or replication. Regular testing is essential to validate RTO.
Failback returns workloads to the original site or region when healthy. After failover, re-protect the workload in the new primary direction, synchronize changes, schedule a planned failback window, and verify post-failback replication. For Azure-to-Azure scenarios, you typically fail over between paired regions and reverse replication to restore the original topology when ready.

Data Layer Continuity: Azure SQL, Storage Replication, and Cosmos DB

Each data service exposes distinct durability and failover semantics that must align with application consistency requirements.

Azure SQL Database and Azure SQL Managed Instance:

Active geo-replication creates up to four readable secondaries for single databases or elastic pools. It offers database-level replication with manual or API-driven failover, enabling read-scale and DR. It is appropriate when you need per-database control and custom orchestration.
Auto-failover groups create a group of databases (or an entire managed instance) that fail over together with a listener endpoint. It simplifies cross-region failover and connection string management and supports automatic failover after a grace period. Use failover groups for multi-database applications requiring coordinated failover and simplified client connectivity.
Zone redundancy places replicas across zones in a region to survive zonal failures with no cross-region recovery. Enable it for tiers that support it to improve local availability without altering latency profiles.

Azure Storage replication options:

GRS (geo-redundant storage) replicates data asynchronously from the primary region (three copies) to a paired secondary region (three copies). During normal operation, reads and writes target the primary.
RA-GRS adds read access to the secondary endpoint for scenarios like emergency reporting or analytics when the primary is degraded.
GZRS (geo-zone-redundant storage) combines ZRS in the primary region for zonal durability with asynchronous replication to the secondary region, improving both local and regional resiliency.
RA-GZRS adds read access to the secondary for GZRS accounts. If the primary region is unrecoverable, you can initiate an account failover to the secondary. After failover, the storage account becomes primary in the secondary region and typically reverts to locally redundant (until you reconfigure). Expect some RPO (asynchronous replication); applications should handle idempotency and reconciliation after failover.

Azure Cosmos DB:

Multi-region writes allow writes to any configured region with conflict resolution policies (last writer wins via a designated property, custom, or multi-master strategies). This reduces write latency and increases availability.
Automatic failover uses a prioritized region list to promote a new write region upon outage. Combined with chosen consistency levels (from Strong to Eventual), you manage the availability-consistency trade-off.
SLAs cover availability, throughput, latency, and consistency. With multi-region writes, Cosmos DB offers up to 99.999% availability for both reads and writes, assuming correct multi-region configuration. Design clients using the SDK with endpoint discovery and retries to fully benefit from these guarantees.

Putting It Together: Meeting Specific Recovery Objectives

Map each tier to its continuity mechanism, guided by RTO/RPO and failure domains:

Intra-region availability: Use Availability Zones. Deploy zonal compute across at least two zones; use zone-redundant frontends (Standard Load Balancer, Application Gateway v2 with zone redundancy, or Front Door at the edge). Enable SQL zone redundancy where supported and use GZRS for storage that needs both zonal and regional resilience.
Cross-region DR: For stateful tiers, prefer native geo-replication (SQL auto-failover groups, Cosmos DB multi-region accounts, Storage GRS/GZRS) for low RPO. For stateful IaaS or workloads without native replication, use Azure Site Recovery with well-tuned replication policies and recovery plans. For ephemeral compute, rehydrate from images or VM Scale Sets, using Infrastructure as Code.
Global routing and failover: For HTTP/S, Azure Front Door provides health-probe-driven, application-aware failover and WAF protection. For non-HTTP or mixed protocols, add Traffic Manager (DNS) or Cross-region Load Balancer (L4 anycast) as appropriate. Use priority routing for strict active/passive RTO goals; use weighted for staged rollouts and performance for lowest-latency user experiences.
Backups as last line of defense: Even with replication, maintain Azure Backup with retention policies that meet compliance, enable soft delete to protect against purge events, and configure cross-region restore for vaults using geo-redundant storage. Backups protect against logical corruption, ransomware, and operator error—risks that replication can propagate.

Testing is non-negotiable. Schedule regular ASR test failovers, perform Front Door/Traffic Manager health drill tests, validate SQL failover group behavior under load, and execute storage failover simulations in a sandbox. Instrument RTO measurements and automate rollback/failback with runbooks. Document and rehearse operational runbooks so on-call responders can execute consistently under pressure.

Practical Problem Scenario

Expedia Group must modernize its global trip-booking platform to meet RTO ≤ 15 minutes and RPO ≤ 5 minutes for core booking, while sustaining 10x traffic spikes during major travel events. The platform serves web and mobile clients worldwide with mixed HTTP and non-HTTP workloads.

Build zonal resilience in a primary region

Deploy stateless microservices as zonal VM Scale Sets across two or more Availability Zones with Standard Load Balancer zone-redundant frontends. This removes single-zone failure risk and ensures low-latency intra-region traffic.
Use Azure SQL Database with auto-failover groups and zone redundancy enabled. Auto-failover groups provide coordinated database failover and a stable listener, meeting the 15-minute RTO with minimal operational burden.
Store session artifacts and images in GZRS storage accounts to combine zonal durability with asynchronous regional protection. This meets the 5-minute RPO when paired with application-side idempotency.

Add cross-region DR with active/active reads

Configure the booking web/API origins in two paired regions behind Azure Front Door Standard. Health probes and priority routing enable rapid failover on application health, while anycast accelerates user traffic. WAF policies with managed rulesets and rate limiting protect against volumetric and application-layer attacks, crucial during traffic spikes.
Enable Cosmos DB multi-region writes for the itinerary and personalization services to reduce write latency for global users and provide 99.999% availability. Automatic failover prioritizes the secondary region, preserving low RTO without manual intervention.
Use SQL auto-failover groups across the same two regions for transactional bookings, enabling read-scale on secondaries for reporting while ensuring rapid, coordinated failover.

Protect state and support recovery from corruption

Use Recovery Services vaults for Azure VM backups (app-consistent where supported) and SQL in-VM if any legacy components remain. Apply backup policies with tiered retention and enable soft delete to guard against accidental or malicious deletions.
For Azure Disks hosting specialized workloads, add Backup vault–based Azure Disk Backup to capture incremental snapshots independent of guest OS agents. This diversifies recovery options.
Enable cross-region restore on vaults using geo-redundant storage, allowing data-plane restores from the secondary region during partial control-plane disruptions.

Orchestrate DR and validate RTO

Configure Azure Site Recovery for any non-native-replicated services (e.g., legacy Windows services). Create recovery plans that sequence database readiness, then API, then web, and include Azure Automation runbooks to update Key Vault references, purge CDN caches via Front Door rules, and flip Traffic Manager priority for non-HTTP endpoints.
Schedule quarterly test failovers into isolated VNets using masked data to verify runbooks, measure actual failover duration, and refine capacity reservations. After tests, clean up artifacts and review metrics against the 15-minute RTO target.

Global routing for mixed protocols

For HTTP/S, Front Door handles health-driven failover and edge security. For non-HTTP protocols (e.g., partner TCP integrations), deploy Cross-region Load Balancer with regional Standard Load Balancers as child endpoints. Health probes remove failed regions instantly, maintaining connectivity without DNS TTL dependencies. Where DNS-level geofencing is necessary (regulatory endpoints), layer Azure Traffic Manager Geographic routing ahead of region-specific endpoints.

Why these services

Availability Zones and zone-redundant frontends eliminate single-zone failures with minimal latency impact. Azure SQL failover groups abstract connection management and automate failover, aligning with the 15-minute RTO. Cosmos DB multi-region writes meet ultra-high availability and low-latency write requirements globally. GZRS and RA options provide zonal plus regional durability with controlled RPO trade-offs. Front Door delivers global acceleration, application-aware failover, and WAF at the edge. Cross-region Load Balancer and Traffic Manager cover non-HTTP and geographic routing needs. Azure Backup and ASR provide independent recovery paths—from point-in-time restores to full-stack failover—ensuring the platform can recover from both infrastructure failures and logical data corruption.

← Networking and Connectivity · All domains · Security Architecture and Zero Trust →

Practice these questions → · Timed practice on ExamRoll.io →