Route 53 Failover practice questions

A financial services company is hosting a critical web application on Amazon EC2 instances behind an Application Load Balancer. The application must remain available even if an entire AWS Region experiences a major outage. The database tier uses Amazon Aurora Global Databases. Which solution provides the most resilient multi-Region architecture with automated failover?

Trap 1: Configure an Application Load Balancer in a single Region with EC2…

A single Region architecture creates a single point of failure if the entire AWS Region suffers an outage. Standard Aurora databases lack cross-region replication capabilities required for high availability across geographical boundaries during catastrophic regional failures.

Trap 2: Use Amazon Route 53 with weighted routing policies to distribute…

Weighted routing does not perform automated health checks to reroute traffic away from a failed Region instantly. Hourly RDS snapshots introduce a high RPO and manual intervention is required to restore databases, which violates critical resiliency requirements.

Trap 3: Set up an AWS Global Accelerator standard accelerator with endpoint…

While AWS Global Accelerator and DynamoDB global tables offer high availability, the scenario specifies an Amazon Aurora relational database tier rather than DynamoDB, making this architecture incompatible with the existing relational database requirements of the application.

A
Configure an Application Load Balancer in a single Region with EC2 instances distributed across multiple Availability Zones, and back the application with a standard Aurora MySQL database instance.
Why it fails: A single Region architecture creates a single point of failure if the entire AWS Region suffers an outage. Standard Aurora databases lack cross-region replication capabilities required for high availability across geographical boundaries during catastrophic regional failures.
B
Use Amazon Route 53 with weighted routing policies to distribute traffic between two AWS Regions, and configure standard cross-region database replication using Amazon RDS snapshots taken every hour.
Why it fails: Weighted routing does not perform automated health checks to reroute traffic away from a failed Region instantly. Hourly RDS snapshots introduce a high RPO and manual intervention is required to restore databases, which violates critical resiliency requirements.
C
Deploy the application stack across two AWS Regions, use Amazon Route 53 with active-passive failover and automated health checks, and configure Amazon Aurora Global Databases with cross-region replication.
Route 53 active-passive routing with health checks automatically detects regional failures and redirects user traffic to the secondary Region. Aurora Global Databases provide low-latency cross-region replication and fast failover capabilities to ensure uninterrupted application availability.
D
Set up an AWS Global Accelerator standard accelerator with endpoint groups in two AWS Regions, and use Amazon DynamoDB global tables with local secondary indexes for data storage.
Why it fails: While AWS Global Accelerator and DynamoDB global tables offer high availability, the scenario specifies an Amazon Aurora relational database tier rather than DynamoDB, making this architecture incompatible with the existing relational database requirements of the application.

Question 2mediummultiple choice

An application is deployed across two AWS Regions to ensure resilience. The architect needs to direct users to the healthy region with the lowest latency. If the primary region fails, traffic should fail over automatically. Which Route 53 routing policy should be implemented?

Trap 1: Simple routing policy.

Simple routing is designed for a single resource that performs a specific function for your domain. It does not support health checks or complex logic like latency-based steering. Using simple routing would not allow the application to automatically fail over to a different region if the primary infrastructure becomes unavailable or performance degrades.

Trap 2: Failover routing policy.

Failover routing is used specifically for active-passive configurations where you want all traffic to go to a primary site and only switch to a secondary site if the primary fails. While it handles resilience, it does not account for user latency, which was a specific requirement for the global performance of the application.

Trap 3: Weighted routing policy.

Weighted routing distributes traffic across multiple resources in proportions that you specify. While it can be used for load balancing or blue/green deployments, it does not automatically route based on network latency. It would require manual adjustments or complex external automation to achieve the performance goals of directing users to the closest healthy region.

