Overview
Resilient Cloud Solutions has three task statements. The first asks you to turn business requirements into resilience needs, remove single points of failure, and spread workloads across Availability Zones and Regions using cross-Region features of DynamoDB, Amazon RDS, Route 53, Amazon S3 and CloudFront. The second covers scalability: fixing scaling issues, choosing auto scaling, load balancing and caching, running containers on Amazon ECS and EKS, and configuring serverless services such as API Gateway, Lambda and Fargate.
The third task statement focuses on automated recovery. You test Multi-AZ and multi-Region failover for RDS, Aurora, Route 53 and CloudFront, pick cross-Region backup strategies with AWS Backup, S3 and Systems Manager, and set up load balancers to route around unhealthy targets.
How it's tested
Domain 3 questions give a workload, a failure or load pattern, and usually numeric RTO, RPO or latency targets. You choose the replication feature, failover method, scaling policy or recovery automation that meets the numbers at the lowest reasonable cost and effort.
-
Match the DR strategy
RTO and RPO values are stated, and you choose backup and restore, pilot light, warm standby or active/active.
-
Remove the weak point
A single instance, AZ or Region dependency is described, and you choose the change that eliminates it.
-
Scale correctly
Load spikes or slow scale-out occur, and you choose scaling policies, warm pools, caching, capacity providers or concurrency settings.
A database must fail over to another Region with an RPO under one second and an RTO under one minute. Cross-Region read replicas replicate asynchronously and need manual promotion, which can take longer. Aurora Global Database replicates with typical lag under a second and supports managed failover to a secondary Region, so it meets both targets with the least custom automation.
Task statements 3
Official task statements from the Amazon Web Services outline, in outline order.
3.1 Implement highly available solutions to meet resilience and business requirementsResilience requirements, single points of failure, cross-Region features and multi-AZ load balancing.
- What it means
- This task covers translating business needs into resilience targets, finding and removing single points of failure, enabling cross-Region capabilities in DynamoDB global tables, RDS and Aurora, Route 53, S3 replication and CloudFront, configuring load balancers across Availability Zones, and running applications in several AZs and Regions with minimal downtime.
- What to understand
- High availability starts with at least two AZs behind an Elastic Load Balancer and a database with a standby. Cross-zone load balancing spreads requests evenly across targets in every enabled AZ. DynamoDB global tables provide multi-Region active/active writes. S3 Cross-Region Replication copies objects for durability or locality, and CloudFront origin groups fail over to a secondary origin.
- How it shows up
- A design has a hidden single point of failure, and you choose the change that keeps service running.
- Common confusion
- Thinking Multi-AZ RDS standby serves read traffic; in the classic Multi-AZ instance setup it is only for failover.
3.2 Implement solutions that are scalable to meet business requirementsScaling issues, auto scaling, caching, containers, global deployment and serverless.
- What it means
- This task covers diagnosing and fixing scaling problems, choosing auto scaling, load balancing and caching (ElastiCache, CloudFront, DAX), deploying containers on ECS and EKS, deploying in several Regions for global reach, and configuring API Gateway, Lambda and Fargate for serverless scale.
- What to understand
- Target tracking keeps a metric near a value, step scaling reacts to alarm breaches by size, and predictive scaling forecasts cyclical load. Warm pools shorten scale-out for slow-booting instances. ECS capacity providers scale cluster capacity with tasks, while EKS uses tools such as Karpenter or Cluster Autoscaler. Lambda reserved and provisioned concurrency control throttling and cold starts.
- How it shows up
- A workload fails to keep up with load, and you choose the scaling, caching or platform configuration that fixes it.
- Common confusion
- Raising instance size when the real problem is slow scale-out that warm pools or predictive scaling would fix.
3.3 Implement automated recovery processes to meet RTO and RPO requirementsFailover testing, cross-Region backup and load balancer recovery from backend failure.
- What it means
- This task covers testing failover for Multi-AZ and multi-Region workloads on RDS, Aurora, Route 53 and CloudFront, choosing cross-Region backup and recovery strategies with AWS Backup, Amazon S3 and Systems Manager, and configuring load balancers to recover when backend targets fail.
- What to understand
- RTO is how long recovery may take, and RPO is how much data loss is tolerable. AWS Backup plans can copy recovery points to another Region and account, and vault lock prevents deletion. Route 53 failover routing uses health checks to move traffic. AWS Fault Injection Service lets teams test failure handling safely. ELB health checks remove failed targets, and Auto Scaling replaces them.
- How it shows up
- Recovery targets are given, and you choose the backup, replication or failover automation that meets them.
- Common confusion
- Assuming a backup alone meets a low RTO; restoring large data sets can take far longer than failing over to a replica.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
RTO and RPO
Allowed downtime and allowed data loss.
- Remember
- Lower values cost more.
- Tested as
- Drive every DR choice.
- Trap
- Mixing up which one measures data loss.
-
DR strategies
Backup and restore, pilot light, warm standby, multi-site active/active.
- Remember
- Ordered from slowest and cheapest to fastest and costliest.
- Tested as
- Matching numeric targets.
- Trap
- Picking active/active when warm standby meets the target.
-
Aurora Global Database
Storage-level replication to up to several secondary Regions.
- Remember
- Typical lag under a second, managed cross-Region failover.
- Tested as
- Low RPO multi-Region databases.
- Trap
- Using cross-Region read replicas for sub-minute RTO.
-
DynamoDB global tables
Multi-Region, multi-active table replicas.
- Remember
- Last-writer-wins conflict resolution.
- Tested as
- Active/active NoSQL scenarios.
- Trap
- Expecting strong consistency across Regions by default.
-
Route 53 failover routing
Routes to a secondary record when health checks fail.
- Remember
- Health checks can monitor endpoints or CloudWatch alarms.
- Tested as
- Regional failover questions.
- Trap
- Forgetting the health check on the primary record.
-
AWS Backup
Central backup policies across services and accounts.
- Remember
- Cross-Region and cross-account copies, Vault Lock.
- Tested as
- Backup strategy questions.
- Trap
- Writing custom snapshot scripts instead.
-
Auto Scaling warm pools
Pre-initialized instances waiting to join the group.
- Remember
- Cut scale-out time for slow boots.
- Tested as
- Latency during spikes.
- Trap
- Overprovisioning the whole fleet instead.
-
ECS capacity providers
Link ECS services to Auto Scaling groups or Fargate.
- Remember
- Managed scaling adjusts cluster capacity.
- Tested as
- Container scaling questions.
- Trap
- Scaling tasks without scaling instances underneath.
-
Lambda concurrency controls
Reserved and provisioned concurrency settings.
- Remember
- Provisioned concurrency removes cold starts.
- Tested as
- Serverless scale and latency.
- Trap
- Using reserved concurrency to fix cold starts.
-
CloudFront origin failover
Origin groups switch to a secondary origin on errors.
- Remember
- Works for GET, HEAD and OPTIONS requests.
- Tested as
- Static content resilience.
- Trap
- Expecting it to fail over write requests.
-
AWS Fault Injection Service
Managed fault injection experiments.
- Remember
- Stop conditions tie to CloudWatch alarms.
- Tested as
- Testing resilience safely.
- Trap
- Testing failover only during real incidents.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Disaster recovery strategies
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Backup and restore | Restore from backups after a disaster | Hours of RTO, lowest cost | Choosing it for minute-level RTO |
| Pilot light | Core data replicated, compute off | Start compute on failover | Assuming servers already run |
| Warm standby | Scaled-down full copy running | Scale up on failover | Confusing it with pilot light |
| Multi-site active/active | Full capacity in several Regions | Near-zero RTO, highest cost | Choosing it when cost is a constraint |
Database resilience options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| RDS Multi-AZ | Synchronous standby in another AZ | AZ failure only | Expecting Region protection |
| Cross-Region read replica | Asynchronous copy in another Region | Manual promotion | Expecting automatic failover |
| Aurora Global Database | Fast storage replication across Regions | Managed cross-Region failover | Assuming it is the same as Multi-AZ |
Scaling policy types
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Target tracking | Holds a metric near a target | Simplest, self-adjusting | Setting conflicting step policies too |
| Step scaling | Adds capacity by breach size | Fine-grained control | Using it for forecastable cycles |
| Predictive scaling | Forecasts load from history | Scales ahead of demand | Using it for random spikes |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Multi-AZ means multi-Region
- What candidates pick
- Rely on RDS Multi-AZ for Regional disaster recovery.
- Why it looks right
- Multi-AZ sounds highly available.
- Why it's wrong
- The standby lives in the same Region, so a Regional outage takes both copies down.
Clue to watch for The requirement mentions a Regional failure.
-
Replica as instant failover
- What candidates pick
- Use a cross-Region read replica for sub-minute RTO.
- Why it looks right
- Data is already in the second Region.
- Why it's wrong
- Promotion is a manual or scripted step and replication is asynchronous, so it rarely meets aggressive RTO.
Clue to watch for RTO measured in seconds or one minute.
-
Always active/active
- What candidates pick
- Run full stacks in two Regions.
- Why it looks right
- It gives the best availability.
- Why it's wrong
- It costs far more than warm standby or pilot light when the targets allow minutes or hours.
Clue to watch for Cost-effective wording with moderate RTO.
-
Reserved for cold starts
- What candidates pick
- Set reserved concurrency to fix Lambda cold starts.
- Why it looks right
- Concurrency settings sound related.
- Why it's wrong
- Reserved concurrency only caps and guarantees capacity; provisioned concurrency keeps environments initialized.
Clue to watch for Latency on first invocations.
-
Backups without copies
- What candidates pick
- Schedule daily snapshots in the same Region.
- Why it looks right
- Backups exist, so recovery seems covered.
- Why it's wrong
- A Regional event or account compromise removes them too; cross-Region and cross-account copies are needed.
Clue to watch for Regional disaster or ransomware wording.
-
Failover with no health check
- What candidates pick
- Create failover records without health checks.
- Why it looks right
- Routing policy looks set up.
- Why it's wrong
- Route 53 needs a health check on the primary to detect failure and switch traffic.
Clue to watch for Automatic DNS failover required.
Answer framework
Work through these steps when a question asks how to keep a workload available, scalable or recoverable.
- Write down the RTO, RPO and failure scope stated in the question: instance, Availability Zone or entire Region.
- Match the targets to the cheapest DR strategy that meets them, from backup and restore up to active/active.
- Pick the data replication feature that fits the store, such as Aurora Global Database, DynamoDB global tables or S3 replication.
- Confirm that detection and switching are automatic through health checks, alarms, Route 53 failover or managed database failover, and that the failover path has been tested recently.
- For scaling issues, identify the bottleneck layer and apply the matching policy, warm pool, cache, capacity provider or concurrency setting.
Practice question
Want more like this? The DOP-C02 practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Anchor this domain on numbers. Make a table of the four DR strategies with typical RTO, RPO and relative cost, and next to each one list the AWS features that implement it. Most questions become quick once you can map the stated targets to a row in that table.
Then practice failover by hand. Create an Aurora Global Database and perform a managed failover, set up Route 53 failover records with health checks, configure a CloudFront origin group, and copy an AWS Backup recovery point to another Region. Run a short AWS Fault Injection Service experiment that stops instances and watch the Auto Scaling group and load balancer recover.
For scaling, deploy a small service on ECS with a capacity provider and on Lambda with provisioned concurrency, and load test both. Note how long scale-out takes and what metric triggered it. Spend roughly 15% of your study time here, weighted toward the failover and DR comparisons that appear most often.
FAQ
How much of DOP-C02 is Resilient Cloud Solutions?
Resilient Cloud Solutions makes up 15% of scored content, which is around 10 of the 65 scored questions on the exam.
Do I need to memorize RTO values for each DR strategy?
Exact numbers are not published as rules, but you should know the order from backup and restore to active/active and roughly what recovery time each supports.
How is this different from the Solutions Architect Professional exam?
Topics overlap, but DOP-C02 stresses automating and testing failover and scaling, not only picking the architecture. Expect questions about health checks, runbooks and recovery testing.
Are EKS questions deep?
The guide lists deploying container applications on ECS and EKS. Expect scaling and deployment choices rather than detailed Kubernetes administration.
Is AWS Elastic Disaster Recovery in scope?
The domain names AWS Backup, S3 and Systems Manager for recovery. Check the in-scope services list in the exam guide before spending much time on other DR tools.
What caching services should I know?
Know when ElastiCache, DynamoDB Accelerator and CloudFront reduce load on a backend, and how caching helps meet scaling requirements cost-effectively.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have covered high availability, scaling and automated recovery. Check whether you can match RTO and RPO numbers to the right design under time pressure.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the DOP-C02 AI tutor Get any concept explained your way