How should I use these Route 53 Failover practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Route 53 Failover questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Route 53 Failover domain.

SAA-C03 · topic practice

Route 53 Failover practice questions

Practise SAA-C03 Route 53 Failover practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

11 questionsDomain: Route 53 Failover

Practice 10 questions Browse domain →

What the exam tests

What to know about Route 53 Failover

Route 53 Failover questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Route 53 Failover exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Route 53 Failover questions

11 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full DNS explanation →

A SaaS platform serves an API using two regional deployments: us-east-1 (primary) and us-west-2 (secondary). Each region has its own ALB. The business requires automated DNS-based failover when the primary region becomes unhealthy, and they do not want manual DNS changes during incidents.

Which Route 53 configuration is the best match?

Trap 1: Create a single Route 53 record using weighted routing across both…

Weighted routing does not automatically detect health conditions and shift traffic based on impairment without manual intervention.

Trap 2: Use latency-based routing so Route 53 always selects the fastest…

Latency-based routing selects based on performance, not health, and does not guarantee failover when the primary region is unhealthy.

Trap 3: Use a single A record with a static IP address that points to a NAT…

Static IPs and NAT gateways are not an appropriate mechanism for regional ALB failover, and updating during incidents is manual.

Study all Route 53 Failover common traps →

A
Create a single Route 53 record using weighted routing across both ALBs with weights adjusted manually during an incident.
Why wrong: Weighted routing does not automatically detect health conditions and shift traffic based on impairment without manual intervention.
B
Use Route 53 failover routing with a primary record pointing to the us-east-1 ALB and a secondary record pointing to the us-west-2 ALB, each using health checks.
Failover routing with health checks enables automatic switching of DNS responses when the primary endpoint fails health evaluation.
C
Use latency-based routing so Route 53 always selects the fastest region; health checks are unnecessary because client latency reflects availability.
Why wrong: Latency-based routing selects based on performance, not health, and does not guarantee failover when the primary region is unhealthy.
D
Use a single A record with a static IP address that points to a NAT gateway, and update that IP during failure events.
Why wrong: Static IPs and NAT gateways are not an appropriate mechanism for regional ALB failover, and updating during incidents is manual.

Full breakdown with real-world context →

Question 2easymultiple choice

Review the full routing breakdown →

An engineering team deploys a stateless web API on EC2 using an Auto Scaling group and an Application Load Balancer (ALB). During a recent test, they noticed that when one Availability Zone was unavailable, traffic failed until new instances were manually launched. Which change most directly improves automatic failover for the compute layer within a single Region?

Trap 1: Place the Auto Scaling group in only one subnet so instance…

Using only one subnet/AZ removes redundancy. An AZ outage would still take down capacity until manual action occurs.

Trap 2: Increase the target group deregistration delay to allow old…

Changing deregistration delay affects connection draining, not capacity placement across AZs. It doesn’t create additional resilient instances.

Trap 3: Use a Network Load Balancer, but keep all subnets in a single…

Switching load balancer type doesn’t fix the root cause. If capacity is only in one AZ, failures will still impact the service.

Study all Route 53 Failover common traps →

A
Place the Auto Scaling group in only one subnet so instance launches are simpler.
Why wrong: Using only one subnet/AZ removes redundancy. An AZ outage would still take down capacity until manual action occurs.
B
Ensure the ALB and Auto Scaling group span multiple subnets in at least two Availability Zones.
Spreading the ALB and Auto Scaling group across at least two AZs provides redundant capacity. If one AZ fails, the ALB continues routing to healthy targets in the other AZ.
C
Increase the target group deregistration delay to allow old instances to stay longer.
Why wrong: Changing deregistration delay affects connection draining, not capacity placement across AZs. It doesn’t create additional resilient instances.
D
Use a Network Load Balancer, but keep all subnets in a single Availability Zone.
Why wrong: Switching load balancer type doesn’t fix the root cause. If capacity is only in one AZ, failures will still impact the service.

