SOA-C03 Reliability and Business Continuity Guide

AWS SOA-C03 reliability guide covering scaling, high availability, load balancing, backups, and disaster recovery decisions.

This chapter is where SOA-C03 tests whether you can keep workloads responsive during growth, keep them available during failure, and restore them correctly after disruption. AWS is not grouping these together by accident. The exam expects CloudOps engineers to separate elasticity, live resilience, and recovery discipline instead of treating all three as one vague “reliability” concept.

I verified the current SOA-C03 Domain 2 task split against the AWS exam guide on May 11, 2026. AWS currently breaks this domain into three operational abilities:

  1. implement scalability and elasticity
  2. implement highly available and resilient environments
  3. implement backup and restore strategies

Current weight in the exam guide

AWS currently weights Reliability and Business Continuity at 22% of scored content.

What this domain is really testing

This domain is not just about knowing what Multi-AZ means. AWS wants to see whether you can:

  • tell load growth apart from component or AZ failure
  • choose between scaling, availability, and disaster recovery without mixing their roles
  • use caching and managed-service elasticity to relieve pressure on the right tier
  • match restore and recovery design to the stated RTO and RPO
  • prefer repeatable, tested continuity procedures over hopeful backup settings

Work this domain in order

Lesson Official task fit Why it matters
2.1 Scaling, Elasticity & Caching Task 2.1 This is the demand-following lane: scale compute, offload repeated reads, and use managed database elasticity correctly.
2.2 HA, Load Balancing & Resilience Task 2.2 This is the survive-failure lane: health checks, load balancers, Multi-AZ design, and resilient service placement.
2.3 Backups, Restores & DR Task 2.3 This is the recovery lane: snapshots, point-in-time restore, AWS Backup, versioning, and tested DR procedures.

Fast routing inside this chapter

If the stem is really about… Go first to… What to look for
Auto Scaling, demand spikes, queue depth growth, cache offload, DynamoDB capacity, or database read pressure 2.1 Scaling, Elasticity & Caching demand pattern, bottleneck tier, cache or scaling fit
ELB health checks, Multi-AZ, Route 53 health-based failover, redundant targets, or fault tolerance during live failures 2.2 HA, Load Balancing & Resilience failure boundary, routing behavior, healthy target design
snapshots, AWS Backup, PITR, S3 versioning, RTO, RPO, restore workflow, or DR drills 2.3 Backups, Restores & DR acceptable data loss, acceptable downtime, recovery scope

Common domain traps

Trap Better thinking
“More instances means the workload is reliable.” More instances may improve elasticity, but reliability during failure needs redundancy and health-based routing.
“Multi-AZ solves scaling.” Multi-AZ primarily improves availability, not demand-following elasticity.
“We have backups, so business continuity is handled.” Continuity also requires restore timing, access, networking, runbooks, and testing.
“Caching is just a performance feature.” On this exam, caching is also a reliability tool because it reduces pressure on fragile backend dependencies.

How strong SOA-C03 answers usually work

  1. Decide whether the problem is growth, failure survival, or recovery.
  2. Stay in that lane until the evidence says otherwise.
  3. Use the narrowest control that satisfies the requirement.
  4. Avoid answers that are technically useful but solve the wrong reliability problem.
  5. Prefer repeatable and testable operational patterns over one-off manual fixes.

In this section

Revised on Monday, June 15, 2026