Microsoft AZ-305: Designing for Continuity and Recovery

Business continuity and disaster recovery in Microsoft AZ-305 are about engineering predictable failure behavior. The exam does not reward a blanket answer such as “use multiple regions.” It expects the architect to connect recovery objectives, workload dependencies, data consistency, failover orchestration, and cost.

Microsoft’s current blueprint assigns 15–20% of AZ-305 to business-continuity design. That includes backup and recovery for compute, databases, and unstructured data as well as high-availability decisions. The strongest approach begins with what the business can lose and how long it can remain unavailable.

Translate business language into RTO and RPO

Recovery time objective defines how quickly service must return; recovery point objective defines how much recent data loss is acceptable. Recovery plans need RTO and RPO expressed as measurable targets: a failover design that exceeds either limit is not adequate just because another region remains online.

A near-zero RTO usually requires capacity that is already running or can become active automatically. A near-zero RPO usually requires synchronous or very frequent replication. Both increase cost and operational complexity, so the architect should not promise aggressive objectives unless the business value justifies them.

Separate high availability from disaster recovery

High availability keeps a service running through expected infrastructure failures. Disaster recovery restores or relocates service after a larger event. The difference between high availability and fault tolerance matters because a zone-resilient service can still require a regional recovery plan.

Designs should identify the fault domain they tolerate: process, VM, rack, zone, region, identity dependency, or external provider. Once the failure boundary is explicit, the architect can choose redundancy and recovery mechanisms that actually address it.

Use availability zones for local resilience where they fit

Zone-redundant services can survive the loss of an availability zone without invoking a full regional failover. For virtual machines, this may mean distributing instances and load-balancing across zones. For managed services, the platform may provide zone redundancy directly.

Zone design still requires dependency analysis. An application tier spread across zones gains little if its database, firewall path, key vault, or name resolution remains a single-zone dependency. Architecture reviews should trace each request through every critical component.

Select a regional recovery pattern intentionally

Common regional strategies range from backup-and-restore through warm standby to active-active designs. Backup-and-restore is inexpensive but slow. A warm environment reduces recovery time while retaining some scaling delay. Active-active can deliver excellent continuity but demands sophisticated data and traffic management.

Traffic redirection is only part of the problem. The recovery region needs configuration, secrets, identities, observability, deployment artifacts, and sufficient capacity. Infrastructure as code reduces drift and makes recovery environments reproducible rather than dependent on manual reconstruction.

Design backup around workload behavior

Compute backups, database-native backups, snapshots, and object versioning all have different semantics. Databases often need transaction-consistent recovery and point-in-time restore. File or object workloads may benefit from versioning, soft delete, or immutable retention in addition to scheduled copies.

Backups should be isolated enough to survive the incident they are intended to recover from. If an attacker or administrator with the same credentials can delete production data and every backup, the recovery architecture has a shared failure path.

Plan failover and failback as separate operations

Failover moves service away from the failed environment. Failback returns it after the original environment is healthy. The second step is frequently harder because data may have changed in the recovery region and must be synchronized safely.

Architecture documentation should define authority during a disaster: which region is primary, who initiates failover, whether traffic switching is automated, and how split-brain conditions are prevented. Clear ownership reduces improvisation during a high-pressure outage.

Include security services in continuity design

Identity, secrets, certificates, DNS, firewalls, and logging are part of the workload even when they are operated by separate teams. A regional application recovery can fail if credentials are unavailable, network policies are missing, or the monitoring plane cannot show whether the restored service is healthy.

Emergency access also matters. Recovery procedures should be executable when normal administrative paths are degraded, but break-glass controls must remain tightly governed and auditable.

Test recovery with measurable evidence

Architecture quality is demonstrated through recovery exercises, not diagrams. The distinction between replication, availability, and recovery is clearer when comparing high availability, fault tolerance, and disaster recovery: a live redundant component cannot automatically restore a corrupted dataset. A test should measure actual restore time, data loss, dependency failures, and operator steps.

