SAA-C03 Design Resilient Architectures Practice Question

A regional web application for a inventory service must fail over automatically to a secondary Region if the primary endpoint becomes unhealthy. Which two services or features are required? The design must avoid adding custom operational scripts.

⚠ Common exam trap

Candidates often think a single service like Route 53 alone can handle failover, but without a pre-deployed standby application stack in the secondary Region, there is no infrastructure to route traffic to, making both Route 53 failover routing and the standby stack required together.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Route 53 failover routing with health checks

Route 53 failover routing with health checks (Option A) is required because it automatically evaluates the health of the primary endpoint and, upon detecting failure, updates DNS resolution to direct traffic to the secondary Region. This is the native AWS mechanism for DNS-based failover without custom scripts, relying on Route 53 health checkers to assess endpoint health via HTTP/HTTPS/TCP or calculated health checks.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Route 53 failover routing with health checks
Why this is correct
Route 53 failover routing with health checks is the control-plane mechanism that implements active-passive regional failover. You configure a primary record with a health check that probes the primary endpoint's HTTP or TCP status, and a secondary record pointing to the standby region; when the health check fails, Route 53 stops returning the primary and starts resolving to the standby. The health check must be created separately and attached to the primary record set, and low TTLs or alias records are recommended so DNS clients quickly pick up the failed-over answer.
✗
S3 Transfer Acceleration
Why it's wrong here
S3 Transfer Acceleration is a performance feature for uploading objects to Amazon S3: it routes your upload traffic through AWS edge locations over optimized, accelerated network paths to the destination bucket's regional endpoint. It does not monitor the health of an origin, reroute users to a different region, or make any DNS routing decision about your application endpoint. Because it only speeds data into the same S3 bucket, it has no role in failing over an inventory application from the primary to a secondary region.
✓
A deployed standby application stack in the secondary Region
Why this is correct
A pre-provisioned standby application stack in the secondary Region is a valid and necessary building block for disaster recovery, because DNS failover can only point users at an endpoint that is actually running and reachable. However, simply deploying that stack does not execute the failover; Route 53 health checks and failover routing are still required to detect the primary's failure and switch DNS resolution to the secondary stack. In practice, you would include Auto Scaling groups, databases, and load balancers in the standby stack so that it can receive production traffic the moment failover occurs.
✗
AWS Organizations service control policies
Why it's wrong here
Service control policies (SCPs) are authorization guardrails used with AWS Organizations to restrict which AWS services and actions principals in an OU or account can use; for example, you could deny certain resource-modifying actions to enforce security boundaries. They do not inspect endpoint health, evaluate HTTP responses, or perform DNS-based traffic management, and they cannot dynamically change DNS records to route users to a working region. Thus SCPs are entirely unrelated to availability or failover behavior.

Visual reference

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question