AWS Route 53 Interview Questions

An A record (Address record) is the standard DNS record type that maps a domain name to a 32-bit IPv4 address. The AAAA record maps a name to an IPv6 address, the CNAME record aliases one name to another name, and the MX record specifies mail exchange servers, so none of those three maps a domain to an IPv4 address.

Route 53 is named after port 53, the well-known port that DNS servers listen on for DNS queries over TCP and UDP. The name signals that the service is a DNS web service. The number is therefore a reference to the DNS port, not to a version, region, or count of anything.

The simple routing policy is the Route 53 policy for sending all traffic to a single resource when no special routing logic is needed. Weighted routing splits traffic by ratio, latency routing picks the lowest-latency endpoint, and failover routing sends traffic to a standby only when the primary fails, so none of those fit a single-resource requirement with no failover need.

Route 53 is classified as a global AWS service. Its hosted zones, DNS records, and routing policies are managed at the global level and are not bound to a single AWS Region, unlike services such as EC2 or RDS, which are regional. The statement is therefore true.

Latency-based routing is the Route 53 policy that uses measured latency between the user's network location and each AWS region or endpoint, then returns the lowest-latency option for each query. The question asks for the policy by name, so the answer is latency-based routing. Other policies such as geolocation or geoproximity route by geographic location rather than measured response time, and weighted or failover routing do not select by latency, so they do not meet the stated requirement.

Latency-based routing is the Route 53 policy designed for multi-region applications. Route 53 uses latency measurements between the user's DNS resolver location and each AWS region backing the records, then returns the endpoint of the lowest-latency region for that user. Geolocation routing selects the target by the user's country or continent rather than by measured latency. Weighted routing splits traffic according to configured proportions, and simple routing returns a single record (or randomly among several) without any latency awareness.

The statement is true. Route 53 Alias records are an AWS-specific extension that resolve to AWS resources such as an Application Load Balancer, CloudFront distribution, or S3 website endpoint, and they are permitted at the zone apex where the bare domain lives. A standard CNAME cannot be used at the apex because the apex must hold SOA and NS records, and DNS standards (RFC 1034) do not allow a CNAME to coexist with any other record type at the same name.

Geolocation routing returns records based on the geographic location of the query origin, and the location can be specified at continent, country, or US state granularity, which matches the requirement to return different IP addresses per continent. Latency-based routing selects the endpoint with the lowest measured latency, not the user's continent. Weighted routing distributes traffic across records according to assigned weights, independent of geography. Failover routing uses health checks to switch between a primary and secondary record, also independent of where the query comes from.

Per DNS standards (RFC 1034), a CNAME record cannot coexist with other records at the zone apex, so a root domain cannot be a CNAME. Route 53 Alias records are a special Amazon type that bypasses this restriction, allowing the apex domain to point to AWS resources like load balancers, CloudFront distributions, or S3 static website endpoints. Alias records also do not incur standard per-query charges when the target is an AWS resource. The core advantage for the apex scenario is that the Alias record works where a CNAME cannot.

With multi-value answer routing, Route 53 evaluates each record's associated health check before answering. A record whose health check is failing is excluded from the candidate set, so it is not returned in DNS responses. Route 53 then answers each query with up to eight records chosen at random from the healthy remainder. This is distinct from simple routing, which ignores health and returns every record, from latency-based routing, which picks a single lowest-latency record, and from a sequential round-robin, which rotates through records in order rather than choosing randomly.

Latency-based routing sends each user to the AWS region with the lowest measured network latency. Attaching health checks to both records means Route 53 only considers healthy endpoints when making latency-based decisions, so if one region's endpoint fails its health check, all users are routed to the remaining healthy region. Failover routing always sends traffic to the primary until it fails and ignores latency, so it misses the latency requirement. Weighted routing distributes traffic by configured weights rather than measured latency. Geolocation routing maps users by geographic origin rather than measured latency, so it does not guarantee the lowest-latency endpoint.

Latency routing answers with the AWS region that has the lowest measured latency between the user's resolver and that region, which satisfies the first requirement. Attaching a health check to each regional ALB record lets Route 53 stop returning a record whose endpoint is unhealthy, so users are sent to the other healthy region, which satisfies the second requirement. Failover routing sends all traffic to the primary until it fails and never considers latency. Weighted routing splits traffic by configured proportions without regard to latency. Geolocation routing chooses based on the user's geographic location rather than measured latency, so it cannot guarantee the lowest-latency region.

Route 53 health checkers run on their own schedule, independent of client DNS traffic, so probing the primary endpoint and recording failures happen before any query arrives. Once consecutive failed probes reach the configured failure threshold, the health check status changes to unhealthy. Only after that does a client's query arrive, and Route 53 then answers with the secondary record. A common misconception is that the DNS query triggers the health check evaluation; it does not, because the status is already determined when the query is answered.

