Design business continuity solutions

RTO, RPO and What Recovery Actually Costs

Every business continuity design starts by turning two business numbers into technical choices. The recovery time objective is how long the workload may be unavailable, and it decides how much of the recovery environment has to already exist when the incident starts. The recovery point objective is how much data may be lost, and it decides how the data gets to the second location and how often. Those two numbers are independent, and reading them separately is what makes a scenario answerable. A tight RTO with a relaxed RPO means you should be spending on standby capacity rather than on tighter replication, because the workload has to come back fast but can afford to lose a little recent data. A relaxed RTO with a tight RPO means the opposite: replicate continuously, but you do not need warm compute waiting. The strategies form a ladder from backup and restore, which is cheapest and slowest because the environment is rebuilt during the incident, through a pilot light where only the core is running, a warm standby that is scaled down but live, up to a fully active-active deployment where both regions serve traffic and there is nothing to fail over to. Cost rises at every step, so the design goal is to meet the stated objectives and stop there.

Exam tip. Read the two objectives separately and let each pick its own control. A scenario with a short RTO and a long RPO is telling you to pay for warm compute, not for more frequent replication, and the reverse is equally true.

Designing an Azure Backup Solution

Azure Backup is the answer whenever the requirement is to recover something that was lost, deleted or corrupted, as opposed to moving a running workload somewhere else. It works on a policy model: a vault holds the recovery points, a policy defines how often backups run and how long each retention band is kept, and the workload types it protects natively go well beyond virtual machines to include Azure Files shares, blobs, managed disks, Azure Database for PostgreSQL, and SQL Server and SAP HANA running inside VMs. Two design decisions carry most of the marks. The first is vault redundancy, because a locally redundant vault disappears with the region it lives in, so a requirement to restore after a regional outage means geo-redundant vault storage with cross-region restore enabled, which allows a restore directly into the paired region. The second is protecting the backups from the people who administer them, which is where soft delete keeps deleted backup data recoverable, immutable vaults stop retention being shortened, and multi-user authorisation requires a second approver before a destructive change takes effect. That combination is what a ransomware requirement is really asking for, because replication-based approaches faithfully copy the damage.

Exam tip. Ransomware, accidental deletion and corruption all point at Azure Backup with soft delete and immutability. Site Recovery is never the right answer to those, because it replicates the damage as faithfully as it replicates everything else.

Azure Site Recovery and Regional Failover for VMs

Azure Site Recovery solves a different problem from backup: it keeps a continuously replicated copy of running machines somewhere else so an entire workload can be brought up there. It covers Azure to Azure replication between regions, and replication from VMware, Hyper-V and physical servers on-premises into Azure, which makes it both a disaster recovery tool and a migration one. The feature that turns replication into a recovery capability is the recovery plan, which groups machines into ordered tiers so the database comes up before the application server, and which can run scripts or Automation runbooks between those groups to do things like updating DNS or reconfiguring connection strings. Just as important is the test failover, which brings the replicated machines up in an isolated network without touching production or interrupting ongoing replication, and it is how you turn a claimed RTO into a measured one. What Site Recovery does not do is protect you from bad data, since a corruption or an encryption event replicates within moments, and it does not solve the parts of a workload it cannot replicate. Networking, load balancers, public addresses and PaaS services in the second region still have to be designed, and multi-tier applications need their dependencies mapped before the plan means anything.

Exam tip. Distinguish the two failure modes in the question. Something is broken and we need it back the way it was means Azure Backup, while the region is gone and the workload has to run elsewhere means Azure Site Recovery.

High Availability Within a Region: Sets, Zones and Scale Sets

Before any conversation about second regions, a design has to survive ordinary failures in the region it already occupies, and Azure offers three levels of protection with clearly different reach. A single VM has no redundancy at all, so any maintenance or hardware fault takes the workload down. An availability set spreads VMs across fault domains, which are groups sharing power and network, and update domains, which are the batches the platform reboots separately, so it covers hardware failure and planned maintenance inside one datacentre. Availability zones go further by placing instances in physically separate datacentres within the region, each with independent power, cooling and networking, which is the only in-region option that survives losing a whole facility. Two vocabulary distinctions matter. A zonal resource is pinned to one zone and you are responsible for placing copies in others, whereas a zone-redundant resource is spread across zones by the platform, and knowing which a service offers tells you whose job the redundancy is. For virtual machines the current recommendation is usually a scale set with flexible orchestration, which spreads instances across zones or fault domains automatically while still letting you treat them as ordinary VMs, so you get placement and scaling without giving up control of the instances themselves.

Exam tip. Match the answer to the named failure. A scenario about host maintenance or a rack fault is satisfied by an availability set, while any mention of a datacentre going down needs availability zones, and a region going down needs a second region.

Business Continuity for Azure Databases

