Design a disaster recovery strategy for a revenue-critical workload on AWS. How do you pick between backup-and-restore, pilot light, warm standby, and active-active?
What they are really testing: Whether you start from RPO and RTO targets and the cost of downtime, and then map those numbers onto a DR pattern, rather than reaching for the most expensive option by reflex. They want the business-driven trade-off, not a pattern recital.
A real interview question
Design a disaster recovery strategy for a revenue-critical workload on AWS. How do you pick between backup-and-restore, pilot light, warm standby, and active-active?
What most people say
drag me
“We take nightly backups and we could restore them to another region if something goes wrong.”
It picks a pattern with no RPO/RTO target behind it, so it cannot say whether hours of data loss and a manual restore are acceptable. There is no automation, no rehearsal, and no awareness that the data tier sets the recovery floor.
The follow-ups they ask next
Your RPO target is near zero but your RTO can be an hour. What does that combination let you build?
Near-zero RPO forces continuous/synchronous-ish replication so data is always current, but a relaxed RTO means you do not need warm compute standing by. That points at pilot light: replicate data continuously, keep compute scaled down, and accept the time to scale it up on failover.
How do you know your DR plan actually meets its RTO?
You measure it. Run a game day that fails over to the DR region under realistic conditions and time the actual recovery against the target. Untested DR routinely misses RTO because of unautomated steps, stale AMIs, or DNS TTLs nobody accounted for.
What the interviewer is listening for
- Derives the pattern from RPO/RTO and downtime cost
- Knows all four patterns and their cost/recovery curve
- Treats data replication as the floor on RPO
- Automates and rehearses failover
What sinks the answer
- Picks a pattern with no RPO/RTO target
- Confuses backups with a tested DR plan
- Ignores replication lag when claiming an RPO
- Never rehearses the failover
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“First I pin [RPO, RTO, cost of downtime] from the business. Those map onto [backup-and-restore, pilot light, warm standby, active-active]. The data tier sets the floor, so [cross-region DB and S3 replication], and RPO is bounded by [replication lag]. I automate failover with [Route 53 health checks + IaC] and [rehearse it on a schedule]. Trade-off: I chose [pattern] over [next tier] because [RTO did not justify the cost].”
Keep going with architecture & design
Junior
How does putting a load balancer in front of your app improve availability, and what does it NOT solve?
Junior
What is autoscaling, and how does it decide when to add or remove instances?
Senior
Design a highly available web application on AWS. Walk me through the architecture and your trade-offs.
Senior
Design a scalable async processing pipeline for spiky, long-running work (think video transcoding or report generation). Walk me through the queue-based architecture and its failure modes.
Senior
You own a system of many services and an incident took too long to diagnose. Design an observability strategy across the whole estate.
Senior
Design a CI/CD pipeline that lets a team deploy many times a day safely. How do you make production changes low-risk with progressive delivery?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free