Interview prompt. A team tells you "we run in three regions, so disaster recovery is covered". The platform is an edge delivery business of Akamai's kind. Take it from here.
Show the full answer Hide the answer
What the interviewer is testing
Whether you can distinguish redundancy from recovery. Multi-region addresses exactly one failure class: the loss of a region's infrastructure. It does nothing for the three disasters that actually happen most often - a bad change, a deletion, and a compromised credential - because all three replicate to every region, correctly and quickly.
The clarifying questions that change the answer
- Is it active-active for writes, or active-passive? If writes are single-homed, two of the three regions are read-only capacity and the recovery time is a promotion procedure whose last rehearsal has a date.
- What is the actual RPO? Cross-region replication is asynchronous almost everywhere, so the honest answer is "minutes, varying with load", not zero. If anyone has promised zero, that is the first thing to correct.
- Which dependencies are global rather than regional? Identity, DNS, the deployment pipeline, the secret store, the container registry, the certificate authority, the observability stack. A region that cannot authenticate, deploy, resolve names or pull an image is not a recovery site, and these are the dependencies that are invisible until exercised.
- Where are the backups, and in whose account? Backups inside the same account as the primary do not survive a credential compromise or a deletion with sufficient privileges.
- When was a failover last performed, and what broke? A failover that has never been performed has an unknown recovery time, which is not a number you can put in a plan.
- What is the RTO for data corruption, as opposed to infrastructure loss? They are different numbers, usually an order of magnitude apart, and only one of them has been thought about.
A strong answer's arc
Separate the failure classes and show which control covers which:
| Failure | Covered by | Not covered by |
|---|---|---|
| Region or zone loss | multi-region or multi-zone capacity | backups alone - too slow |
| Bad deploy or bad config | staged rollout - fast rollback | replication - which copies it everywhere |
| Deletion or corruption | point-in-time restore - immutable backups | replication - which copies the deletion |
| Credential compromise | separate account - immutable backups - least privilege | replication - which the credential also controls |
Then make the asymmetry explicit: replication copies corruption at the speed of the network, and backups are the only mechanism that holds a point in time. Everything else in disaster recovery is a variation on that sentence.
Common weak answers
- "We have three regions, so we are covered." The claim under examination, and it is a statement about capacity, not about recovery.
- "Backups run nightly." Untested backups are an intention. The deliverable is a restore with a measured duration, repeated on a schedule.
- "The provider handles durability." Durability is not recovery: the provider will faithfully store the corrupted version.
What a strong answer adds
Three things. A restore drill with a number attached, performed often enough that the number is current. Immutable, separately-governed backups - a different account or tenancy, with object-lock or equivalent so that no single compromised credential can both corrupt and destroy the history. And a dependency inventory for the recovery path, so that the first thing you discover during a regional failure is not that the deployment pipeline only existed in the region you lost.