Examkin

Question

Difficulty: HardRoute 53 Routing Policies and DNS Failover Strategies

A company runs a global API platform across three AWS Regions: us-east-1, eu-west-1, and ap-southeast-2. Each region has an Application Load Balancer (ALB) routing traffic to Amazon EC2 instances. To optimize performance, the company uses Amazon Route 53 Latency routing with 'Evaluate Target Health' enabled on the alias records. During a disaster recovery test, the database in us-east-1 is powered down. The EC2 instances in us-east-1 remain running but return HTTP 500 Internal Server Error to all API clients because they cannot access the database. However, Route 53 continues to route client traffic to the us-east-1 ALB. Which configuration change will resolve this issue and ensure that Route 53 fails over to the next closest region?

  1. A
    Change the Route 53 routing policy to Failover routing, as Latency routing policies do not support health checks or Evaluate Target Health for automatic failover.
  2. B
    Scale up the EC2 instances in the standby regions to match the primary region's capacity, as Route 53 will not failover to a Pilot Light environment until target capacity is verified.
  3. Configure the Application Load Balancer's target group health check to query a deep health check endpoint that validates database connectivity rather than a static resource.Answer
  4. D
    Promote the database read replica in the standby region to primary, as Route 53 failover requires the database replication state to be synchronized before updating DNS records.

Answer

Configure the Application Load Balancer's target group health check to query a deep health check endpoint that validates database connectivity rather than a static resource.
The correct answer is to configure the Application Load Balancer's target group health check to query a deep health check endpoint that validates database connectivity. When Route 53's Evaluate Target Health is enabled on an alias record pointing to an Application Load Balancer, Route 53 relies on the health status of the registered targets in the ALB's target groups. If the targets are configured to verify health using a static resource, they will continue to report as healthy even if the database is offline. By changing the health check path to a deep health check endpoint that verifies backend database connectivity, the targets will be marked unhealthy when the database fails, causing Route 53 to failover traffic to the next closest region.

Step-by-Step Solution

1
Analyze the relationship between Route 53 'Evaluate Target Health' and the Application Load Balancer (ALB).
Identify that Route 53 determines the health of the ALB based on the health checks of its target group instances.
To find why Route 53 failed to detect the outage, we must trace how Route 53 gets health state data.
2
Evaluate the impact of the database outage on the existing target group health check configuration.
Determine that the targets are returning healthy status because the health check is hitting a static resource, ignoring the database status.
This explains why the EC2 instances are marked healthy by the ALB despite returning HTTP 500 to clients.
3
Formulate the correction to the target group health check.
Point the health check path to a deep health check endpoint that verifies database connection.
When the database goes down, this deep endpoint will return an unhealthy status, causing the target group to mark targets unhealthy, which prompts Route 53 to route traffic to the next closest region.

Key Concept

Route 53 routing policies evaluate target health based on the configured health checks of the target endpoint. For Application Load Balancers, this health state depends directly on the ALB target group's health checks. If target groups query a shallow endpoint (e.g. static file), Route 53 will remain unaware of database-level outages.
Rate this question

Topics

Route 53 Routing Policies and DNS Failover Strategies

More questions from this topic