Databases have their own continuity mechanisms and the exam expects you to reach for them rather than bolting on a generic solution. Azure SQL Database and Managed Instance take automatic backups, so point-in-time restore covers any moment inside a recent window and is the answer to a bad change or an accidental deletion, while long-term retention keeps weekly, monthly and yearly copies for compliance. Surviving a zone outage is a configuration choice: enable zone redundancy on a tier that supports it and the replicas are placed in different zones. Surviving a regional outage is a different mechanism entirely, and here active geo-replication creates readable secondaries in other regions while an auto-failover group wraps that with a listener endpoint that follows the primary and can fail over automatically, which is what allows an application to keep the same connection string through a failover. That last detail is usually the deciding factor in a question. Cosmos DB approaches the same problem from the other direction, since it is globally distributed by design: adding read regions gives local reads and a failover target, and adding multi-region writes keeps writes available during a regional failure at the cost of conflict resolution and a lower consistency ceiling.

Exam tip. The phrase that decides between active geo-replication and a failover group is usually about the application. If connection strings must not change or failover must be automatic, the answer is the auto-failover group.

Designing a Multi-Region Application

Making an application survive the loss of a region is less about any single service and more about assembling four decisions consistently. The first is the entry point, because something has to notice a region is unhealthy and send users elsewhere: Azure Front Door does this at the edge with health probes and moves traffic within seconds, while Traffic Manager works at the DNS layer and is therefore bounded by how long clients cache a record, which makes it the right answer only for non-HTTP traffic or endpoints outside Azure. The second is the compute tier, which is far easier when it is stateless, because then recovery is just running instances somewhere else, and this is why pushing session state into a cache or store is a continuity decision rather than a performance one. The third is data, which is always the hard part, since a database can usually only have one place accepting writes unless it was designed otherwise, so the choice is between a replicated primary with an automatic failover mechanism and a genuinely multi-write store such as Cosmos DB. The fourth is everything that is not the application: DNS, certificates, secrets, identity and networking all have to exist in the second region before the incident, because anything created during a failover becomes part of the RTO.

Exam tip. When the scenario is HTTP or HTTPS and mentions fast, automatic failover between regions, the answer is Azure Front Door. Traffic Manager only becomes correct when the traffic is not web traffic or the endpoints live outside Azure.

1. Which approach should the architect recommend so that newly created virtual machines are protected without anyone remembering to do it?

• A. Ask each team to add a backup tag to their virtual machines and review the tag report monthly.
• B. Schedule an automation runbook that enumerates virtual machines nightly and enrolls any it finds unprotected.
• C. Require all virtual machine deployments to go through a single Bicep module that includes the backup configuration.
• D. Assign an Azure Policy definition that configures backup on virtual machines to a management group, and use Backup center for estate wide reporting.correct

The failure being described is a governance gap, not a technology gap, so the fix belongs in the governance layer. Assigning a policy that configures backup on virtual machines at a management group makes protection a property of the platform rather than of anyone's diligence, it applies to subscriptions created later, and Backup center gives the single estate wide view of protected and unprotected items the governance team asked for. A shared Bicep module is the genuinely tempting alternative because it does produce protected machines and is good practice, and it only helps for machines created through that module, so anything deployed by hand or by another pipeline slips through exactly as before. A nightly runbook is code the company now owns, with its own credentials and failure modes, doing a job Azure Policy does natively. Tagging and monthly review detects the problem after the fact and still depends on a human noticing. When a stem says automatically and across the estate, think policy at a management group.

2. Which solution should the architect recommend to meet the file recovery requirement at the lowest cost?

• A. Protect the virtual machines with Azure Backup in a Recovery Services vault, using a policy that takes daily backups and retains them for 30 days.correct
• B. Replicate the virtual machines to a second Azure region with Azure Site Recovery and perform a failover whenever a user reports a lost file.
• C. Change the storage accounts behind the virtual machine disks to read access geo redundant storage so a second copy of every disk exists.
• D. Write a scheduled automation runbook that takes managed disk snapshots each night and copies them to a separate storage account.

The requirement is recovering individual files after human error within a couple of weeks, and that is precisely the job Azure Backup exists to do. A Recovery Services vault with a daily policy gives point in time recovery points, supports file level recovery from a virtual machine recovery point without restoring the whole machine, and costs only for the retained backup data. Site Recovery is the tempting wrong answer because it genuinely does hold a second copy of the machine, but it is built for keeping a workload running through an outage, its recovery points are short lived, and failing a production system over to recover one spreadsheet is operationally absurd. Geo redundant storage protects against infrastructure loss, not against a user deleting a file, because the deletion replicates faithfully to the second copy. A custom snapshot runbook does technically produce restorable copies, and that is exactly the trap: the team now owns scheduling, retention pruning, and restore tooling that a managed service already provides. Match the protection mechanism to the failure you are actually defending against.