Exams / SAP-C03 / Study guide / Multi-Region failover (ARC, Route 53, Global Accelerator, multi-cluster containers)
Multi-Region failover (ARC, Route 53, Global Accelerator, multi-cluster containers): SAP-C03 study notes and practice questions
What to know about Multi-Region failover (ARC, Route 53, Global Accelerator, multi-cluster containers) for the SAP-C03 exam, from the Resilience, Migration, and Business Continuity domain (15% of the exam guide), then 2 free questions to test it. Part of the SAP-C03 study guide.
SAP-C03 asks how to fail over a multi-Region application quickly, safely and predictably, and how to keep containerized workloads available across clusters and Regions.
Traffic switching options
Option
How it moves traffic
Notes
Route 53 failover routing + health checks
DNS answer changes when the primary’s health check fails
Depends on DNS TTLs and client caching; health checks are part of Route 53’s data plane
Route 53 latency, weighted or geolocation routing with health checks
Healthy records only
Active/active across Regions
AWS Global Accelerator
Two static anycast IPs; edge sends traffic to the healthy Regional endpoint
Fast failover not tied to DNS caching; traffic dials and endpoint weights
ARC routing controls
On/off switches that drive Route 53 health checks, flipped through a highly available cluster of endpoints in five Regions
Deliberate, operator-controlled failover with safety rules
ARC zonal shift / zonal autoshift
Moves load balancer traffic away from one impaired AZ
For AZ failures, not Region failures; autoshift lets AWS shift for you
ARC Region switch
Orchestrated plans that run ordered steps (scale up, promote databases, switch traffic) across Regions
Repeatable, auditable Region failover runbooks
Facts that decide answers
Static stability: fail over using data plane actions (health checks, routing controls, pre-provisioned capacity), not control plane calls such as creating resources or editing DNS records in the impaired Region during an event.
Automatic health-check failover is fast but can flap; regulated or complex systems often prefer operator-initiated failover with ARC routing controls and safety rules (for example, never turn both Regions off).
The data layer must fail over too: promote an Aurora Global Database secondary (managed failover or switchover), point to the DynamoDB global table replica, or promote an RDS cross-Region replica. Write traffic and data failover must stay in step.
Pre-scale or keep warm capacity in the standby Region, and check service quotas there.
Multi-cluster containers
Run separate EKS or ECS clusters per Region (and spread nodes or tasks across AZs inside each); a cluster is a failure domain, so stretch neither a cluster nor its control plane across Regions.
Deploy the same manifests to every cluster with GitOps (Argo CD or Flux), CI/CD pipelines or IaC, so clusters stay identical.
ECR replication copies images to each Region so pulls don’t depend on the primary.
Front clusters with Route 53 or Global Accelerator, using health checks against each Region’s load balancer.
Keep state outside the cluster (Aurora Global Database, DynamoDB global tables, S3 CRR); for persistent volumes use replicated storage or backups through AWS Backup for EKS.
Zonal shift works with EKS to move traffic away from an impaired AZ inside a cluster.
How to choose
Scenario wording
Pick
“Failover must not depend on DNS caching, static IPs”
Global Accelerator
“Operators must trigger failover, with guardrails against mistakes”
ARC routing controls with safety rules
“One AZ degraded, move traffic out quickly”
ARC zonal shift or zonal autoshift
“Ordered, repeatable Region failover including database promotion”
ARC Region switch plan
“Simple active/passive web app, lowest cost”
Route 53 failover routing with health checks
“EKS app must survive a Region outage”
Clusters in two Regions, GitOps, ECR replication, Route 53
Common traps
Failover that creates resources in the recovery Region during the event.
One EKS cluster spanning Regions.
Switching traffic while the database is still read-only in the new Region.
A car maker runs its dealer-ordering application in two Regions, with the primary Region serving all traffic. The on-call leads must be able to move traffic to the secondary Region during an incident, but the team does not want automatic failovers triggered by a brief network blip.
The switch must be a single, deliberate action, and the system must refuse a change that would leave no Region serving traffic. The change must take effect within a few minutes.
Which solution meets these requirements?
Choose one answer.
AA. Create Route 53 failover records driven by health checks on the primary Region's endpoints, with a failure threshold of three checks, so that traffic moves automatically whenever the primary's health check fails.
BB. Edit the Route 53 weighted records by hand from the console during an incident, moving the weight from the primary to the secondary Region, with a 60-second time to live.
CC. Change the traffic dials in a Global Accelerator endpoint group by hand, moving the share of traffic from the primary to the secondary Region.
DD. Create an ARC routing control for each Region with a safety rule that refuses any change leaving no Region on, and tie the Route 53 records to routing control health checks that an on-call lead flips.
Show the answer and explanation
Answer: D
A. Wrong: Automatic failover on a health check is what the team ruled out, since a brief blip would move traffic. The option gives the on-call leads no deliberate switch.
B. Wrong: A manual edit is deliberate, but the console change has no safety rule that refuses a switch leaving no Region serving. Mistakes in the edit would go straight to customers.
C. Wrong: The dials can shift traffic deliberately, but the option has no safety rule that blocks a change leaving no Region serving. The requirement calls for that check.
D. Right: Correct. Routing controls are switched deliberately, and safety rules block any change that would leave no Region serving traffic. Route 53 uses the control state in its health checks, and the change propagates within minutes.
Explanation
ARC routing controls give a deliberate switch, and their safety rules refuse any change that leaves no Region serving. Automatic health-check failover, hand-edited weights and manual dial changes each lack either the deliberate control or the safety rule.
A streaming service's checkout API runs behind an Application Load Balancer in each of two Regions. The load balancers answer health probes quickly even when the checkout service's downstream payment calls are failing, so customers see errors while the probes report healthy.
The team wants Route 53 to fail over when checkout actually fails, which means the health check must reflect the application's error rate. The health signal must not need custom code that the team has to maintain.
Which solution meets these requirements?
Choose one answer.
AA. Create a Route 53 health check on a CloudWatch alarm that watches the checkout error-rate metric, and attach that health check to the failover records for each Region.
BB. Point the health check at the load balancer's root path on HTTP, and have the path return a static 200 response from the load balancer's listener rule.
CC. Create a TCP health check on the load balancer's listener port, since a TCP connection succeeds whenever the listener is accepting traffic.
DD. Write a Lambda function on a schedule that calls the checkout service, counts the errors and calls the Route 53 API to change the records when the count is high.
Show the answer and explanation
Answer: A
A. Right: Correct. A health check based on a CloudWatch alarm follows the application's own error metric, so failover follows checkout failures and not just load balancer responses. No custom code is needed.
B. Wrong: A static response reports healthy even when the checkout calls fail, which repeats the problem in the question. The health check never sees the application error.
C. Wrong: A successful TCP connection says only that the listener accepts connections. It does not show that checkout is succeeding.
D. Wrong: The function works in principle, but the team would build and maintain the monitoring, the thresholds and the DNS changes. The requirement rules out that custom code.
Explanation
A Route 53 health check that reads a CloudWatch alarm on the checkout error rate reflects the application's real health without custom code. Static responses and TCP checks report healthy during the failures, and a custom function adds code the team must maintain.
Want more on Multi-Region failover (ARC, Route 53, Global Accelerator, multi-cluster containers)? The 5 full-length practice sets have 8 more Multi-Region failover (ARC, Route 53, Global Accelerator, multi-cluster containers) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Multi-Region failover (ARC, Route 53, Global Accelerator, multi-cluster containers)