A request to https://api.example.com/v1/health fails from one Linux host. Walk through how you would isolate whether name resolution, the path, the TCP port, TLS, or the HTTP application is at fault, and say what each step rules out.

## Why the order is the answer An interviewer asking this is not testing whether you know `curl`. They are testing whether you narrow a search space instead of guessing. Every layer depends on the one beneath it, so testing bottom-up means each success permanently removes suspects, and the first failure is the fault. Jumping straight to "the app is broken" when DNS is returning a decommissioned address wastes the outage. ## Step 1 — resolution: is there an address, and is it the right one? ```bash dig +short api.example.com ``` Three distinct outcomes. No output at all means no usable answer, and you are debugging naming, not the service. An address you do not recognise means you are about to test the wrong machine — chase the record, not the app. The expected address means resolution is clean and you can stop thinking about it. Carry that address forward explicitly for the rest of the drill so later steps cannot be confused by a different answer. ## Step 2 — the path: can packets get there at all? ```bash mtr -rwc 20 <addr> ``` This is advisory rather than decisive, because ICMP results are shaped by policy. Read the destination row, and treat loss at a middle hop as meaningful only if it persists through the later rows. A completely dead path is a strong signal; a clean one does not prove the port is reachable. Do not linger here — the port test is far more decisive. ## Step 3 — the port: does a TCP handshake complete? ```bash nc -zv <addr> 443 ``` This is the pivotal step. A completed handshake proves routing works in both directions, a firewall is permitting the port, and something is listening and accepting. Everything below the transport is now exonerated, and the fault must be in TLS or above. A failure means the opposite: stop looking at the application. The *way* it fails carries information too — an immediate rejection means you reached the host and nothing accepted, while a silent hang until timeout is the classic signature of a filtering rule that drops rather than rejects. Always pass a short timeout (`nc -w 3`) so a filtered port fails in seconds. On a stripped-down image without `nc`, `curl -v --max-time 3 telnet://<addr>:443` gives the same connect-only test. ## Step 4 — TLS and HTTP: let curl narrate the rest ```bash curl -v --max-time 5 https://api.example.com/v1/health ``` Verbose output walks the remaining layers in sequence: the address it chose, the TCP connect, the TLS handshake with the negotiated protocol and the certificate's subject and validity, then the request headers, the status line and the response headers. Wherever it stops is your layer. A certificate subject-name mismatch or an expired certificate is a TLS finding; a `502` or `503` is an application or upstream finding; a `404` means you reached the right server and asked for the wrong path. For latency rather than failure, replace the guesswork with measurement: ```bash curl -o /dev/null -s -w \ 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \ https://api.example.com/v1/health ``` Those fields split the elapsed time into resolution, handshake, TLS negotiation, server think-time and transfer. "It's slow" becomes "TLS takes 900 ms" or "time to first byte is 4 s" — an attributable number instead of an impression. ## Step 5 — is it me, or is it everyone? Re-run the same commands from a second host on a different network, and from the service's own machine against `127.0.0.1`. Three informative shapes emerge: works everywhere except here (local resolution, local firewall or egress policy), fails everywhere but works on localhost (the service is healthy and the path or the ingress filter is not), fails on localhost too (the application itself). This step converts a single data point into a boundary. ## Working the layers as a habit The same reasoning telescopes. If the 502 came from a proxy, the proxy's own upstream call is the next thing to run the drill against, one hop further in. What makes the answer strong is not the tool list but the discipline: name the layer you are testing, name what a pass rules out, and never skip a layer because you are confident about it.