Exercise 2: Diagnosing an Unreachable Web Server on Port 443 — Possible Solution
====================================================================

Following the chapter's own practical checklist (security group ->
NACL -> route table -> DNS), in order:

1. CHECK THE SECURITY GROUP'S INBOUND RULES on the web server
   instance. Confirm there's an inbound rule allowing TCP port 443
   from the source the request is coming from (e.g. 0.0.0.0/0 for
   public internet access). This rules out the single most common
   cause the chapter names -- "a misconfigured security group blocking
   the wrong port is very likely the single most common real-world
   networking support issue there is."

2. CHECK THE SUBNET'S NETWORK ACL, both inbound AND outbound rules for
   port 443 (and the ephemeral port range needed for the return
   traffic, since NACLs are stateless per Exercise 1). This rules out
   the exact "checked only one of the two" trap the chapter's
   warn-box specifically calls out -- a security group that correctly
   allows port 443 doesn't guarantee the subnet-level NACL does too.

3. CHECK THE ROUTE TABLE for the subnet the web server sits in, to
   confirm there's a route to an internet gateway. This rules out the
   web server actually sitting in what's effectively a private
   subnet (no internet gateway route) despite being assumed public --
   per the chapter, a public subnet is specifically DEFINED by having
   that internet gateway route, so its absence would explain
   unreachability regardless of security group/NACL configuration.

4. CHECK DNS RESOLUTION -- confirm the domain name being used to reach
   the server actually resolves to the correct IP address of this
   specific instance (and hasn't, for example, been left pointing at
   an old IP after a change, tying to this chapter's own TTL/DNS
   section). This rules out a DNS-level misdirection that would look
   identical to a real connectivity failure from the user's
   perspective, despite the network path itself being completely
   fine.

WHY THIS WORKS AS AN ANSWER
------------------------------
Each step in this order rules out one layer at a time, from the most
statistically likely cause (security group) down to the layer least
likely to be the culprit for a "used to work, suddenly doesn't"
scenario (DNS) -- exactly matching the chapter's own stated
troubleshooting order and its own reasoning for why that specific
sequence makes sense to check in that order.