Full breakdown with real-world context →

Question 3mediummulti select

Read the full DNS explanation →

A SaaS application is deployed in us-east-1 and us-west-2 behind separate ALBs. The business wants DNS to send new clients to the primary Region when it is healthy and automatically fail over to the secondary Region when the primary endpoint is unhealthy. Which two Route 53 settings are required? Select two.

Trap 1: Use weighted routing with a 50/50 traffic split between both…

Weighted routing distributes traffic, but it does not automatically fail over based on endpoint health.

Trap 2: Use latency-based routing so clients always choose the fastest…

Latency-based routing optimizes performance, but it is not the same as primary-secondary failover behavior.

Trap 3: Use a geolocation policy without health checks.

Geolocation routes by user location and still requires additional health-aware design for automatic failover.

Study all Route 53 Failover common traps →

A
Use a failover routing policy with a primary and secondary record.
Failover routing is designed specifically to send traffic to a secondary endpoint when the primary becomes unhealthy.
B
Create a health check and associate it with the primary endpoint.
Health checks give Route 53 the signal it needs to decide when the primary endpoint should stop receiving answers.
C
Use weighted routing with a 50/50 traffic split between both Regions.
Why wrong: Weighted routing distributes traffic, but it does not automatically fail over based on endpoint health.
D
Use latency-based routing so clients always choose the fastest Region.
Why wrong: Latency-based routing optimizes performance, but it is not the same as primary-secondary failover behavior.
E
Use a geolocation policy without health checks.
Why wrong: Geolocation routes by user location and still requires additional health-aware design for automatic failover.

Full breakdown with real-world context →

Question 4mediummultiple choice

Review the full routing breakdown →

Based on the exhibit, which Route 53 configuration should be used so traffic automatically returns to the secondary Region only when the primary Region becomes unhealthy?

Exhibit

DNS design notes:
  Primary Region: us-east-1
  Primary ALB: alb-prod-east-1.example.internal
  Secondary Region: us-west-2
  Secondary ALB: alb-prod-west-2.example.internal

Health check results:
  /health on us-east-1 returns HTTP 503
  /health on us-west-2 returns HTTP 200

Requirement:
  Clients should use the primary endpoint during normal operations and switch automatically only on primary failure

Trap 1: Use latency-based routing with both ALB records enabled.

Latency-based routing chooses the Region with the lowest latency, not a designated primary/secondary pair. It does not provide the explicit health-based failover behavior required here.

Trap 2: Use geolocation routing so users are always sent to the closest…

Geolocation routing is based on client location, not the health of the primary Region. It can still direct users to an unhealthy endpoint if that Region matches the location rule.

Trap 3: Use a CNAME record that points to both ALBs so DNS can round-robin…

A single DNS record cannot provide health-aware active failover to two targets in that manner. Round-robin behavior also does not guarantee that traffic will move away from a failed primary only when the primary becomes unhealthy.

Study all Route 53 Failover common traps →

A
Use latency-based routing with both ALB records enabled.
Why wrong: Latency-based routing chooses the Region with the lowest latency, not a designated primary/secondary pair. It does not provide the explicit health-based failover behavior required here.
B
Use failover routing with a primary alias record, a secondary alias record, and a Route 53 health check on the primary target.
Failover routing is designed for this pattern: Route 53 returns the primary alias while the primary endpoint is healthy, and switches to the secondary alias when the primary health check fails. Alias records integrate cleanly with ALB targets, and the health check provides the signal that drives the failover decision.
C
Use geolocation routing so users are always sent to the closest Region.
Why wrong: Geolocation routing is based on client location, not the health of the primary Region. It can still direct users to an unhealthy endpoint if that Region matches the location rule.
D
Use a CNAME record that points to both ALBs so DNS can round-robin between Regions.
Why wrong: A single DNS record cannot provide health-aware active failover to two targets in that manner. Round-robin behavior also does not guarantee that traffic will move away from a failed primary only when the primary becomes unhealthy.

