All jobs / DevOps / SRE / cloud

Backup & Disaster Recovery interview questions

Backup & Disaster Recovery questions a DevOps / SRE / cloud can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. “We have a replica, so we do not need backups.” Is that true?

    The strongest answer: No — a replica copies a mistaken DROP TABLE within seconds; replicas protect against hardware or zone failure and serve reads, backups protect against human error, bugs and ransomware. You need both

    Why it works: Exactly — replication propagates errors; backups let you go back in time. Different failure classes, different tools.

    • Replicas copy mistakes too.
    • Backups are point-in-time.
    • Different failures, both needed.
    • Test the restore.

  2. A single-region app has snapshots. A region fails. What do you still not have?

    The strongest answer: A restore story in another place and a practiced RTO/RPO — snapshots in the same burning region are not DR

    Why it works: Exactly. Off-region and practiced. Managed is not a restore test.

    • Backups off-region.
    • A practiced restore.
    • Name RTO/RPO without inventing percentages.
    • Managed ≠ tested DR.

  3. Backups are stored in the same cloud account as production, written by the same credentials that run the app.

    What is the risk, and what does the design look like?

    The strongest answer: One leaked credential, ransomware run or `terraform destroy` erases production and its backups together; copies go to a separate account with independent credentials and immutable or object-locked storage, and restores are tested from that copy

    Why it works: Right — isolation is the property. Separate blast radius, immutability, and a restore drill from the isolated copy.

    • Separate account, separate credentials.
    • Immutable or object-locked.
    • Blast radius is the property.
    • Restore from the isolated copy.

  4. The DR doc is beautiful and unrun. What do you schedule?

    The strongest answer: A game day that actually fails a dependency and restores, with a clock — I do not count a tabletop as a restore test

    Why it works: Exactly. Touch the restore. Tabletops teach talk, not muscle. Surprise-prod is cruelty.

    • Run a game day.
    • Fail something real.
    • Time the restore.
    • Do not ambush prod.

  5. The primary region is degraded, not down: errors at a few percent, the provider says “investigating”. A warm standby exists in another region.

    Do you fail over? How do you decide?

    The strongest answer: Against criteria agreed before today: expected recovery time versus our RTO, replication lag versus our RPO, one named person with the authority, and the cost of failing back — an unrehearsed failover can be worse than the degradation

    Why it works: Right — the decision is designed in advance: thresholds, authority and the fail-back plan. The incident is when you execute, not when you invent.

    • Decide the criteria before the day.
    • RTO and RPO versus estimates.
    • One person holds the authority.
    • Plan the fail-back too.

  6. Give the one-sentence residual you would say before a region-failover game day.

    The strongest answer: “We will fail the dependency we named; we have not proved a real region loss, and the product owner accepted that the game day is a step, not DR-done.”

    Why it works: Exactly. What you will prove, what you will not, who accepted. That is residual.

    • Proved / not proved / accepter.
    • Name the step.
    • Do not say “we are HA.”
    • Do not hide behind the vendor SLA.