A
Simple routing policy.
Why it fails: Simple routing is designed for a single resource that performs a specific function for your domain. It does not support health checks or complex logic like latency-based steering. Using simple routing would not allow the application to automatically fail over to a different region if the primary infrastructure becomes unavailable or performance degrades.
B
Latency routing policy with health checks.
Latency routing optimizes the user experience by serving requests from the AWS Region that provides the lowest network latency. When combined with health checks, it provides both performance optimization and high availability. Route 53 monitors the health of the endpoints and automatically skips any region that fails health checks during the routing decision.
C
Failover routing policy.
Why it fails: Failover routing is used specifically for active-passive configurations where you want all traffic to go to a primary site and only switch to a secondary site if the primary fails. While it handles resilience, it does not account for user latency, which was a specific requirement for the global performance of the application.
D
Weighted routing policy.
Why it fails: Weighted routing distributes traffic across multiple resources in proportions that you specify. While it can be used for load balancing or blue/green deployments, it does not automatically route based on network latency. It would require manual adjustments or complex external automation to achieve the performance goals of directing users to the closest healthy region.

Question 3mediummultiple choice

A company hosts a web application on EC2 instances behind an Application Load Balancer. The application stores session state in local memory, causing users to be logged out whenever the load balancer routes requests to different instances. Which solution provides the most resilient, scalable architecture to resolve this?

Trap 1: Configure the Application Load Balancer to use source IP stickiness.

Source IP stickiness ties a client to a specific backend instance. If that instance fails or the Auto Scaling group terminates it, the session state is lost. This approach creates a dependency on individual instance health, violating the principle of designing stateless, resilient application tiers.

Trap 2: Use Amazon EBS multi-attach to share session files across instances.

EBS volumes can only be attached to instances within the same Availability Zone. If the AZ fails, the data becomes inaccessible, creating a single point of failure. Furthermore, file-based locking mechanisms are inefficient and prone to corruption in high-concurrency environments compared to dedicated caching services.

Trap 3: Replicate session files using a cron job across all web instances.

Replicating files via cron jobs introduces significant latency and synchronization challenges. As the number of instances grows, the overhead of maintaining consistency becomes unmanageable and error-prone. This design lacks the robustness and sub-millisecond performance required for modern, scalable, and resilient cloud-native web applications.

A
Configure the Application Load Balancer to use source IP stickiness.
Why it fails: Source IP stickiness ties a client to a specific backend instance. If that instance fails or the Auto Scaling group terminates it, the session state is lost. This approach creates a dependency on individual instance health, violating the principle of designing stateless, resilient application tiers.
B
Use Amazon EBS multi-attach to share session files across instances.
Why it fails: EBS volumes can only be attached to instances within the same Availability Zone. If the AZ fails, the data becomes inaccessible, creating a single point of failure. Furthermore, file-based locking mechanisms are inefficient and prone to corruption in high-concurrency environments compared to dedicated caching services.
C
Store session state in Amazon ElastiCache for Redis.
ElastiCache for Redis provides a high-performance, distributed, and managed key-value store that persists session data outside the web server memory. This ensures that session state remains available even when instances are replaced, enabling seamless horizontal scaling and maintaining high availability across multiple Availability Zones.
D
Replicate session files using a cron job across all web instances.
Why it fails: Replicating files via cron jobs introduces significant latency and synchronization challenges. As the number of instances grows, the overhead of maintaining consistency becomes unmanageable and error-prone. This design lacks the robustness and sub-millisecond performance required for modern, scalable, and resilient cloud-native web applications.

Read the full DNS explanation →

Question 4mediummultiple choice

An architect is designing a system that must be resilient against AWS regional failure. Which AWS service is best suited to manage global DNS traffic and provide health-based routing?

Trap 1: Elastic Load Balancing (ELB).

ELB operates at the regional level, distributing traffic across instances within a single region. It does not provide global DNS routing capabilities or the ability to fail over between AWS Regions. It is an essential component for high availability, but not for managing global traffic failover scenarios.

Trap 2: AWS Direct Connect.

