2.2 Business Continuity
Official task mapping
SAP-C02 task 2.2: Replication and recovery knowledge; continuity architecture and recovery tests. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review recovery objectives, Aurora and S3. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Continuity design
Multi-AZ mitigates selected AZ failures; multi-Region can address regional disruption but adds data, routing and operational complexity. RDS Multi-AZ DB instance standbys are not read replicas. Aurora readers and global databases have product-specific replication/failover behavior; do not assume synchronous zero-loss cross-Region replication.
Replicate durable application data separately from stateless compute. S3 replication does not replace versioned backups or independently protected recovery points. Validate permissions, encryption keys, artifacts, secrets and quotas in the destination before an outage.
Queues buffer work but do not restore a database or guarantee business-level completion. Consumers need idempotency, retries and dead-letter/replay procedures. DNS health checks must represent meaningful service health; network reachability alone is insufficient.
Replication and recovery reference
| Mechanism | Main objective | Important caveat |
|---|---|---|
| RDS Multi-AZ DB instance | Automatic standby failover | Standby is not read-scale capacity |
| RDS read replica | Offload supported reads | Lag and promotion/cutover behavior |
| Aurora readers/global database | Supported scale/regional recovery | Version/topology and failover guarantees |
| S3 CRR/SRR | Copy eligible objects across buckets | Versioning, permissions and replication rules |
| S3 Batch Replication | Replicate eligible existing objects | Job scope/cost and prerequisites |
Live replication rules do not automatically backfill every object created before configuration. Existing-object migration requires an appropriate batch process. Replication also does not preserve every deleted/corrupted business state as a safe recovery point.
SQS queues provide buffering with retention and consumer responsibilities; SNS fans out supported subscriptions. Neither guarantees that an order was processed successfully merely because a message was delivered.
Continuity drill extension
Assume a write arrives just before failover, the old Region still accepts writes, and replication is delayed. Decide which endpoint may accept new writes, what fencing prevents split brain and how reconciliation identifies the incomplete order. Test DNS convergence and client reconnection separately. A quoted sub-second normal replication latency is not a guaranteed outage RPO.
Scenario and rationale
An order portal must resume within 30 minutes after regional disruption with at most five minutes of data loss. A warm secondary with appropriate database replication may meet those objectives if promotion, write fencing and routing have been tested. Quantify replication lag rather than assuming a zero RPO.
Reject nightly backup-only recovery for the five-minute data-loss target. Reject two writable database copies without conflict management: availability can become inconsistent orders. Multi-AZ alone does not cover the specified Region-wide event.
Practice drill
Create a failover runbook with detection, decision authority, source-write fencing, database promotion, secrets/routing updates and transaction reconciliation. Estimate each step and test whether it fits 30 minutes. Add a failback plan that avoids split-brain writes. Use a tabletop event first; an actual regional failover requires separate authorization.
References
- Official Domain 2 task guide
- RDS Multi-AZ DB instance behavior
- Aurora global database recovery
- S3 replication considerations
Return to Domain 2. The drill is proposed study work, not a claim of a completed deployment.
Across the wiki
- AKS Backup, Disaster Recovery, and Cross-Region Business Continuity — backup and disaster recovery (Azure)
- Backup for GKE Architecture, Stateful Disaster Recovery, and Cross-Region Restoration — backup and disaster recovery (GCP)
- Backup & Restore — backup and disaster recovery (Kubernetes)
- Disaster Recovery — backup and disaster recovery (Architecture)