D6 · Recovery

Business Continuity

Business continuity (BC) is the broader framework that encompasses . It ensures critical operations can continue during and after an incident. AZ-104 evaluates how Azure supports a BCDR strategy and the architectures that guarantee resilience.

Business Continuity Management (BCM)

Business Continuity is the process of ensuring critical business functions can continue during and after a disaster. It is broader than DR: DR covers IT recovery, BC also covers business processes, staff, customers and communication.

BC vs DR

  • •DR: recover IT systems after the disaster
  • •BC: keep business operations running during the disaster
  • •BC includes: alternative manual processes, communication, staff, vendors
  • •A good BC plan can allow operations to continue even while IT systems are down

Types of incidents

  • •Natural disaster: earthquake, flood, datacenter fire
  • •Technology failure: hardware, software, network, cloud provider
  • •Security incident: ransomware, DDoS, data breach
  • •Human error: accidental deletion, misconfiguration
  • •Pandemic/human event: key staff unavailable

BCM lifecycle

  • •Analysis: BIA — identify critical processes and their impact
  • •Design: define RTO/RPO, strategies and architecture
  • •Implementation: deploy technical solutions (ASR, Backup, multi-region)
  • •Testing: test failovers, drills, tabletop exercises
  • •Improvement: lessons learned, plan updates

Business Impact Analysis (BIA)

The Business Impact Analysis (BIA) identifies critical business processes, quantifies the impact of their disruption, and establishes recovery priorities. It's the starting point for defining RTO and RPO.

What the BIA identifies

Critical Business Functions (CBF)

Processes that cause catastrophic impact if they fail. E.g.: payment processing, manufacturing control systems, urgent medical support.

Maximum Tolerable Downtime (MTD)

The maximum time a process can be down before irreversible damage to the business. RTO must be less than the MTD.

Work Recovery Time (WRT)

Time needed to catch up on work accumulated during the downtime (e.g.: processing pending orders). RTO + WRT ≤ MTD.

Dependencies

Which systems, vendors, people or data each critical process needs. A downed DB can halt multiple processes.

System classification

BIA output: classify each system by criticality to prioritize DR investment.

Tier 1 — Critical — RTO < 1h, RPO < 15 min

Payment system, core banking, medical control system. Maximum BC investment.

Tier 2 — Important — RTO < 8h, RPO < 1h

ERP, CRM, email. Significant but not catastrophic impact if down for a few hours.

Tier 3 — Normal — RTO < 24h, RPO < 4h

Intranet, reporting, internal tools. Operational but tolerable impact.

Tier 4 — Low — RTO days, RPO daily

File systems, historical reporting. Only basic backup needed.

BCDR in Azure — key services

Azure serviceRole in BCDRRTORPOScope
Azure BackupBackup and restore for VMs, DBs, filesHoursHours-daysArchive + restore
Azure Site RecoveryVM replication for cross-region DRMinutes30 sec - 5 minVM DR
SQL Failover GroupsAutomatic failover for Azure SQL< 30 sec< 5 secSQL DR
Storage GRS/GZRSAsync replication of blobs to the paired regionHours (Microsoft-initiated)~15 min lagStorage DR
Automatic DNS failover between endpoints1-3 minN/A (routing)Endpoint DR
Azure Front DoorGlobal traffic failover at the edge< 30 secN/A (routing)Global app DR
Availability ZonesHA within a region against zone failure< 1 sec0Intra-region HA
Distribute VMs across fault/update domains0 (other VMs keep running)0VM HA

Resilient architectures in Azure

Single region with Availability Zones

SLA 99.99%

VMs across multiple zones, zone-redundant Load Balancer, zone-redundant SQL. Protects against datacenter failure. Does NOT protect against a full region failure.

Key components

  • •VMSS distributed across zones
  • •Zone-redundant Standard LB
  • •Azure SQL with zone redundancy
  • •Storage with ZRS

Multi-region active-passive (warm standby)

RTO 15-60 min, RPO ~0

Active primary region + secondary region with reduced capacity. ASR for VMs, SQL Geo-Replication. Traffic Manager for failover.

Key components

  • •Azure Site Recovery (VMs)
  • •SQL Active Geo-Replication
  • •Traffic Manager Priority
  • •Storage GRS
  • •Key Vault in both regions

Multi-region active-active

RTO ~0, RPO ~0

Both regions receive traffic simultaneously. Front Door or Traffic Manager distributes it. DB in bilateral sync. Failover is transparent.

Key components

  • •Azure Front Door (performance routing)
  • •SQL Failover Groups (both regions read/write with routing)
  • •VMSS in both regions
  • •Cosmos DB (multi-region write)
  • •Azure CDN

Backup + Restore (low cost)

RTO hours, RPO hours

Azure Backup only. No active replica. For non-critical systems with limited budget.

Key components

  • •Azure Backup with GRS vault
  • •Cross-Region Restore enabled
  • •IaC scripts to re-provision infrastructure
  • •Documented restore procedure

Compliance and contractual SLAs

Regulations that impose BC/DR requirements

PCI-DSS

Documented DR plan, encrypted backups, annual plan testing

HIPAA (healthcare)

Contingency plan, backup, DR and documented emergency procedures

ISO 22301

BC standard — full BCM process, BIA, plans and audits

GDPR

Ability to restore personal data within an appropriate time after an incident

SOC 2

Availability controls, including DR and regular testing

Contractual SLA vs Azure SLA

Microsoft's SLA for Azure services is a financial commitment — if not met, they offer service credits. They don't guarantee your application has 99.99% uptime — that depends on how you've designed it.

Azure SLA = resource availability

Azure VM in an AZ: 99.99% → if the VM is unavailable for more than 52 min/year, Microsoft issues a credit.

Your application's SLA = composite SLA

Your app uses VM (99.99%) + SQL (99.99%) + LB (99.99%). Composite SLA = 99.99% × 99.99% × 99.99% ≈ 99.97%.

D6 review — final comparison table

Service / ConceptWhat it's forKey difference
Backups and restorationMultiple historical recovery points. RPO = backup frequency.
DR — continuous VM replicationNot backup — no multiple historical points. RPO = 30 sec.
Recovery Services VaultContainer for Backup and ASRSupports Backup + ASR. The most complete and most common on the exam.
Backup VaultContainer for modern PaaS backupBackup only (no ASR). For Blobs, Disks, PostgreSQL, AKS.
RTOMaximum tolerable downtimeMeasures SYSTEM downtime. RTO < MTD.
RPOMaximum tolerable data loss (in time)Measures DATA loss. RPO determines backup/replication frequency.
FailoverActivating the secondary system when the primary failsCan be automatic (TM, SQL Failover Groups) or manual (ASR).
FailbackReturning to the primary system once it recoversIn ASR: requires Re-protect first. Never do a rushed failback.
Test Failover (ASR)Test DR without impacting productionTest VMs in an isolated VNet. Production is not interrupted.
Soft DeleteRetain backup data after deletion14 additional days of retention. Protects against accidental/malicious deletion.
Intra-region HA (a DC zone fails)Does NOT protect against a full region failure.
Cross-region DR, geographically separatedFor regional disasters. GRS, ASR and CRR use the paired region.

Did you get this topic?

Test what you just learned

A financial services company needs to ensure its payments application can recover from a regional disaster with RTO < 30 minutes and RPO < 5 minutes, complying with PCI-DSS. Which combination of services is most appropriate?

Ready to test "Business Continuity"?

Put what you learned to the test with original AZ-104 exam questions.

Start AZ-104 mock exam

Unlimited mock exams with the Pro plan

Log in to track your progress.