Direct Connect establishes a dedicated network connection from an on-premises data center to AWS. It is a connectivity solution, not a DNS routing or traffic management service. While it can be part of a resilient hybrid architecture, it does not provide regional failover functionality for internet-facing applications.

Trap 3: Amazon CloudFront.

CloudFront is a Content Delivery Network (CDN) that caches content at edge locations to reduce latency. While it can route traffic to different origins, it is not a DNS service. Route 53 is required to manage the DNS-level failover for the origins themselves during a regional outage.

A
Elastic Load Balancing (ELB).
Why it fails: ELB operates at the regional level, distributing traffic across instances within a single region. It does not provide global DNS routing capabilities or the ability to fail over between AWS Regions. It is an essential component for high availability, but not for managing global traffic failover scenarios.
B
Amazon Route 53.
Route 53 is the primary tool for global traffic management. Its health checks continuously monitor the status of regional endpoints. If an endpoint fails, Route 53 can update DNS records to route traffic to healthy infrastructure in other regions, providing the necessary resilience against regional-wide service interruptions.
C
AWS Direct Connect.
Why it fails: Direct Connect establishes a dedicated network connection from an on-premises data center to AWS. It is a connectivity solution, not a DNS routing or traffic management service. While it can be part of a resilient hybrid architecture, it does not provide regional failover functionality for internet-facing applications.
D
Amazon CloudFront.
Why it fails: CloudFront is a Content Delivery Network (CDN) that caches content at edge locations to reduce latency. While it can route traffic to different origins, it is not a DNS service. Route 53 is required to manage the DNS-level failover for the origins themselves during a regional outage.

Question 5hardmulti select

An application uses a monolithic architecture on EC2 instances. The company wants to improve resilience against regional failures. Which TWO actions should the architect take to achieve this? (Select TWO.)

Trap 1: Deploy the application to multiple Availability Zones within a…

Multi-AZ deployment provides high availability against localized data center failures but does not protect against full regional outages. While it is a best practice for general availability, it fails to meet the specific requirement of regional resilience requested in the scenario.

Trap 2: Use an AWS Direct Connect connection to link the two regions.

Direct Connect is intended for private connectivity between an on-premises data center and AWS, not for replicating data between two AWS regions. While it provides consistent network performance, it does not solve the challenge of regional application failover or state synchronization between regions.

Trap 3: Increase the minimum number of EC2 instances in the Auto Scaling…

Increasing the instance count improves capacity and localized redundancy but does not mitigate risks associated with regional outages. If the entire region goes down, the increased instance count remains unreachable, failing to address the fundamental requirement of regional resilience and disaster recovery planning.

A
Deploy the application to multiple Availability Zones within a single region.
Why it fails: Multi-AZ deployment provides high availability against localized data center failures but does not protect against full regional outages. While it is a best practice for general availability, it fails to meet the specific requirement of regional resilience requested in the scenario.
B
Configure Amazon Route 53 with failover routing policies to a secondary region.
Route 53 failover routing policies monitor the health of primary region endpoints. If health checks fail, traffic is automatically routed to the secondary region. This is a foundational step in building a resilient multi-region architecture that provides automated business continuity during a regional disaster.
C
Implement Amazon Aurora Global Database for cross-region data replication.
Aurora Global Database enables fast, low-latency cross-region replication. This ensures that the secondary region has an up-to-date copy of the primary database. In the event of a regional failure, the global database can be promoted to provide full read-write capabilities in the failover region.
D
Use an AWS Direct Connect connection to link the two regions.
Why it fails: Direct Connect is intended for private connectivity between an on-premises data center and AWS, not for replicating data between two AWS regions. While it provides consistent network performance, it does not solve the challenge of regional application failover or state synchronization between regions.
E
Increase the minimum number of EC2 instances in the Auto Scaling group.
Why it fails: Increasing the instance count improves capacity and localized redundancy but does not mitigate risks associated with regional outages. If the entire region goes down, the increased instance count remains unreachable, failing to address the fundamental requirement of regional resilience and disaster recovery planning.