Regular exercises often reveal hidden assumptions: DNS TTLs are too long, certificates are not present in the secondary region, quotas block scaling, or application owners do not know which data source becomes authoritative. Those findings should feed back into the architecture.

Use scenario trade-offs instead of slogans

On AZ-305, eliminate answers that exceed the requirement at disproportionate cost or fail the stated recovery target. A 24-hour RTO does not require active-active infrastructure. A payment platform with seconds of RPO cannot rely on a nightly backup.

Read each scenario for the business objective, failure scope, data requirement, and operational constraint. Then choose the smallest architecture that meets the target with a credible test and failback plan. That is the reasoning pattern Microsoft expects from a solutions architect.

Application dependency ordering matters during both outage and recovery. A front end may recover quickly but remain unusable until identity, databases, message brokers, DNS, and key services are available. Recovery plans should therefore model dependency groups and sequence them rather than treating every resource as an independent restore task. This is one reason orchestration can be as important as replication technology.

Data corruption is a different failure from infrastructure loss. Replicating corrupted or malicious changes into a secondary region can preserve availability while destroying recoverability. Point-in-time recovery, immutable copies, delayed replicas, or protected backup vaults may be needed to address logical failure. A mature continuity design covers accidental deletion and ransomware as well as datacenter outages.

Regional capacity also deserves validation. A secondary region may not have identical quota, SKU availability, or reserved capacity. If the recovery plan assumes rapid scale-out, architects should verify quota and deployment readiness before an emergency. Capacity planning is especially important for specialized VM families and large databases that cannot simply appear on demand in every region.

Communications are part of recovery architecture even though they are not Azure resources. Operations teams need a way to declare an incident, authorize failover, coordinate application owners, and tell users which functions are degraded. A technically successful failover can still be chaotic if nobody knows who has decision authority or how to confirm business service restoration.

Recovery testing should include partial failures rather than only total-region loss. A broken identity dependency, misrouted DNS zone, unavailable private endpoint, or failed database replica can be more realistic than a clean regional outage. These exercises expose monitoring gaps and unclear ownership that a full disaster drill might accidentally hide behind broad failover procedures.

Cost models should distinguish always-on resilience from recovery capacity that is created or scaled during an incident. Active-active architectures pay continuously for readiness, while warm or pilot-light patterns accept a longer RTO in exchange for lower steady-state cost. The exam frequently tests whether the chosen level of redundancy is proportional to the stated objective.

Failback should be rehearsed with the same discipline as failover. Once users and data are active in the recovery environment, returning to the original region can require reverse replication, maintenance windows, and another traffic transition. If teams only test the first half of the process, the organization may remain in an expensive or temporary recovery posture far longer than planned.

Continuity architecture should also define what ‘service restored’ means. Infrastructure can be online while the business process remains broken because queues are backlogged, external integrations are disconnected, or data reconciliation is incomplete. Recovery validation should therefore include application-level transactions and business checks, not only infrastructure health.

Third-party dependencies need explicit treatment in the recovery plan. Payment gateways, SaaS APIs, identity providers, and external DNS may have their own regional behavior and recovery commitments. The organization cannot guarantee an end-to-end RTO that is tighter than a critical dependency unless it has an alternate provider or a degraded operating mode.

Runbooks should state which actions are safe to automate and which require human approval. Automatic failover is useful when health signals are trustworthy and the consequence of a false positive is low. For stateful systems, a premature failover can create data divergence, so a controlled decision may be safer even if it adds minutes to recovery.

Recovery architecture should also account for data reconciliation after degraded operation. Some systems allow limited writes during a regional incident or queue transactions until a dependency returns. Once normal service resumes, teams need a deterministic way to merge, replay, or reject conflicting changes. That requirement can influence whether the application should continue in a reduced mode or stop writes entirely during a failover.

Monitoring thresholds used for automatic recovery actions should be conservative and tested. A transient network problem can make a healthy region look unavailable, and an automatic global failover can create more disruption than the original fault. Combining multiple signals and requiring sustained failure can reduce false positives.