Route 53 supports a proprietary record type called an alias record, which maps a name directly to an AWS resource such as an Application Load Balancer, CloudFront distribution, or S3 website endpoint. The DNS standard does not allow a CNAME at the zone apex because the apex must also carry SOA and NS records, and a CNAME cannot coexist with other records on the same name. An alias record avoids this restriction, so it is the correct way to route the apex to a load balancer.

Route 53 multivalue answer routing responds to each DNS query with up to eight records, chosen from the resource record sets that pass their health checks. The limit applies per response, so a client may see different subsets over time. Because the question asks for a single number, the answer is 8 (written as eight). The original arithmetic prompt (3 + 3 = 6) did not test any Route 53 concept, so it was replaced with this topic-relevant fact at the same difficulty.

Route 53 latency routing evaluates only endpoints whose health checks are currently passing. The us-east-1 endpoint is excluded because its health check is failing, even though it has the lowest measured latency (40 ms). Among the two remaining healthy endpoints, us-west-2 has the lower latency (60 ms versus 120 ms), so Route 53 returns the us-west-2 record.

An alias record with Evaluate Target Health set to Yes makes Route 53 check the health of the AWS resource the alias points to, in addition to any health check attached to the record. For an ALB, the alias is unhealthy when the load balancer has no healthy targets in its target group. So the record is returned only when the attached health check passes and the ALB has at least one healthy target; if either fails, the failover logic routes clients to the SECONDARY record.

Latency-based routing has no visibility into the end user's address unless the resolver forwards EDNS0 client subnet information. Without it, Route 53 uses the IP address of the querying resolver as its estimate of where the request originates. Here that resolver is in Singapore, so the decision is based on Singapore's location, and the healthy endpoint with the lowest latency for that location is returned. The user's physical presence in Mumbai does not influence the answer in this scenario. The statement about measuring live latency to each ALB at query time is wrong because Route 53 does not probe endpoints per query. The statement that returns all three addresses is wrong because latency routing answers each query with a single record, not a set for the client to choose from. The statement about ignoring location is wrong because latency routing is explicitly location-aware.

Route 53 weighted routing answers DNS queries only from records considered healthy. A record whose associated health check is failing is removed from the pool, and the remaining healthy records share traffic in proportion to their weights. After HP fails, the pool is Q (weight 30) and R (weight 20), so Q gets 30/50 = 60% and R gets 20/50 = 40%. R has no health check, so Route 53 always treats it as healthy. When HQ also fails, only R remains in the pool, so it receives 100% of responses.

When a failover record is an alias to an ALB with Evaluate Target Health enabled, Route 53 relies on the load balancer's aggregate health rather than inspecting each target group or target. The ALB still has healthy registered targets in the surviving target group, so it reports healthy to Route 53. The primary alias is therefore healthy and Route 53 continues to serve it, so no failover to the S3 alias occurs. Fixes include a custom health check against a specific path on the ALB with a higher failure threshold, or redesigning so the ALB's overall health reflects the failover condition.

Cross-account private hosted zone association is a two-step flow. The account that owns the hosted zone (Account A, 111111111111) must first call CreateVPCAssociationAuthorization, passing the hosted zone ID and the VPC's ID and region, to grant permission for that specific VPC. The account that owns the VPC (Account B, 222222222222) then calls AssociateVPCWithHostedZone with the same hosted zone ID, VPC ID (vpc-abc123), and VPC region (us-east-1) to complete the association. The authorization is a prerequisite: Account B cannot associate the VPC without it. After association, the Route 53 Resolver in the VPC answers internal.corp queries from the private hosted zone's records.

Route 53 evaluates geolocation records by specificity: country (or state, where applicable) first, then the enclosing continent, then the Default record. For a query from Japan, the country-level Japan record (192.0.2.10) matches first. Its health check is unhealthy, so Route 53 does not return it. Route 53 then moves to the next less-specific geolocation in the hierarchy, the Continent: Asia record (192.0.2.20). That record's health check is healthy, so Route 53 returns 192.0.2.20. The Default record (192.0.2.30) is only reached when no healthy record exists at the more specific levels. The common misconception this question targets is that Route 53 jumps straight from the unhealthy country match to the Default record; the lookup instead steps through the continent level first.

Evaluate Target Health makes Route 53 read the ALB's target health rather than probe the endpoint. Since at least one target (target-A) is healthy, the ALB counts as healthy and its IP addresses are returned in DNS. Route 53 returns the load balancer's IPs, not target IPs. The ALB then sends traffic only to target-A, because it routes requests to healthy targets using its own target group health checks. No quorum is needed, so a single healthy target is enough. The answer requires explaining both layers: the DNS-level health decision and the ALB's request-level routing.