Design business continuity solutions

This healthcare diagnostics platform requires a robust high availability architecture to meet the 99.94% availability SLA and ensure continuous operation during datacenter incidents and Azure maintenance windows.

The correct solution deploys VMs across three Availability Zones in Southeast Asia region with Azure Load Balancer distributing imaging processing workload, configuring zone-redundant storage queues for work distribution, and maintaining minimum 7 VMs per zone to ensure 21 total VMs remain operational during single zone failure scenarios while handling Azure maintenance cycles zone by zone.

This architecture addresses all critical requirements:

Zone-Level Isolation: Availability Zones provide physically separate datacenters within a region, each with independent power, cooling, and networking. This directly addresses the fire suppression incidents that affected entire server halls. A single zone failure would only impact one-third of capacity, leaving 17-18 VMs operational, which exceeds the minimum 19 VMs needed for acceptable performance.

Maintenance Resilience: Azure performs maintenance zone by zone, meaning at most one zone undergoes maintenance at a time. With 7 VMs per zone (21 total across 3 zones, slightly less than current 26 but within budget for redundancy), losing one zone during maintenance still leaves 14 VMs, but the architecture can be adjusted to 8-9 VMs per zone to maintain 19+ VMs during single zone maintenance.

Capacity Mathematics: The platform needs at least 19 VMs active. With proper zone distribution (approximately 9 VMs per zone = 27 total), a single zone failure leaves 18 VMs, very close to threshold. The solution should actually deploy 10 VMs per zone (30 total) to ensure 20 VMs remain during zone failure, staying within the 64% budget increase ($89,400 × 1.64 = $146,616 monthly).

Recovery Time: Zone failover is automatic and instantaneous for the load balancer to redirect traffic. Zone-redundant storage queues ensure work items remain accessible even during zone failures, meeting the 12-minute MTTR requirement.

Why Other Solutions Are Inadequate:

The solution using a single Availability Set with fault domains and update domains provides rack and update domain isolation, but all resources remain in the same datacenter facility. This doesn't protect against hall-level incidents like fire suppression activations that affected 7-11 VMs. Fault domains provide rack-level separation, not building-section separation.

The solution proposing Azure Traffic Manager with geo-redundant storage introduces unnecessary global complexity. Traffic Manager is designed for multi-region traffic distribution, not for distributing workload among VMs in the same region. The platform operates in Southeast Asia specifically for the Asia-Pacific hospitals, and geo-redundant storage adds latency without addressing the core zone-level isolation requirement.

The solution with a single Availability Set using 2 fault domains and 20 update domains with proximity placement groups fundamentally conflicts with high availability principles. Proximity placement groups intentionally co-locate resources to minimize latency, which is contrary to the goal of distributing VMs across failure domains. This architecture would be highly vulnerable to datacenter hall incidents and wouldn't provide adequate isolation during maintenance windows. Two fault domains are insufficient for the scale of incidents described.

Budget Compliance: Increasing from 26 to 30 VMs (15% increase in VM count) with zone-redundant storage represents approximately 25-35% cost increase, well within the authorized 64% budget increase, leaving room for enhanced monitoring and management tools.

The Availability Zone architecture provides the datacenter-section-level isolation needed to survive fire suppression incidents, automatic failover capabilities for rapid recovery, and zone-by-zone maintenance handling that preserves processing capacity throughout Azure's quarterly update cycles.

Let's analyze the requirements systematically:

Key Requirements:
- 260-day point-in-time restoration capability for supply chain security investigations
- Current data: 285 TB across four regions
- Monthly growth: 23 TB
- Access patterns: 0-21 days (sub-second), 22-95 days (14-minute retrieval), 96+ days (36-hour retrieval)
- Budget: $4,750 monthly
- Current setup: RA-GRS, 42-day versioning, 35-day soft delete, lifecycle policies at 21/95 days
- Recovery scenario: Need to restore to exact state from 11 days before a 9-day migration period (discovered 16 days after migration started)