Full breakdown with real-world context →

Question 5mediummulti select

Review the full routing breakdown →

A solutions architect is designing a highly available and resilient architecture for a critical internal application that processes financial transactions. The application runs on Amazon EC2 instances inside an Auto Scaling group. The database layer uses an Amazon Aurora MySQL cluster. The company requires that if an entire AWS Availability Zone (AZ) fails, the application must remain operational with minimal impact and automatically recover without manual intervention. Which combination of architectural decisions will meet these requirements? (Choose four.)

Trap 1: Deploy the Aurora cluster with a single DB instance to reduce…

Deploying an Aurora cluster with only a single DB instance, even if it's the primary writer, significantly compromises high availability. If that single instance or its underlying Availability Zone experiences an outage, the database will become unavailable, leading to application downtime. While it might reduce immediate cost, it fails to meet the requirement for a highly available and resilient architecture.

Trap 2: Place the EC2 instances in a single Availability Zone to ensure…

Placing all EC2 instances in a single Availability Zone creates a single point of failure, directly contradicting the goal of a highly available and resilient architecture. While it might offer marginal latency benefits for data locality, the risk of a complete application outage if that specific AZ experiences an issue far outweighs any perceived advantage. High availability mandates distribution across multiple AZs.

Study all Route 53 Failover common traps →

A
Configure the Auto Scaling group to span at least three Availability Zones in the same AWS Region.
This is a fundamental best practice for high availability and resilience. By distributing EC2 instances across at least three Availability Zones (AZs), the application can withstand an outage in a single AZ without experiencing downtime. Auto Scaling groups automatically launch new instances in healthy AZs if one fails, ensuring continuous application availability and fault tolerance.
B
Deploy the Aurora cluster with a single DB instance to reduce complexity and cost.
Why wrong: Deploying an Aurora cluster with only a single DB instance, even if it's the primary writer, significantly compromises high availability. If that single instance or its underlying Availability Zone experiences an outage, the database will become unavailable, leading to application downtime. While it might reduce immediate cost, it fails to meet the requirement for a highly available and resilient architecture.
C
Configure the Aurora cluster to include at least one Aurora Replica in a different Availability Zone than the primary instance.
This configuration is crucial for database resilience and high availability. An Aurora Replica in a different Availability Zone acts as a failover target, allowing Aurora to automatically promote the replica to primary in case of an outage affecting the original primary instance or its AZ. This multi-AZ deployment minimizes downtime and ensures continuous database operations.
D
Use an Application Load Balancer (ALB) to distribute traffic across EC2 instances in multiple Availability Zones.
An Application Load Balancer (ALB) is essential for distributing incoming application traffic efficiently and for enhancing resilience. By automatically routing requests to healthy EC2 instances across multiple Availability Zones, the ALB ensures that no single instance becomes a bottleneck and that the application remains available even if instances or an entire AZ fail. This provides fault tolerance and improves overall application responsiveness.
E
Place the EC2 instances in a single Availability Zone to ensure data locality with the primary database.
Why wrong: Placing all EC2 instances in a single Availability Zone creates a single point of failure, directly contradicting the goal of a highly available and resilient architecture. While it might offer marginal latency benefits for data locality, the risk of a complete application outage if that specific AZ experiences an issue far outweighs any perceived advantage. High availability mandates distribution across multiple AZs.
F
Set up an Amazon RDS Proxy to manage database connections and provide connection pooling for improved resilience.
Amazon RDS Proxy enhances application resilience by managing and pooling database connections, reducing the overhead on the database instance. In the event of a database failover, RDS Proxy automatically routes connections to the new primary instance, minimizing application disruption and transparently handling connection management. This improves fault tolerance and application stability during database events.

Full breakdown with real-world context →

Question 6easymultiple choice

Review the full routing breakdown →

