Disaster Recovery and Business Continuity Questions

Designing and maintaining plans, architectures, and processes to ensure service continuity and recoverability after major incidents or disasters. Topics include defining Recovery Time Objective and Recovery Point Objective, conducting business impact analysis and tiering services by criticality, dependency mapping and recovery ordering, selecting replication and backup strategies including synchronous and asynchronous replication, active active and active passive topologies, snapshots and transaction log based point in time recovery, and planning cold, warm, and hot recovery sites. Also covers failover and failback procedures, orchestration and automation of recovery workflows, runbook creation and stakeholder roles and communications, regular disaster recovery testing and exercises including tabletop, simulated failover, full recovery drills and chaos engineering, metrics tracking such as mean time to recovery and actual Recovery Time Objective achieved, off site and geographic redundancy considerations, cloud versus on premise trade offs, regulatory and data residency requirements, and postexercise reviews to close recovery gaps.

EasyTechnical

24 practiced

As a Solutions Architect, summarize your primary responsibilities in disaster recovery and business continuity during the pre-sales and post-sales phases. Provide at least three concrete deliverables or activities you would lead in each phase.

EasyTechnical

25 practiced

Describe the steps in conducting a Business Impact Analysis (BIA) for an enterprise application portfolio. Provide a short example table with at least three services and the columns: criticality, approximate revenue impact per hour, RTO, RPO, and recovery-team owner. Explain how you would use this output to prioritize recovery efforts.

Sample Answer

Steps to conduct a Business Impact Analysis (BIA) for an enterprise application portfolio

1. Scope & stakeholders: Identify all applications/services, business owners, and recovery stakeholders (IT ops, app teams, finance, legal).2. Data collection: Use surveys/interviews to gather usage patterns, dependencies, SLA history, and financial metrics (revenue per hour, regulatory fines, reputational impact).3. Identify critical business processes and map to applications and dependencies (databases, middleware, external APIs).4. Assess impact: For each service estimate tangible (revenue loss/hour, penalties) and intangible (customer churn, brand) impacts over time.5. Define Recovery Objectives: Derive RTO (Recovery Time Objective) and RPO (Recovery Point Objective) from impact curves and business tolerance.6. Assign owners & recovery teams: Nominate technical owners and cross-functional recovery-team leads.7. Validate & prioritize: Review results with stakeholders, run tabletop exercises to validate assumptions.8. Document & integrate: Produce prioritized runbooks, SLA adjustments, and DR plans; feed into budget and architecture decisions.9. Review cadence: Update BIA annually or after major changes.

Using the output to prioritize recovery:- Rank services by combined score (criticality × revenue impact × SLA sensitivity). Focus immediate resources on High-criticality/high revenue-per-hour items (Payment Gateway) — aim for faster restore strategies (active-active, warm failover).- Map dependencies: restore foundational services first (auth, databases) even if their revenue impact appears lower.- Allocate DR investments proportionally: shorter RTO/RPO require automation, replication, and runbooks; longer RTOs can use manual restore playbooks.- Use the BIA to drive runbook creation, DR testing frequency, and budget decisions — test highest-priority services most frequently and ensure owners are trained and reachable.

EasyTechnical

29 practiced

Define active-active and active-passive topologies. For a global REST API, what are the main consistency and operational challenges of active-active? For a relational OLTP database, when would you favor active-passive instead?

Sample Answer

Active-active vs active-passive — definitions- Active-active: Two or more datacenters/regions accept reads and writes concurrently and replicate changes between them (multi-master). Improves locality, availability, and write throughput.- Active-passive: One primary site accepts writes; one or more secondaries are replicas (hot or cold). Failover promotes a passive to primary; replication is typically one-way.

Main consistency and operational challenges of active-active for a global REST API- Data consistency: Concurrent writes to different regions create conflicts (last-write-wins, vector clocks, CRDTs needed); achieving strong consistency globally requires synchronous replication which increases latency.- Read-your-writes and session consistency: Ensuring client sees its own recent updates across regions needs sticky sessions or causal mechanisms.- Conflict resolution: Designing deterministic, domain-appropriate merge logic is hard for relational schemas and business rules.- Latency vs consistency trade-offs: Either accept higher API latency (synchronous) or weaker consistency (eventual).- Operational complexity: More complex deployment, testing, monitoring, observability across regions; harder failure modes (split-brain), schema migrations coordination, and backup/restore across multi-master topology.- Security and compliance: Cross-region data residency and GDPR considerations complicate replication.