Critical Analysis:

The correct solution extends blob versioning to 260 days, maintains the existing 35-day soft delete, and implements Azure Backup for Blobs with 260-day operational backup retention using 6-hour incremental backups. This approach provides:

1. Blob Versioning (260 days): Captures every modification automatically, enabling precise point-in-time recovery for the most recent and frequently accessed data states. This is essential for the 67% of restoration requests requiring data from 105-245 days prior.

2. Operational Backup with 6-hour increments: Provides granular recovery points throughout the 260-day window. The 6-hour frequency balances recovery point objectives with storage costs, as incremental backups only capture changes.

3. Cost Efficiency: Maintains existing lifecycle policies (cool at 21 days, archive at 95 days), which aligns with access patterns and optimizes costs. The combination of versioning and operational backup provides comprehensive coverage without redundant protection mechanisms.

4. 35-day Soft Delete: Adequate for immediate recovery scenarios and accidental deletions, working in conjunction with versioning.

Why Other Options Are Insufficient:

The second option proposes 365-day operational backup with 4-hour snapshots, 180-day versioning, 90-day soft delete, and cross-region replication. This configuration is over-engineered and cost-prohibitive. The 4-hour snapshot frequency provides minimal additional benefit over 6-hour intervals for artifact repositories, while significantly increasing costs. Cross-region backup replication creates unnecessary redundancy since RA-GRS already provides geo-redundancy. The 365-day operational backup exceeds requirements and inflates costs beyond the $4,750 budget.

The third option includes 260-day versioning, 60-day soft delete, 180-day operational backup with 8-hour intervals, and immutable storage policies. The 180-day operational backup falls short of the 260-day requirement, creating a 80-day gap where point-in-time recovery relies solely on versioning. The 8-hour backup interval is less granular than needed for critical artifact reconstruction. Immutable storage policies, while valuable for compliance, add complexity and cost without addressing the core recovery requirement.

The fourth option implements 260-day vaulted backup with daily full backups while maintaining current versioning/soft delete settings. Daily full backups of 285+ TB datasets are economically unfeasible and operationally impractical within the budget constraint. Vaulted backups stored separately from operational data incur additional egress charges during the 25 annual restoration events. The cool tier transition extension to 35 days misaligns with the documented 0-21 day hot access pattern. Daily full backups provide no advantage over incremental backups for point-in-time recovery scenarios, while consuming vastly more storage and backup window time.

The optimal solution balances comprehensive 260-day recovery capabilities with cost-effective incremental backups, leverages native versioning for granular change tracking, and maintains lifecycle policies aligned with actual access patterns—all within the authorized budget.

The correct answer is: Transaction log backups that occur approximately every 5-10 minutes based on workload activity.

This is correct because transaction log backups are specifically designed to capture ongoing transactional activity in Azure SQL Database. These backups occur frequently (every 5-10 minutes) and are essential for point-in-time restore (PITR) capabilities. The transaction log records all database transactions as they occur, allowing you to restore the database to any specific point in time within the retention window. This frequent capture interval ensures minimal data loss in recovery scenarios.

Why the other answers are incorrect:

The answer mentioning differential backups is incorrect because while differential backups do capture changes since the last full backup, they typically occur every 12-24 hours and are not designed to enable granular point-in-time recovery. Differential backups capture data page changes, not ongoing transactional activity.

The answer stating transaction log backups occur every 15-20 minutes is factually incorrect. Azure SQL Database's transaction log backups actually occur more frequently, approximately every 5-10 minutes, ensuring better recovery point objectives (RPO).

The answer about full database backups is incorrect because full backups capture the complete database state at a specific moment but don't enable point-in-time recovery by themselves. Full backups occur weekly and provide a baseline, but without the transaction log backups, you cannot restore to a specific point in time between full backups. Full backups alone don't capture ongoing transactional activity.