A company runs the same public API in two regions (Region A and Region B), each fronted by an ALB. They want Route 53 to automatically route clients to the Region B API when Region A becomes unhealthy, with minimal configuration effort. Which Route 53 approach should they use?

Trap 1: Use a single Route 53 A record that points only to Region A’s ALB…

A single-record setup does not provide automatic failover and still requires manual changes during outages.

Trap 2: Use Route 53 latency-based routing with separate records for each…

Latency-based routing optimizes user proximity, but it does not automatically fail over based on health checks.

Trap 3: Use weighted routing and set the Region B weight to 0 to ensure it…

Weighted routing does not react to health status. Weight changes are not automatic failover responses.

Study all Route 53 Failover common traps →

A
Use a single Route 53 A record that points only to Region A’s ALB and manually update it after failures.
Why wrong: A single-record setup does not provide automatic failover and still requires manual changes during outages.
B
Use Route 53 latency-based routing with separate records for each region.
Why wrong: Latency-based routing optimizes user proximity, but it does not automatically fail over based on health checks.
C
Use Route 53 failover routing with health checks for each region’s endpoint.
Failover routing works with health checks to move traffic from a primary endpoint to a secondary endpoint when the primary becomes unhealthy.
D
Use weighted routing and set the Region B weight to 0 to ensure it is only used when needed.
Why wrong: Weighted routing does not react to health status. Weight changes are not automatic failover responses.

Full breakdown with real-world context →

Question 7mediummulti select

Review the full routing breakdown →

A company is designing a multi-Region disaster recovery (DR) strategy for a stateless web application running on Amazon EC2 instances behind an Application Load Balancer (ALB). The application uses an Amazon RDS for MySQL database as its data store. The architecture must provide rapid failover with the lowest possible Recovery Point Objective (RPO) and Recovery Time Objective (RTO). Which of the following design choices will help achieve these objectives? (Choose four.)

Trap 1: Set up Amazon RDS Multi-AZ deployment to enable automatic failover…

While Amazon RDS Multi-AZ deployments provide high availability and automatic failover within a single AWS Region, they do not protect against a regional disaster. If the entire primary AWS Region becomes unavailable, the Multi-AZ standby replica in a different Availability Zone within that same region would also be affected, failing to meet the multi-region disaster recovery requirement.

Trap 2: Use an Amazon RDS for MySQL single-AZ deployment in the primary…

A single-AZ RDS deployment lacks high availability within the primary region, making it vulnerable to AZ failures. Furthermore, relying on daily snapshots for multi-region disaster recovery results in a high Recovery Point Objective (RPO), meaning up to 24 hours of data could be lost. The manual restoration process from snapshots also leads to a high Recovery Time Objective (RTO), making this approach unsuitable for robust DR.

Study all Route 53 Failover common traps →