When to favor active-passive for a relational OLTP database- Strong consistency required: Financial, inventory, or transactional systems where lost/merged updates are unacceptable.- Complex relational constraints and transactions: ACID semantics and complex joins/foreign keys are easier with single-writer primary.- Simpler operational model: Easier schema migrations, backups, point-in-time recovery, and predictable failover behavior.- Low global write volume or acceptable failover RTO: If most clients are read-heavy or writes can be routed to a single region, active-passive reduces risk.- Compliance/regulatory constraints: Ensures data locality and simpler audit trails.

Summary: Use active-active when low-latency global writes and high availability outweigh consistency complexity and you can design conflict resolution; prefer active-passive for strict ACID relational workloads, simpler ops, and regulatory needs.

MediumTechnical

26 practiced

Design a communications plan template for major incidents impacting availability, specifying stakeholders (executives, customers, engineering, legal), cadence of updates, content templates for status pages, and escalation thresholds. Provide an example first 60-minute communication sequence for a critical outage.

Sample Answer

Communications Plan Template — Major Incidents (Availability)

Purpose: Ensure timely, accurate, and role-appropriate communications during availability-impacting incidents to preserve trust, enable recovery, and manage legal/regulatory risk.

Stakeholders & Roles- Executives (CIO/VP): receive impact/business risk, decision points, estimated customer impact.- Customers (end-users, paying customers, partners): receive clear status, ETA, mitigation steps, workarounds.- Engineering (SRE, App, Infra): receive technical symptoms, scope, ownership, required actions.- Legal & Compliance: receive potential SLA/regulatory impact, messaging review for public statements.- Customer Success / Sales / Support: receive Q&A, templates for customer conversations.

Cadence of Updates- T0 (Detection): initial internal alert (engineering + incident commander)- T+5m: initial external acknowledgement for customers (if outage visible) or “we’re investigating” status- T+15m: technical summary + current impact + next update ETA- T+30m: progress update with actions taken, estimated time to resolution (ETTR) or “investigation ongoing”- Every 30 minutes thereafter until resolved; then postmortem notification within 48–72 hours

Escalation Thresholds- P1 / Critical: >50% customer impact or revenue-affecting, escalate to Execs and Legal immediately; incident commander + war room- P2 / High: Major feature degraded for >30 min, notify product leads and customers with targeted scope- P3 / Medium: Minor degradation, update service desk and monitor; no exec escalation unless worsens

Status Page Content Templates- Header: Incident ID, start time, affected services- Impact Summary: Who is affected, user-visible symptoms- Current Status: Investigating / Identified / Mitigating / Resolved- Actions Taken: Short bullet list of fixes/rollbacks/workarounds- ETA / Next Update: concrete time or “next update in X minutes”- Contact / Workarounds: links to support, temporary mitigations- Postmortem link: to be added after RCA

Example First 60-Minute Communication Sequence (Critical Outage)- T0 (00:00) — Internal alert: “INC-2025-001 detected: API 500 errors at 00:00. Impact: 80% of traffic failing. Incident Commander: Alice (SRE). Initial action: collect logs, open war room.”- T+5m (00:05) — Public status page & customer email: “We’re aware of widespread API errors affecting most users. Engineers investigating. No ETA yet. Next update at 00:15. Status: Investigating. [support link]”- T+15m (00:15) — Internal update to Execs & Legal: “Root cause suspected: database connection pool exhaustion after recent deploy. Rolling back last deploy now. Estimated mitigation in 10–15m. Customer impact remains high. Preparing customer-facing FAQ.”- T+20m (00:20) — Status page update: “Identified cause: recent deploy increased DB connections. Rolling back deploy. Mitigation expected within 10 minutes. Next update at 00:30.”- T+30m (00:30) — Internal engineering update: “Rollback completed at 00:28; system recovering. Error rate down from 80% to 35%. Continued monitoring; scaling DB pool and validating integrity.”- T+40m (00:40) — Status page: “Mitigation in progress: rollback complete, error rates improving. Partial service restored for majority; some regions still degraded. Next update at 01:00 or sooner.”- T+60m (01:00) — Resolution bulletin (if recovered): “Service restored at 00:55. Root cause: connection leak introduced in recent deploy causing DB exhaustion. No data loss. Postmortem scheduled within 72 hours. Credits/SLA info: contact support.” If not recovered, provide updated ETTR and actions.

Best practices- Keep external messages concise, non-technical, and repeat ETA.- Use templates to speed messaging; have pre-approved legal phrasing.- Assign single Incident Commander and single Exec liaison to centralize communications.- Log all messages for postmortem timelines and SLA calculations.

EasyTechnical

23 practiced

Describe three storage-consistency concerns when taking backups of a multi-tier application (e.g., web front-end, application servers, relational DB, cache). For each concern, propose a mitigation strategy to ensure recoverable, consistent backups across tiers.

Unlock Full Question Bank

Get access to hundreds of Disaster Recovery and Business Continuity interview questions and detailed answers.

Join thousands of developers preparing for their dream job.