Business continuity architecture begins with a question that technical teams sometimes avoid: how much interruption and data loss can the business actually tolerate? The Microsoft AZ-305 exam expects architects to recommend high availability, backup, and disaster-recovery solutions for compute, databases, and unstructured data. Those recommendations only make sense when recovery objectives are defined first.
The most important distinction is between keeping a service available during ordinary failures and recovering the service after a larger disruption. High availability, backup, replication, and disaster recovery overlap, but they are not substitutes for one another.
RTO and RPO turn continuity into measurable requirements
Recovery time objective describes how quickly service must be restored after disruption. Recovery point objective describes how much recent data loss is acceptable. The RTO and RPO distinction should be one of the first things you recognize in any AZ-305 continuity scenario.
A workload with a five-minute RTO and near-zero RPO requires a very different architecture from a reporting system that can be unavailable for a day and rebuilt from yesterday’s data. If recovery objectives are not explicit, teams tend to overbuild expensive resilience or underbuild systems that cannot meet business expectations.
High availability protects against expected component failure
High availability keeps a workload operating when individual components fail. Availability Zones, redundant instances, load balancing, clustered database capabilities, and zone-redundant platform services can all contribute. The design goal is to remove single points of failure within the failure domains relevant to the workload.
However, high availability usually assumes that enough of the surrounding platform remains healthy. It does not automatically protect against a regional disaster, widespread configuration error, compromised credentials, or bad application deployment. Architects should identify the specific failure boundary each availability mechanism covers.
Disaster recovery addresses larger failure domains
Disaster recovery prepares the workload to continue or recover when a major environment is unavailable. Cross-region replication, Azure Site Recovery, replicated data services, secondary infrastructure, DNS or routing failover, and recovery automation may all participate depending on the solution.
The secondary environment does not need to be identical to the primary if the business does not require it. Active-active designs can offer fast recovery but add cost and complexity. Active-passive or pilot-light approaches can be cheaper but take longer to restore. AZ-305 questions frequently test whether the resilience level matches the stated business objective.
Backup protects against logical failure as well as infrastructure failure
Replication can copy a bad change. If an administrator deletes critical data, malware encrypts files, or an application corrupts records, synchronous replicas may faithfully reproduce the damage. Backup provides independent recovery points that can restore an earlier known-good state.
A backup strategy should address frequency, retention, immutability where required, geographic protection, encryption, administrative access, and restore testing. A backup that has never been restored is only a theory. Operational evidence matters as much as policy.
Compute recovery depends on the workload model
Virtual-machine workloads may use Azure Backup for protection and Azure Site Recovery for replication and orchestration. Containerized workloads may rely more on declarative deployment, replicated registries, resilient control planes, and protected stateful services. Serverless workloads are often redeployed from infrastructure definitions, with continuity focused on dependent data and regional service availability.
The architect should separate stateless compute from state. Stateless application nodes are usually easier to recreate than databases or file repositories. Recovery architecture becomes clearer when each component is classified by how it is rebuilt and where its durable state lives.
Database continuity is engine-specific
Relational and distributed databases provide different replication, backup, and failover capabilities. Some Azure database services include zone redundancy, automatic backups, geo-replication, or failover groups. The architect needs to choose a pattern that meets both data-loss tolerance and recovery-time requirements.
Be careful with the phrase “geo-redundant.” A service can store copies in another region without providing the exact application failover behavior the workload needs. Continuity design must include connection behavior, DNS, client retry, consistency, and the process for returning to normal operations.
Unstructured data needs explicit durability and recovery choices
Azure Storage redundancy options can protect data across disks, zones, or regions, but redundancy does not replace backup or version protection. Blob soft delete, versioning, immutability, lifecycle rules, and independent backup can address different loss scenarios.
Architects should decide what happens if an entire region is unavailable, if an object is deleted, if a privileged account is compromised, and if the application writes corrupt data. Different controls answer different questions.
Dependencies determine whether recovery actually works
A workload can have a perfectly replicated database and still fail during disaster recovery because DNS, certificates, secrets, identity, network routes, external APIs, or messaging dependencies were not included. Business continuity must be designed across the dependency graph, not resource by resource.
Dependency mapping should identify which systems recover together and which can operate in degraded mode. A payment service may require identity, secrets, database access, event processing, and external gateway connectivity before it is truly available. Recovery plans should be sequenced accordingly.
Failover is only half the story
Teams often plan how to fail over and spend less time planning failback. After the primary environment is restored, data may have changed in the secondary region. Returning traffic safely can require data reconciliation, replication direction changes, validation, and another controlled cutover.
An architect should consider both directions of the lifecycle: normal operation, disruption detection, failover decision, secondary operation, primary repair, resynchronization, failback, and post-incident review.
Recovery testing must reflect real operating conditions
A continuity plan that exists only in documentation can fail under pressure. Regular tests reveal missing permissions, outdated scripts, hidden dependencies, expired certificates, insufficient capacity, and unrealistic RTO assumptions. Testing can range from component restore exercises to full regional failover simulations.
Results should feed back into architecture. If every test exceeds the required RTO, the solution is not meeting the business requirement even if all resources eventually recover. Continuity is an operational capability, not a diagram.
Cost and resilience should be negotiated with the business
More resilience usually costs more. Additional regions, replicas, reserved capacity, network paths, backup retention, and operational testing all have real expense. The architect should present the tradeoff clearly: what failure does the extra cost protect against, how much recovery time does it save, and what data-loss reduction does it buy?
The cloud architecture certification path reinforces this principle across vendors. Architecture is not about maximizing redundancy. It is about meeting business objectives with justified complexity and cost.
Security is part of continuity
Recovery systems are attractive targets because they may contain broad permissions and complete copies of important data. Backup administrators, recovery vaults, secondary environments, and automation credentials need strong access control. Immutability and protected operations can reduce the risk that an attacker destroys both production and recovery paths.
Continuity planning should also assume that the incident could be a security incident. Recovering into the same compromised credentials or configuration can immediately recreate the problem.
How AZ-305 scenarios usually point to the right pattern
If the requirement is to survive a single datacenter failure within a region, think zonal or zone-redundant high availability. If the requirement is regional disaster recovery, think secondary-region architecture. If the requirement is protection from accidental deletion or corruption, think backup, versioning, or immutable recovery points. If the workload has tight RTO and RPO, expect more active capacity and automation.
The AZ-104 administration layer helps with implementation, but AZ-305 asks which recovery architecture should exist and why. The distinction is important: configuration knowledge tells you how to turn on a feature; architecture knowledge tells you whether that feature satisfies the stated failure model.
A continuity design checklist
- Define RTO and RPO with business owners.
- Identify component, zone, region, logical, and security failure scenarios.
- Choose high availability for expected local failures.
- Choose disaster recovery for larger failure domains.
- Add independent backup for logical loss and ransomware scenarios.
- Map dependencies, DNS, identities, certificates, and external services.
- Plan failover, secondary operations, and failback.
- Test recovery and use measured results to improve the design.
Continuity tiers prevent every workload from becoming mission critical
Large environments benefit from classifying workloads into continuity tiers. A revenue-critical system may justify multi-zone deployment, rapid regional recovery, and frequent testing, while a low-impact internal application can accept slower restoration from backup. Tiers turn business impact into repeatable architecture standards.
The model also improves budgeting. Instead of debating resilience from scratch for every application, teams choose or justify a tier based on outage impact, data-loss tolerance, legal obligations, and dependency importance. Exceptions still exist, but the default level of protection becomes predictable.
The durable lesson
Business continuity is a set of measurable promises. Availability, backup, and disaster recovery are tools for keeping those promises under different failure conditions. The architect’s job is to understand the business tolerance, map it to technical failure domains, and design a recovery process that can actually be operated.
Within the Microsoft Azure infrastructure certification path, AZ-305 is where those operational capabilities become design tradeoffs. The right answer is the one that meets the required recovery objectives with defensible cost, complexity, and security.