A
Configure an active-passive failover strategy by deploying the application stack in two AWS Regions and using Amazon Route 53 health checks with a failover routing policy.
This strategy establishes a primary active region and a secondary passive region, where the application stack is fully deployed but not actively serving traffic. Amazon Route 53 health checks continuously monitor the primary region's health. If a failure is detected, the failover routing policy automatically redirects traffic to the healthy secondary region, ensuring business continuity with minimal downtime.
B
Set up Amazon RDS Multi-AZ deployment to enable automatic failover to a standby replica in a different Availability Zone within the primary Region.
Why wrong: While Amazon RDS Multi-AZ deployments provide high availability and automatic failover within a single AWS Region, they do not protect against a regional disaster. If the entire primary AWS Region becomes unavailable, the Multi-AZ standby replica in a different Availability Zone within that same region would also be affected, failing to meet the multi-region disaster recovery requirement.
C
Use Amazon RDS cross-Region read replicas with automatic failover to promote a read replica to a primary instance in the secondary Region.
For stateful applications relying on databases, Amazon RDS cross-Region read replicas continuously replicate data from the primary database in one region to a read replica in a secondary region. In a disaster scenario, this read replica can be quickly promoted to a standalone primary instance, minimizing data loss and providing a fully functional database in the secondary region for recovery.
D
Deploy the application and ALB in an active-active configuration across two AWS Regions using Amazon Route 53 latency-based routing.
An active-active configuration involves deploying the full application stack in two or more AWS Regions, with both regions simultaneously serving traffic. Amazon Route 53 latency-based routing directs user requests to the region that provides the lowest network latency, effectively distributing the load and providing inherent disaster recovery as traffic automatically shifts away from an unhealthy region.
E
Store static assets and application state in Amazon S3 with cross-Region replication enabled, and serve them via Amazon CloudFront.
Storing static assets and application state in Amazon S3 with cross-Region replication ensures data durability and availability across multiple regions. Amazon CloudFront, a global content delivery network, can then serve these assets from the nearest edge location, improving performance and providing resilience by automatically pulling content from the healthy S3 bucket in either region during a disaster.
F
Use an Amazon RDS for MySQL single-AZ deployment in the primary Region and take daily snapshots copied to the secondary Region.
Why wrong: A single-AZ RDS deployment lacks high availability within the primary region, making it vulnerable to AZ failures. Furthermore, relying on daily snapshots for multi-region disaster recovery results in a high Recovery Point Objective (RPO), meaning up to 24 hours of data could be lost. The manual restoration process from snapshots also leads to a high Recovery Time Objective (RTO), making this approach unsuitable for robust DR.

Full breakdown with real-world context →

Question 8mediummulti select

Review the full routing breakdown →

A company is designing a disaster recovery plan for a critical application hosted on AWS. The application runs on EC2 instances with data stored in Amazon EBS volumes and Amazon S3. The recovery time objective (RTO) is 15 minutes, and the recovery point objective (RPO) is 1 hour. Which three strategies would help meet these objectives? (Choose three.)

Trap 1: Pre-provision EC2 instances in the disaster recovery region and…

Pre-provisioning and continuously running EC2 instances in a disaster recovery region represents a 'hot standby' strategy. While this approach offers the lowest possible Recovery Time Objective (RTO), it is significantly more expensive due to the ongoing operational costs of maintaining duplicate, fully scaled infrastructure 24/7. For many applications, a more cost-effective strategy like pilot light or warm standby can achieve acceptable RTOs without such high expenditure.

Trap 2: Store Amazon Machine Images (AMIs) in the source region and use AWS…

Storing Amazon Machine Images (AMIs) only in the source region and attempting to copy them via AWS Lambda *after* a disaster introduces significant delays, severely impacting the Recovery Time Objective (RTO). AMIs are region-specific, and for an effective disaster recovery strategy, pre-copying or regularly replicating AMIs to the DR region is essential. Relying on post-disaster replication would prolong recovery efforts unnecessarily.

Trap 3: Set up an AWS Direct Connect link between the primary and DR…

AWS Direct Connect establishes a dedicated, private network connection from an on-premises data center directly to AWS. It is designed for hybrid cloud architectures, not for inter-region connectivity *between* two AWS Regions. Data transfer and communication between different AWS Regions occur over the highly resilient AWS global network, often utilizing services like VPC peering or AWS Transit Gateway, making Direct Connect irrelevant for this specific inter-region DR scenario.

Study all Route 53 Failover common traps →

