SAP-C02
Deep Dive
The SAP-C02 evaluates your ability to design DR architectures that meet specific RPO/RTO targets using the right services. Questions always include cost-vs-recovery-time tradeoffs you have to balance.
Contents
RPO — Recovery Point Objective
The maximum amount of data you can lose, measured as time from the last backup/snapshot to the moment of the disaster.
RPO = 1 hour → at most 1 hour of data lost
RPO = 0 → zero data loss (synchronous replication)
Determines: backup frequency, synchronous vs asynchronous replication
RTO — Recovery Time Objective
The maximum acceptable time to restore service after a disaster. The business can operate up to X hours without the system.
RTO = 4 hours → the system must be online within 4h
RTO = minutes → requires pre-deployed automatic failover
Determines: pre-warmed DR infrastructure or cold start
Multi-Site Active-Active
Two or more regions serve production traffic simultaneously. If one region fails, Route 53 or Global Accelerator automatically routes all traffic to the available region.
How to implement in AWS:
DynamoDB Global Tables (writes in every region), Aurora Global DB (writes only in the primary), Route 53 latency routing + health checks, an ALB in each region.
Use when:
RTO/RPO < 1 minute, mission-critical applications, gaming, real-time finance.
Warm Standby
A minimal-scale version of production runs in the DR region with reduced instance sizes. Data replicates continuously. On disaster, it scales up/out.
How to implement in AWS:
A cross-region RDS Read Replica (promoted to primary), minimal always-on EC2 instances in DR, an ASG configured to scale fast, Route 53 failover routing.
Use when:
An RTO of 15-60 minutes is acceptable. Higher availability than Pilot Light at a lower cost than Active-Active.
Pilot Light
Only the most critical components (database, data) are replicated to the DR region. Application and compute layers are off or minimal. They're started up on disaster.
How to implement in AWS:
RDS with cross-region snapshot or Read Replica, pre-configured AMIs for fast startup, ready-to-go CloudFormation templates, Route 53 with failover to the DR region.
Use when:
RTO of 1-4 hours. Balance between cost and recovery speed for important but non-critical systems.
Backup & Restore
Periodic data backup to S3 in another region. No pre-deployed DR infrastructure. On disaster, restore from backups and recreate the infrastructure.
How to implement in AWS:
S3 Cross-Region Replication for backups, AWS Backup to automate it, CloudFormation to recreate infrastructure, RDS snapshot copy to the DR region.
Use when:
Non-critical systems where hours/days of downtime is acceptable. Minimal cost.
| Policy | How it works | Health Checks | DR/HA use case |
|---|---|---|---|
| Failover | The Primary receives all traffic. If its health check fails, Route 53 routes to the Secondary. | Required on Primary | Active-passive DR between two regions |
| Latency | Routes to the endpoint with the lowest latency for the user. With health checks, avoids degraded regions. | Optional (recommended) | Active-active multi-region with latency-based routing |
| Weighted | Distributes traffic according to configured weights (e.g. 90/10 for canary releases). | Optional | Canary deployments, blue/green between regions |
| Geolocation | Routes based on the user's geographic location (country, continent, default). | Optional | Data compliance (GDPR: EU users → EU region) |
| Geoproximity | Routes based on physical proximity to the endpoint, with an adjustable bias. | Optional | Fine-tuning traffic distribution between nearby regions |
| Multivalue Answer | Returns up to 8 healthy IPs to the client. Each record has its own health check. | Required per record | Simple DNS-level load balancing with health checks |
Route 53 Health Checks — critical for DR
Endpoint checks
Verifies HTTP/S or TCP to an endpoint. Can evaluate the response string. Recommended: check an app /health endpoint, not just the TCP.
Calculated health checks
Combines the result of multiple health checks (AND/OR). Marks "healthy" only if every critical component responds.
CloudWatch alarm checks
The health check is based on a CloudWatch alarm's state. For resources without an HTTP endpoint (databases, queues).
| Feature | Global Accelerator | CloudFront |
|---|---|---|
| Main function | Accelerates network-level traffic routing (static anycast IPs) | CDN — caches content at edge locations |
| Traffic type | TCP and UDP (any protocol, not just HTTP) | Mainly HTTP/S |
| Caching | Does NOT cache — it's purely optimized routing | YES, caches static and dynamic content, configurable |
| Static IPs | YES — 2 fixed anycast IPs (never change) | NO — edge location IPs vary |
| Protocols | TCP, UDP, HTTP, HTTPS | HTTP, HTTPS, WebSocket |
| Failover | Automatic failover in < 1 minute to a secondary endpoint | Failover via Origin Groups with health checks |
| Use cases | Gaming (UDP), IoT, VoIP, API failover, static IPs for whitelisting | Websites, HTTP APIs, video streaming, static content |
| Shield Advanced | Included with Shield Advanced | Included with Shield Advanced |
AWS Backup is the centralized service for managing backups of multiple AWS services from a single place. For multi-account environments, AWS Backup is managed centrally via Organizations.
Supported services
Key features for the exam
Backup Vault Lock — the exam's "anti-ransomware shield"
Backup Vault Lock applies WORM (Write Once Read Many) to the vault. Once enabled, no one (not even the root user or AWS) can delete backups before they expire. It's the answer whenever the scenario says "protect backups from malicious deletion, even by admins with elevated privileges".
Resilience Hub analyzes AWS applications (via CloudFormation, Terraform, AppRegistry) and evaluates whether they meet the defined resilience policies (RTO/RPO targets). It generates a Resiliency Score and improvement recommendations.
Resiliency Policy
Defines RTO/RPO targets for different disruption types (AZ, region, hardware).
Application Assessment
Analyzes the architecture and identifies Single Points of Failure (SPoF) and resilience gaps.
Recommended Actions
Suggests concrete changes: add Multi-AZ, configure backups, add health checks.
Resiliency Score
A 0-100 score based on how many recommendations have been implemented.
Trap: "RPO is recovery time and RTO is data loss"
Reality: Reversed. RPO = maximum data loss (Recovery Point). RTO = maximum recovery time (Recovery Time). RPO determines backup frequency; RTO determines how much infrastructure you pre-warm.
Trap: "Warm Standby and Pilot Light are the same strategy"
Reality: They're different. Pilot Light only keeps the "core" running (replicated DB, critical data). Warm Standby keeps a minimal but complete version of the app running — ready to scale. Warm Standby has a lower RTO but a higher cost.
Trap: "Global Accelerator caches content like CloudFront"
Reality: FALSE. Global Accelerator caches NOTHING — it only optimizes network routing using AWS's backbone. Caching is exclusive to CloudFront.
Trap: "Route 53 Failover policy fails over instantly"
Reality: Route 53 detects the failure via health checks (checked every 30s by default). The DNS record's TTL also affects failover time. RTO isn't 0 — it can be 1-5 minutes.
Did you get this topic?
Test what you just learned
A financial services company has its main application in us-east-1. DR requirements are: RPO of at most 1 minute and RTO of at most 5 minutes. The budget doesn't allow for a full active-active architecture. What is the most suitable DR strategy?
Put what you learned to the test with original SAP-C02 exam questions.
Start SAP-C02 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.