All jobs / DevOps / SRE / cloud

Networking interview questions

Networking questions a DevOps / SRE / cloud can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. A service is “down.” Where do you look first?

    The strongest answer: Whether the name resolves, whether I can reach the port, then the app — I do not start in the application logs if the packet never arrived

    Why it works: Exactly. DNS, reachability, then the app. Layer the investigation.

    • Resolve the name.
    • Reach the port.
    • Then read the app.
    • Do not reboot the world first.

  2. How many addresses are in a /24, and why do people say 254 hosts?

    The strongest answer: 256 — 32 minus 24 leaves 8 host bits, 2 to the 8th; the network and broadcast addresses are reserved on a classic subnet, and cloud providers reserve a few more per subnet

    Why it works: Exactly — host bits give the size, and the reserved addresses explain the smaller usable count. Knowing this is how you size subnets before you run out.

    • Prefix bits fixed; the rest are hosts.
    • /24 is 2 to the 8th, 256.
    • Network and broadcast are reserved.
    • Clouds reserve a few more per subnet.

  3. The load balancer is happy (HTTP 200). Half the requests 500. What might be true?

    The strongest answer: The health check hits a cheap path that does not use the database — I will make ready mean “can do the work”

    Why it works: Exactly. A cheap 200 lies. Ready must exercise what users need, or you accept the lie on purpose.

    • Health should touch the dependency you need.
    • Or name the lie.
    • Do not 200 your 500s.
    • Read user-error metrics too.

  4. “Connection refused” versus “connection timed out” — what does each tell you about where to look?

    The strongest answer: Refused means the host answered and nothing listens on that port, so I check the service and `ss -ltnp` there; timed out means no answer at all — firewall, security group, route or wrong host

    Why it works: Right — a refusal is a reply, so the network path works; a timeout is silence, so start with what drops packets.

    • Refused is a reply; timeout is silence.
    • Refused: check the listener.
    • Timeout: check firewall and route.
    • Never widen firewalls to debug.

  5. Where do you put a database in a cloud VPC?

    The strongest answer: In a private subnet, no public IP, reachable from the app tier — I do not give it a 0.0.0.0/0 security group “so we can admin from home”

    Why it works: Exactly. Private, tight SG, a real admin path (SSO / bastion / IAP). Home-open is the incident.

    • Private subnet.
    • No public IP on the DB.
    • Tight security groups.
    • Admin via identity, not 0.0.0.0/0.

  6. You renewed the certificate. Browsers are happy, but curl and the Java client fail with “unable to get local issuer certificate”.

    What is wrong?

    The strongest answer: The server sends only the leaf certificate, not the intermediate chain; browsers fetch or cache intermediates, strict clients do not. Serve the full chain and verify with `openssl s_client -showcerts`

    Why it works: Exactly — a leaf without its intermediates is an incomplete chain. Browsers hide the mistake; libraries expose it.

    • Serve leaf plus intermediates.
    • Browsers forgive; libraries do not.
    • Check with openssl s_client.
    • Never disable verification.

  7. A security group allows 0.0.0.0/0 on 5432 “temporarily.” What do you do?

    The strongest answer: Close it now, assume scans already happened, and put a ticket on how it was applied — temporary is how these live for years

    Why it works: Exactly. Close, assume scan, fix the path that applied it. A high port is not a lock.

    • Close 0.0.0.0/0 on data ports.
    • Assume it was scanned.
    • Fix the IaC that opened it.
    • Do not hide behind a password or a weird port.

  8. Your company acquires another. Both estates use 10.0.0.0/8 heavily and leadership wants the networks joined by VPN next month.

    What do you decide, and what do you refuse to do?

    The strongest answer: I refuse to route overlapping ranges — traffic black-holes. Short term, NAT between the estates for the flows that matter; long term, a company IP plan with non-overlapping blocks and a renumbering roadmap

    Why it works: Right — overlap is a planning problem, not a VPN setting. Bridge with NAT, then fix the address plan for good.

    • Overlap cannot be routed.
    • NAT as the bridge.
    • Write the company IP plan.
    • Renumber on a roadmap.