A
Use AWS Backup to create hourly snapshots of EBS volumes and copy them to a different AWS Region.
AWS Backup provides a centralized service to manage backups for various AWS resources, including EBS volumes. Creating hourly snapshots ensures a low Recovery Point Objective (RPO), minimizing potential data loss. Copying these snapshots to a different AWS Region is a fundamental strategy for disaster recovery, enabling the restoration of EBS volumes and associated EC2 instances in an alternate region should the primary region become unavailable.
B
Pre-provision EC2 instances in the disaster recovery region and keep them running 24/7.
Why wrong: Pre-provisioning and continuously running EC2 instances in a disaster recovery region represents a 'hot standby' strategy. While this approach offers the lowest possible Recovery Time Objective (RTO), it is significantly more expensive due to the ongoing operational costs of maintaining duplicate, fully scaled infrastructure 24/7. For many applications, a more cost-effective strategy like pilot light or warm standby can achieve acceptable RTOs without such high expenditure.
C
Replicate critical data to S3 in the disaster recovery region using S3 Cross-Region Replication (CRR).
S3 Cross-Region Replication (CRR) automatically and asynchronously replicates objects between specified S3 buckets in different AWS Regions. This ensures that critical application data stored in S3, such as user-generated content or application assets, is continuously available in the disaster recovery region. CRR is a highly effective and managed service for maintaining data durability and availability, crucial for rapid recovery during a regional outage.
D
Store Amazon Machine Images (AMIs) in the source region and use AWS Lambda to copy them after a disaster.
Why wrong: Storing Amazon Machine Images (AMIs) only in the source region and attempting to copy them via AWS Lambda *after* a disaster introduces significant delays, severely impacting the Recovery Time Objective (RTO). AMIs are region-specific, and for an effective disaster recovery strategy, pre-copying or regularly replicating AMIs to the DR region is essential. Relying on post-disaster replication would prolong recovery efforts unnecessarily.
E
Configure Amazon Route 53 with a failover routing policy and health checks to redirect traffic to the DR region.
Amazon Route 53's failover routing policy, combined with robust health checks, is a critical component for automated disaster recovery. It continuously monitors the health of resources in the primary region and, upon detecting a failure, automatically redirects DNS traffic to the healthy resources in the disaster recovery region. This mechanism ensures high availability and minimizes downtime by transparently directing users to the operational application endpoint.
F
Set up an AWS Direct Connect link between the primary and DR regions for faster data transfer.
Why wrong: AWS Direct Connect establishes a dedicated, private network connection from an on-premises data center directly to AWS. It is designed for hybrid cloud architectures, not for inter-region connectivity *between* two AWS Regions. Data transfer and communication between different AWS Regions occur over the highly resilient AWS global network, often utilizing services like VPC peering or AWS Transit Gateway, making Direct Connect irrelevant for this specific inter-region DR scenario.

Full breakdown with real-world context →

Question 9hardmulti select

Review the full routing breakdown →

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 team wants the control to be enforceable during normal operations.

Trap 1: S3 Transfer Acceleration

Transfer Acceleration improves upload paths to S3 but does not provide application failover.

Trap 2: AWS Organizations service control policies

SCPs enforce permissions and do not provide regional failover.

Study all Route 53 Failover common traps →

A
Route 53 failover routing with health checks
Route 53 can monitor endpoint health and return the standby endpoint when the primary is unhealthy.
B
S3 Transfer Acceleration
Why wrong: Transfer Acceleration improves upload paths to S3 but does not provide application failover.
C
A deployed standby application stack in the secondary Region
DNS failover requires a working target in the secondary Region.
D
AWS Organizations service control policies
Why wrong: SCPs enforce permissions and do not provide regional failover.

Full breakdown with real-world context →

Question 10mediummultiple choice

Review the full routing breakdown →

A fintech startup uses AWS to run a web API and a PostgreSQL database. They must meet an RPO of 15 minutes and an RTO of 2 hours for a Region-wide disaster. Budget allows running a small, always-on set of infrastructure in a secondary Region, but not full production capacity. The team wants a DR approach that is regularly testable without large manual effort.

Which disaster recovery strategy is the best fit?

Trap 1: Pilot light: replicate databases and store backups, keep only…

Pilot light can work for some RTO goals, but fully scaling dependencies within 2 hours may be difficult depending on application initialization and data warm-up.

Trap 2: Backup and restore only: rely on daily automated backups and…

Daily backups cannot meet a 15-minute RPO, and restoration time would likely exceed the 2-hour RTO.

Trap 3: Multi-site active-active: run both Regions at full capacity and…

