HA and DR interviews have a habit of exposing people who know the feature names but have never actually had to explain why one architecture choice survives a failure scenario that another one doesn’t. That distinction — knowing what fails over versus why it fails over the way it does — is really what this whole topic is testing.
Split into Beginner (1–17), Intermediate (18–35), and Advanced (36–50), written the way you’d actually talk it through in a room, with the reasoning behind each answer, not just the definition.
One framing worth carrying through the whole list: HA and DR are answering two genuinely different questions. HA asks “how do we survive a failure without anyone noticing much.” DR asks “how do we survive losing an entire region, and how much data and time are we willing to lose to do it.” Good answers throughout this list keep that distinction clear rather than treating them as the same thing with different names.
Beginner Level
1. What’s the difference between High Availability (HA) and Disaster Recovery (DR)? HA is about surviving small, localized failures — a node crashing, a storage issue — with minimal or no downtime, usually within the same datacenter or region. DR is about surviving a much bigger event — an entire region becoming unavailable — and involves failing over to infrastructure in a different geography, generally with a longer recovery time and more planning involved.
2. Does Azure SQL Database include high availability by default, or do you have to configure it? Every Azure SQL Database has built-in high availability by default — you don’t build it yourself the way you might configure an on-prem Always On Availability Group. The exact architecture underneath differs by service tier, but some level of automatic HA is baked in regardless of which tier you choose.
3. What are the two main HA architectures behind Azure SQL Database’s General Purpose and Business Critical tiers? General Purpose separates compute and storage — compute runs on a single node with storage on remote, redundant Azure storage, and if the compute node fails, a new one spins up and reattaches to that same durable storage. Business Critical uses a local, “Always On”-style architecture with multiple synchronized replicas, each with its own local storage, giving faster failover since there’s no need to reattach anything.
4. What is RTO, and why does it matter? Recovery Time Objective — how long you can tolerate being down before the business is meaningfully harmed. It’s the number that drives which HA/DR architecture is actually appropriate; a five-minute RTO requirement and a four-hour RTO requirement lead to very different, very different-cost designs.
5. What is RPO, and how is it different from RTO? Recovery Point Objective — how much data you can tolerate losing, measured in time (e.g., “we can afford to lose the last 5 minutes of transactions”). RTO is about how long recovery takes; RPO is about how much data is gone when it’s done. They’re both needed to describe a complete requirement — one alone doesn’t tell you the full picture.
6. What is a failover group in Azure SQL? A construct that groups one or more databases together with a defined secondary region and a stable, unchanging endpoint — so when a failover happens, the application doesn’t need its connection string changed, because the endpoint automatically redirects to whichever database is currently primary.
7. What is active geo-replication? A feature that creates a readable secondary copy of your database in a different region (or the same region), continuously kept in near-sync with the primary. It’s the underlying mechanism failover groups are built on top of, and it can also be used directly, with manual failover control, without necessarily using the failover group construct.
8. What’s the difference between a “hot” standby and a “cold” standby in DR terms? A hot standby is already running and synchronized, ready to take over almost immediately — like a geo-replica. A cold standby doesn’t exist until you need it — you’d have to provision and restore it from backup when disaster strikes, which is slower but cheaper to maintain in the meantime, since you’re not paying for a running secondary the whole time.
9. Is Azure SQL Database’s built-in HA the same thing as a DR strategy? No, and this is a common beginner mix-up — built-in HA protects against failures within a region (a node or storage failure), but if the entire region goes down, built-in HA alone doesn’t help, because it’s not replicating anywhere outside that region on its own. You need a separate DR mechanism — geo-replication or failover groups — for genuine regional resilience.
10. What is a read-only replica, and how does it relate to HA? In Business Critical (and Premium) tiers, one of the secondary replicas used for HA can also serve read-only query traffic via read scale-out — meaning the same infrastructure protecting you against failure is also doing useful work day-to-day, rather than sitting idle waiting for a failure that may never come.
11. What happens to active connections during a failover? They’re dropped and need to reconnect — failover isn’t instant or invisible at the connection level, though it’s typically fast (seconds for HA-driven failover, longer for a full DR failover). Applications need reasonable retry logic to handle this gracefully rather than surfacing a hard error to the end user.
12. What is zone-redundant configuration, and how is it different from geo-redundancy? Zone redundancy spreads replicas across different availability zones within the same region — physically separate datacenters close together, protecting against a single datacenter-level failure without the latency or cost of a fully separate region. Geo-redundancy replicates to an entirely different region, protecting against a much bigger event (like a regional outage) that zone redundancy alone wouldn’t survive.
13. Can you choose which Azure region a failover group’s secondary lives in? Yes, within the set of regions Azure supports for that pairing — you’re not limited to only the automatically “paired region,” though using the standard paired region is common and often simplest for compliance and latency reasons.
14. What’s the simplest way to think about why Business Critical tier costs more than General Purpose, from an HA perspective? You’re paying for extra, continuously running, fully synchronized replicas with local storage, ready to take over almost instantly — versus General Purpose’s model of reattaching a new compute node to shared durable storage after a failure, which is cheaper because it’s not maintaining multiple fully redundant live copies at all times.
15. What is Auto-failover group’s “automatic failover policy,” and why would you want manual control instead? The automatic failover policy lets the failover group detect an outage and switch primary roles on its own, without a human triggering it — good for minimizing downtime when you trust the detection to be accurate. Manual control means a human decides when to actually fail over, which some organizations prefer specifically to avoid an unnecessary failover being triggered by a brief, self-resolving blip rather than a genuine sustained outage.
16. What’s the risk of not testing a failover before you actually need it in a real emergency? You genuinely don’t know if it works as expected, how long it actually takes, or whether the application handles the reconnect correctly, until you’ve seen it happen — a documented DR plan that’s never been executed is, in practice, an unproven plan, not a validated one.
17. What’s the very first question you should ask before designing any HA/DR solution for a database? What are the actual RTO and RPO requirements — because that single answer drives almost every subsequent architecture decision (which tier, whether you need geo-replication at all, how many regions, automatic vs manual failover), and skipping straight to “let’s use Business Critical with a failover group” without establishing the actual requirement often leads to either over-engineering or under-protecting.
Intermediate Level
18. Explain the architectural difference between General Purpose and Business Critical HA in more technical detail. General Purpose stores data on Azure Premium remote storage, decoupled from the compute layer — if the compute node fails, Azure spins up a new compute instance and reattaches it to the same durable remote storage, which already has its own redundancy built in. Business Critical runs four replicas total (one primary, three secondaries) using a technology architecturally similar to SQL Server Always On Availability Groups, each with its own local, directly-attached storage kept in near-synchronous state — meaning failover doesn’t require reattaching storage at all, just promoting an already-synchronized secondary, which is why it’s typically faster.
19. What’s the typical failover time difference between General Purpose and Business Critical tiers, and why? Business Critical typically fails over in well under a minute — often around 30 seconds or less — because a fully synchronized local replica is simply promoted. General Purpose failover generally takes longer, because it involves provisioning or reattaching compute to the durable remote storage layer, which is a heavier operation than promoting an already-running, already-synchronized replica.
20. How does read scale-out actually route read-only traffic, and what should applications do to use it correctly? Applications specify ApplicationIntent=ReadOnly in the connection string, and the engine routes that connection to a secondary replica instead of the primary — but this only makes sense for genuinely read-only workloads, since writes sent with that intent will simply fail. It’s the application’s responsibility to correctly split its connection strings between read-write (primary) and read-only (secondary) traffic; the platform doesn’t guess based on the actual query content.
21. What’s the difference between failover groups and plain active geo-replication in terms of what an application experiences during a failover? With plain active geo-replication, the application’s connection string typically needs to change post-failover, since it’s pointing directly at the specific secondary server, which becomes the new primary — that’s a code or configuration change during an already-stressful event. Failover groups solve exactly this by providing a stable, unchanging listener endpoint that automatically redirects to whichever database is currently primary, meaning the application’s configuration doesn’t need to change at all during a failover.
22. How would you design a failover group setup for an application that also needs to serve read-heavy reporting traffic? I’d configure the failover group’s secondary to also serve as a read-only replica during normal operation (available on Business Critical/Premium via read scale-out), routing reporting traffic there via ApplicationIntent=ReadOnly so it doesn’t compete with the primary’s OLTP workload — meaning the DR infrastructure is doing genuinely useful work day-to-day instead of sitting idle, and I’d make sure the reporting application handles the temporary loss of that read endpoint gracefully during an actual failover event, since the roles do briefly swap.
23. What’s the difference in how General Purpose and Hyperscale approach high availability? General Purpose’s HA is based on reattaching compute to shared durable remote storage after a failure. Hyperscale takes a fundamentally different, more distributed storage architecture — with page servers each independently responsible for a portion of the data, and the ability to maintain multiple replicas (including HA replicas and separately, read-only named replicas) — designed specifically to also support very large databases where General Purpose’s model would become a bottleneck for both HA failover time and backup/restore time.
24. How would you decide between zone-redundant configuration and a full cross-region failover group for a given application? It comes down to what failure scope the business actually needs to survive — if a single-datacenter failure is the realistic concern and a full regional outage is considered acceptable residual risk (or handled by some other means), zone redundancy alone is simpler and cheaper. If the requirement genuinely includes surviving a full regional outage — a real compliance mandate or a business that can’t accept “the whole region is down” as an acceptable excuse — a cross-region failover group is necessary, and the two aren’t mutually exclusive; you can combine zone redundancy within a region alongside geo-replication across regions.
25. What’s the operational difference between an automatic and a manual failover policy in a failover group, in a real incident? Automatic policy means the platform detects a qualifying outage and initiates failover without waiting for a human decision — minimizing downtime, but trusting the detection logic’s judgment about what counts as a genuine outage worth failing over for. Manual policy means someone has to actively trigger the failover, giving a human the chance to confirm it’s a real, sustained event rather than a brief blip — trading some speed for more deliberate control, which some organizations prefer specifically because an unnecessary failover has its own cost and risk (a fresh, less-tested primary suddenly taking live traffic).
26. How do you monitor the health of a failover group and geo-replication link to catch problems before an actual failover is needed? I’d monitor replication lag specifically (available via metrics/DMVs), since sustained high lag is an early warning that the secondary isn’t keeping pace and your actual RPO in a real event would be worse than expected, and I’d set up Resource Health and Service Health alerts on both primary and secondary regions so a developing issue on the secondary is caught proactively, not discovered for the first time during an actual failover attempt.
27. What’s the difference between failing over and “failing back” — and why does failback deserve just as much planning? Failing over moves primary role to the secondary during an incident. Failing back moves it back to the original region once that region is healthy again — and it’s often treated as an afterthought, even though it involves the same risk (a role switch, a brief connection drop, re-syncing data) as the original failover. I’d plan and test failback with the same rigor as failover, rather than assuming it’s automatically simpler just because it’s “going back to normal.”
28. How does Azure SQL Managed Instance’s HA/DR model differ from Azure SQL Database’s? Managed Instance follows broadly similar principles — built-in HA by default, with failover groups available for cross-region DR — but its architecture and some operational details differ given it’s a full instance rather than a single database, including how Distributed Transactions across databases within the same instance behave during failover, and generally somewhat different (often longer) provisioning and failover timing characteristics that are worth validating specifically for Managed Instance rather than assuming Azure SQL Database’s numbers apply directly.
29. What’s the relationship between backup-based Geo-Restore and failover groups — do you need both? They protect against different things and generally aren’t redundant with each other — failover groups give you fast, low-RPO recovery from an already-synced live replica for a regional outage, while Geo-Restore recovers from backup data and protects against scenarios where you specifically need a point-in-time state (including, notably, recovering from your own data corruption or mistake that a live synchronized replica would have already replicated). Most serious DR strategies keep both layers rather than treating one as a full substitute for the other.
30. How would you test a DR failover without impacting production during the test? For active geo-replication/failover groups, you can generally initiate a planned (not forced) failover as a genuine test, which performs a clean, synchronized role switch you can then fail back from — the safer way to validate the mechanism actually works, versus a forced failover, which is meant specifically for a genuine emergency where the primary is already unavailable and you’re accepting the possibility of some data loss to fail over anyway.
31. What’s the difference between a “planned” and a “forced” failover? A planned failover performs a clean, fully synchronized switch — it waits for the secondary to be fully caught up before switching roles, so there’s no data loss, and it’s what you’d use for a genuine test or a scheduled maintenance-driven switch. A forced failover is used when the primary is already unavailable and you can’t wait for synchronization — it switches immediately, accepting the risk of losing any transactions that hadn’t yet replicated to the secondary, appropriate specifically for a real emergency, not routine testing.
32. How do you ensure application connection strings and retry logic are actually ready for a failover event, not just the database side? I’d verify the application uses the failover group’s listener endpoint (not a direct server name that would require a manual config change), confirm it has reasonable connection retry logic with backoff to handle the brief reconnect window gracefully rather than surfacing a hard failure to users, and actually test this during a planned failover exercise rather than just assuming the application team configured it correctly, since this is a very common gap between database-side DR readiness and actual application-side readiness.
33. What’s the cost trade-off consideration when deciding whether to run Business Critical tier purely for the faster failover time, versus General Purpose with a strong DR strategy layered on top? Business Critical’s faster HA failover addresses localized failures within the region faster, but doesn’t by itself solve regional DR — you’d still want geo-replication/failover groups on top regardless of tier. If your actual concern is mainly regional-outage DR rather than sub-minute local failover time, General Purpose plus a well-designed failover group might meet the requirement at meaningfully lower cost than Business Critical — it really depends on whether the specific RTO requirement can tolerate General Purpose’s somewhat longer local failover time, which is a question worth answering with real numbers, not assumption.
34. How would you approach documenting an HA/DR runbook so it’s actually usable by someone other than the person who designed it? Concrete, verifiable steps rather than vague guidance — not “initiate failover” but the actual portal path or specific PowerShell/CLI command, an explicit decision point for planned versus forced failover with the criteria for choosing each, expected timing so whoever’s executing it knows what “normal” looks like versus something going wrong, and a defined post-failover validation checklist (confirm application connectivity, confirm data looks correct) before declaring the incident resolved.
35. What’s a realistic scenario where built-in Business Critical HA alone would NOT be sufficient, and cross-region DR is genuinely required? Any scenario involving a full regional Azure outage — which does happen, even if rarely — since Business Critical’s HA replicas all live within the same region by default. A business with a genuine, non-negotiable requirement to survive that scenario (financial services regulatory requirements, healthcare systems with continuity mandates) needs cross-region failover groups regardless of how good the in-region HA already is, because in-region HA and cross-region DR are solving genuinely different failure scopes.
Advanced Level
36. Design a complete HA/DR architecture for a globally distributed financial application with a sub-minute RTO and near-zero RPO requirement. Walk through your reasoning. Business Critical tier as the baseline for fast in-region HA (sub-30-second local failover), combined with a failover group to a secondary region for genuine regional DR, using automatic failover policy given the sub-minute RTO requirement doesn’t leave room for manual decision-making delay. For near-zero RPO, I’d rely on the synchronous nature of Business Critical’s local replicas and validate actual geo-replication lag under realistic production load is consistently low enough to meet the RPO target — if it’s not, that’s a real constraint worth surfacing rather than assuming geo-replication automatically delivers near-zero RPO regardless of workload, since replication lag is workload-dependent, not a fixed guarantee. I’d layer zone redundancy within each region on top for additional resilience against datacenter-level failures short of a full regional event, and validate the entire design with scheduled planned failover tests, not just at launch but on a recurring cadence, since infrastructure and workload both drift over time.
37. Explain in detail how Business Critical’s synchronous replication actually achieves near-zero RPO, and what would cause that guarantee to degrade. Writes to the primary are synchronously confirmed against a quorum of the local secondary replicas before being acknowledged as committed, meaning a properly functioning Business Critical database genuinely shouldn’t lose committed transactions during a routine failover. That guarantee degrades under sustained heavy write load that outpaces the replicas’ ability to keep up (creating log-send/redo queue backlog), under network issues between replicas, or during a forced (not planned) cross-region failover, where the geo-replication link to a different region is asynchronous, not synchronous — meaning a cross-region forced failover genuinely can lose recent transactions in a way a local Business Critical replica failover normally wouldn’t.
38. How would you architect HA/DR for a solution using Hyperscale, given its different storage model, and what changes compared to a General Purpose/Business Critical design? Hyperscale’s HA replicas and its separately-purposed named replicas serve different roles — HA replicas provide failover protection, while named replicas are workload-isolated read-only copies not part of the failover topology at all, so I’d be deliberate about not conflating the two when designing for both availability and read-scaling needs. For cross-region DR, Hyperscale supports geo-replication similarly in principle, but I’d specifically validate failover and backup/restore timing at the actual data scale Hyperscale is typically chosen for (very large databases), since the numbers that hold for a modest-sized General Purpose database don’t automatically transfer to a 50TB Hyperscale database’s real-world failover behavior.
39. What’s your approach to designing HA/DR for a multi-tenant, sharded architecture across many Azure SQL databases, rather than a single database? Each shard needs its own HA/DR configuration (failover group membership, tier selection), but the harder problem is usually orchestration — ensuring a regional failover event triggers failover consistently across every shard together, not some shards failing over while others lag behind, which would leave the application in an inconsistent state mid-incident. I’d design the failover group grouping (or automation around it) at the shard-set level specifically to keep the whole logical dataset consistent, and validate that the shard map/routing metadata itself is also protected and correctly reflects the post-failover topology, since a correctly failed-over shard that the application can’t correctly route to is still effectively down.
40. How would you handle HA/DR design for a database using Always Encrypted, specifically regarding key availability during a regional failover? The encrypted data replicates fine as ciphertext along with everything else, but the column master key — typically in Azure Key Vault — needs to be genuinely accessible from the DR region too, not just the primary. I’d explicitly configure Key Vault with its own appropriate redundancy (or a replicated/paired Key Vault setup in the DR region) and test that the application can actually retrieve and use the key when connecting to the failed-over database in the secondary region, since a technically successful database failover that the application can’t actually decrypt data against is not a successful recovery in any practical sense.
41. Explain the trade-off between using automatic failover policy with a grace period setting versus immediate automatic failover, and how you’d choose the grace period value. The grace period delays automatic failover for a configurable window after an outage is detected, specifically to avoid failing over for a transient blip that resolves on its own within seconds — failing over unnecessarily has its own cost (a less-warmed-up new primary suddenly taking full production load, and an eventual failback that carries its own risk). I’d set the grace period based on realistic data about how long genuine transient issues in that environment typically take to self-resolve versus how long a real outage tends to last, rather than either extreme — too short risks unnecessary failovers, too long directly eats into your actual achievable RTO.
42. How would you design a DR strategy that accounts for dependencies beyond just the database itself — application tier, DNS, and networking? Database failover alone doesn’t recover the system if the application tier, DNS resolution, or network path (like a Private Endpoint or VPN/ExpressRoute connection) isn’t also failing over or already present in the DR region — I’d map every dependency in the full request path, not just the database, and specifically verify Private Endpoint DNS resolution correctly follows the failover group’s endpoint changes, since a private networking setup that isn’t correctly configured for the DR scenario can silently leave the application unable to reach an otherwise successfully failed-over database.
43. What’s your approach to capacity planning for a DR region, given the secondary needs to actually handle full production load if it becomes primary? I’d provision the secondary at a tier and size capable of handling genuine full production load, not a minimally-sized placeholder that technically satisfies “having a secondary” but would immediately struggle under real traffic if it actually had to take over — and I’d validate this periodically as production load and data volume grow over time, since a secondary that was appropriately sized a year ago may no longer be, if nobody’s revisited it since the original DR design.
44. How would you handle a scenario where a regional outage occurs, but only partially — some services in the region are degraded rather than fully down — and it’s genuinely unclear whether to trigger failover? This is exactly the scenario where a manual failover policy (or a human-in-the-loop override even on an automatic policy) earns its cost — I’d rely on Service Health and Resource Health data specifically for the affected resources rather than general regional status alone, since a broad regional issue doesn’t necessarily mean your specific database is actually impacted, and triggering an unnecessary failover in a genuinely ambiguous partial-outage scenario carries real cost and risk of its own. I’d have a pre-defined decision framework (which specific signals justify failover, who has authority to make the call) established before the incident, precisely because this kind of ambiguous scenario is the hardest to reason clearly about in the moment.
45. Explain how you’d validate that a DR failover genuinely met its RTO/RPO targets after a real (not test) incident, for post-incident reporting. I’d reconstruct the actual timeline from platform-level evidence — Resource Health state transitions, Activity Log entries for the failover operation itself, and application-side monitoring showing when service was genuinely restored from the user’s perspective, not just when the database technically completed failover — since “the database failed over” and “users could use the application again” aren’t necessarily the same timestamp. For RPO, I’d compare the last committed transaction visible on the new primary against the last known transaction from the original primary (via Query Store or transaction log evidence, where available) to quantify actual data loss precisely, rather than reporting an assumed RPO based on the platform’s typical behavior.
46. How would you design HA/DR for a hybrid environment where some data must remain on-prem for compliance, but is also accessed by applications now running against Azure SQL? I’d treat the on-prem and Azure SQL portions as having genuinely separate HA/DR requirements and strategies, rather than assuming Azure SQL’s DR capabilities somehow extend to protect the on-prem component too — the on-prem side needs its own traditional DR approach (its own Always On or backup-based strategy), and I’d pay particular attention to the connectivity layer between them (ExpressRoute/VPN redundancy) as its own dependency, since a perfectly designed DR strategy on both sides individually still fails as a whole system if the link between them is a single point of failure with no redundancy of its own.
47. What’s the risk of over-relying on Automatic Tuning or other automated features remaining consistent across a failover, and how would you account for it? Automatic Tuning’s learned state (forced plans, applied index recommendations) is tied to the specific database, and while it generally carries forward correctly through failover since it’s part of the database itself, I’d specifically validate this assumption for a genuinely critical database rather than assuming it transparently and identically after a regional failover — particularly worth confirming that a forced-plan decision made based on the primary region’s historical performance data still makes sense given potentially different underlying infrastructure characteristics in the secondary region.
48. How would you approach chaos-engineering-style testing for Azure SQL HA/DR, beyond a standard planned failover test? Beyond a clean planned failover, I’d look at testing more adversarial scenarios where realistic — simulating a forced failover to validate actual data-loss behavior under an unclean switch, testing application behavior when the failover group’s DNS change is slow to propagate (not every client resolves DNS changes equally fast), and testing failback under load rather than only during a quiet maintenance window, specifically because a real incident is unlikely to conveniently occur during low traffic — the goal is surfacing gaps that only show up under real, messy conditions rather than the clean, well-behaved conditions a standard planned test tends to represent.
49. Explain how you’d communicate HA/DR trade-offs and residual risk to business stakeholders who want “zero downtime, zero data loss” without understanding the cost implications. I’d translate the technical trade-off into business terms directly — quantify the actual cost delta between the tier/architecture that gets close to their stated ideal versus a more moderate, still-strong option, and be explicit about what residual risk remains even at the highest tier (a sufficiently catastrophic, simultaneous multi-region event is still technically possible, however unlikely), so the business is making an informed decision about accepting some quantified residual risk in exchange for cost, rather than being told a design achieves an absolute guarantee that no real system can actually make.
50. Walk through a genuinely difficult HA/DR incident or design challenge you’ve handled or would expect to handle, end to end. Intentionally open-ended — interviewers are evaluating judgment and sequencing, not a memorized script. A strong structure to demonstrate regardless of the specific scenario: (1) establish the actual RTO/RPO requirement clearly before designing anything, resisting the urge to default to the most expensive option without justification, (2) design layered protection matching the failure scope required — in-region HA for local failures, cross-region DR for regional ones, not conflating the two, (3) account for the full dependency chain, not just the database — application, DNS, networking, key management, (4) test the design for real, including edge cases like partial outages and forced failovers, not just the clean happy-path scenario, and (5) after any real incident, measure actual RTO/RPO achieved against target and feed genuine gaps back into the design rather than treating “we recovered eventually” as success on its own. Interviewers consistently favor candidates who can describe what they’d do when a scenario is genuinely ambiguous — a partial outage, an uncertain failover decision — over candidates who only have a clean answer for the textbook, unambiguous failure case.
A Closing Thought
The idea running through nearly every advanced answer here: HA and DR aren’t the same problem wearing different names, and neither one alone is a complete strategy — you need both, sized to the failure scope each is actually meant to survive, and you need to have genuinely tested the failover, not just configured it and assumed it works.
Discover more from Technology with Vivek Johari
Subscribe to get the latest posts sent to your email.
