Networking Fundamentals

About these networking questions

This is a practice topic, not a vendor exam. The questions cover the networking every IT and cloud role assumes you already know: how packets find their way, how names become addresses, and why a connection that should work doesn't. They suit people preparing for a support, sysadmin, DevOps or cloud engineering interview, and anyone starting AWS, Azure or Google Cloud networking who keeps meeting terms like CIDR, TTL or "layer 4" without being sure what they mean.

The questions are vendor-neutral and built on the protocol standards themselves, the RFCs that define TCP, UDP, DNS, ARP and IP addressing. Several are short troubleshooting scenarios, because that is where networking knowledge earns its keep: a host has a strange address, a DNS change hasn't taken effect, or a machine is sending ARP requests for the wrong thing.

What the questions cover

There is one 10-question test so far. It covers:

• Network models and layers. Where common protocols sit in the TCP/IP model and how that maps to the OSI layers people still quote.
• Transport protocols. When to choose TCP or UDP, and what each step of the TCP three-way handshake does.
• DNS. Which record type routes mail for a domain, and how caching and TTL values explain why a DNS change takes time to reach everyone.
• IPv4 addressing and subnetting. Working out the usable host range of a /26, and recognising the private address ranges.
• Network services and troubleshooting. What a 169.254.x.x address tells you about DHCP, and why a host sends an ARP request for its default gateway rather than a remote server.
• Application protocols. What the main HTTP status code classes mean and when each is returned.

How to use them

• Do subnetting on paper. Converting a prefix length to a mask, a block size and a host range by hand is the only way it sticks, and interviews often ask for it without a calculator.
• For each question, ask which layer the problem lives at. Most networking faults are easier to reason about once you know whether it is addressing, transport or an application issue.
• Try the tools the questions mention. dig or nslookup shows TTLs counting down, ip neigh or arp -a shows the ARP cache, and a packet capture of one web request shows the whole handshake.
• Read the explanations for the wrong options too. Mixing up UDP and TCP guarantees, or thinking ARP crosses a router, are common errors worth fixing early.
• Come back to these before a cloud networking course. VPCs, subnets, route tables and private DNS are all built on exactly these ideas.

These questions are original, written from the public IETF RFCs and other open references. They are not taken from any exam or interview question bank.