Active-active typically costs more than allowed, and it adds complexity beyond what the budget and requirements describe.

Study all Route 53 Failover common traps →

A
Pilot light: replicate databases and store backups, keep only minimal infrastructure in the secondary Region, and scale up fully during failover.
Why wrong: Pilot light can work for some RTO goals, but fully scaling dependencies within 2 hours may be difficult depending on application initialization and data warm-up.
B
Warm standby: keep a scaled-down application environment and database replication active in the secondary Region, using automated failover controls.
Warm standby aligns with moderate RTO requirements by having ready-to-run resources plus continuous replication to meet the RPO target during failover.
C
Backup and restore only: rely on daily automated backups and restore into the secondary Region during an incident.
Why wrong: Daily backups cannot meet a 15-minute RPO, and restoration time would likely exceed the 2-hour RTO.
D
Multi-site active-active: run both Regions at full capacity and route live traffic to both simultaneously.
Why wrong: Active-active typically costs more than allowed, and it adds complexity beyond what the budget and requirements describe.

Full breakdown with real-world context →

Question 11hardmulti select

Review the full routing breakdown →

A regional web application for a content publishing system 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.

Trap 1: AWS Organizations service control policies

SCPs enforce permissions and do not provide regional failover.

Trap 2: S3 Transfer Acceleration

Transfer Acceleration improves upload paths to S3 but does not provide application failover.

Study all Route 53 Failover common traps →

A
AWS Organizations service control policies
Why wrong: SCPs enforce permissions and do not provide regional failover.
B
Route 53 failover routing with health checks
Route 53 can monitor endpoint health and return the standby endpoint when the primary is unhealthy.
C
S3 Transfer Acceleration
Why wrong: Transfer Acceleration improves upload paths to S3 but does not provide application failover.
D
A deployed standby application stack in the secondary Region
DNS failover requires a working target in the secondary Region.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Route 53 Failover sessions

Start a Route 53 Failover only practice session

Every question in these sessions is drawn from the Route 53 Failover domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Route 53 Failover questions →Mixed SAA-C03 session

Frequently asked questions

What does the SAA-C03 exam test about Route 53 Failover?: Route 53 Failover questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Route 53 Failover questions in a focused session?: Yes — the session launcher on this page draws every question from the Route 53 Failover domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other SAA-C03 topics?: Use the topic links above to move to related areas, or go back to the SAA-C03 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the SAA-C03 exam covers. They are not copied from any real exam or dump site.

Route 53 Failover only

10 questions 20 questions 30 questions 50 questions

Mixed SAA-C03 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All SAA-C03 questions Route 53 Failover domain overview SAA-C03 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Route 53 Failover practice questions

What to know about Route 53 Failover

Common Route 53 Failover exam traps

Route 53 Failover questions

Based on the exhibit, which Route 53 configuration should be used so traffic automatically returns to the secondary Region only when the primary Region becomes unhealthy?

Exhibit

A company runs the same public API in two regions (Region A and Region B), each fronted by an ALB. They want Route 53 to automatically route clients to the Region B API when Region A becomes unhealthy, with minimal configuration effort. Which Route 53 approach should they use?

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 team wants the control to be enforceable during normal operations.

A regional web application for a content publishing system 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.

Track your progress over time

Start a Route 53 Failover only practice session

Related SAA-C03 topic practice pages

Design Secure Architectures practice questions

Design Resilient Architectures practice questions

Design High-Performing Architectures practice questions

Design Cost-Optimized Architectures practice questions

SAA-C03 VPC practice questions

SAA-C03 S3 lifecycle policy questions

SAA-C03 RDS Multi-AZ questions

SAA-C03 IAM policy practice questions

SAA-C03 Route 53 failover questions

SAA-C03 CloudFront practice questions

SAA-C03 NAT gateway questions

SAA-C03 VPC endpoint questions

Frequently asked questions

Track your progress

Study resources

Exam traps to avoid