50 real networking interview questions with detailed answers on OSI/TCP-IP, subnetting, DNS, VLANs, routing and troubleshooting — by difficulty.
The OSI model has seven layers, each responsible for one job in getting data from an application on one machine to an application on another: Physical (raw bits on the wire or radio), Data Link (framing and addressing on the local segment, e.g. Ethernet and MAC addresses), Network (routing between segments, e.g. IP), Transport (end-to-end delivery, e.g. TCP/UDP), Session (managing a conversation between two endpoints), Presentation (formatting/encoding, e.g. TLS, compression), and Application (the protocol the user-facing software actually speaks, e.g. HTTP, DNS).
It's a mental model more than a literal description of every real stack — TCP/IP compresses several of these into fewer layers in practice. Interviewers ask this because it gives you shared vocabulary for talking about where a problem lives: "that's a Layer 2 issue" narrows the search a lot faster than "the network is broken."
Reference: Cloudflare: What is the OSI Model?
A hub repeats every incoming signal out of every other port with no intelligence at all — it's a Layer 1 device and effectively one big collision domain. A switch operates at Layer 2, learns which MAC address lives on which port, and forwards frames only to the port that needs them, which is why switches largely replaced hubs. A router works at Layer 3, forwarding packets between different networks based on IP address, and is what lets your home network talk to the internet.
The short version an interviewer wants to hear: hub = dumb repeater, switch = smart within one network, router = connects separate networks together.
It's the sequence that establishes a reliable TCP connection before any application data flows: the client sends a SYN (synchronize) packet with an initial sequence number; the server replies with SYN-ACK, acknowledging the client's sequence number and sending its own; the client replies with a final ACK, acknowledging the server's sequence number. After that, both sides know the connection is open and agree on starting sequence numbers, so lost or out-of-order segments can be detected and retransmitted.
This matters in interviews because handshake behavior explains real symptoms — a SYN flood attack works by sending many SYNs and never completing the handshake, exhausting the server's half-open connection table, and a connection that hangs at SYN_SENT usually means a firewall is silently dropping the return traffic rather than actively refusing it.
A subnet mask marks which bits of an IP address identify the network and which bits identify the specific host on that network. /24 is CIDR (Classless Inter-Domain Routing) shorthand meaning the first 24 bits are the network portion — equivalent to a mask of 255.255.255.0 — leaving the last 8 bits (256 addresses, 254 usable after subtracting network and broadcast) for hosts.
Understanding this is what lets you answer "is this device on the same network as me" just by looking at an IP and a prefix, which is the single most common everyday networking calculation.
NAT (Network Address Translation) rewrites the source IP address of outbound packets so many devices on a private network can share a single public IP address, and rewrites it back on the way in so replies reach the right internal device. Your router keeps a translation table mapping each internal device's connection to a port on the shared public IP.
It exists mainly because IPv4 addresses ran out — there aren't enough public addresses for every device on earth to have its own, so NAT lets a household or office hide dozens of devices behind one. A useful side effect is that NAT also makes it harder for something outside your network to directly reach a device inside it, though NAT was never designed as a security feature and shouldn't be relied on as one.
Reference: RFC 3022 — Traditional IP Network Address Translator
A public IP address is globally unique and routable across the internet — no two devices on the public internet can have the same one at the same time. A private IP address comes from reserved ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) that are only meaningful inside a local network; routers on the public internet won't forward traffic to or from them at all.
That's exactly why NAT exists: private addresses can be reused in millions of different homes and offices simultaneously precisely because they're never directly exposed to the internet.
Reference: RFC 1918 — Address Allocation for Private Internets
An A record points a domain name directly at an IPv4 address (an AAAA record does the same for IPv6). A CNAME record points a domain name at another domain name instead of an IP, useful for aliasing (e.g. pointing www.example.com at example.com). An MX record specifies which mail server is responsible for receiving email for a domain, along with a priority for failover between multiple servers.
A common gotcha worth knowing: a domain can't have a CNAME and any other record type (like MX) at the same name, because a CNAME says "this name is just an alias, go look everywhere else at the target instead" — mixing them creates an ambiguous, invalid configuration.
ARP (Address Resolution Protocol) maps an IP address to the MAC address of the device that owns it on the local network segment. IP operates at Layer 3 and MAC addresses operate at Layer 2, but a frame ultimately has to be delivered using a MAC address — ARP is the glue that lets a device say "I know the IP I want to reach, but what physical address do I actually send this frame to?"
It works by broadcasting an ARP request ("who has this IP?") to the whole local segment; the device that owns that IP replies directly with its MAC address, and the requester caches that mapping for a while to avoid repeating the broadcast for every packet.
Reference: RFC 826 — Address Resolution Protocol
The default gateway is the router a device sends traffic to when the destination isn't on its own local network — it's the "door out" of the local segment. Every device with an IP configuration typically has one set (often via DHCP).
If it's wrong or missing, the device can still talk to other devices on its own subnet just fine, but anything outside the subnet — including the internet — becomes unreachable, because the device has no idea where to forward traffic that isn't local. This is a classic first thing to check when "I can reach my coworker's PC but nothing else works."
Latency is how long it takes a single piece of data to travel from source to destination — usually measured in milliseconds via round-trip time. Bandwidth is how much data can be transferred per unit of time — the size of the pipe, not the speed of any one drop through it.
They're independent: you can have a high-bandwidth connection with terrible latency (a satellite link can transfer a lot of data per second but each individual packet takes a long physical round trip), and a low-bandwidth connection with great latency (a local, uncongested link). Real-time applications like video calls or competitive gaming care much more about latency than raw bandwidth, which is why "just upgrade your internet speed" doesn't always fix a laggy call.
ping tests basic reachability and round-trip time to a host using ICMP echo requests — it's the first thing to check "can I even reach this at all." traceroute (or tracert on Windows) shows the path packets take hop by hop, by sending packets with incrementing TTL values and recording which router replies at each hop — useful for finding where along a path a problem is happening, not just whether one exists. nslookup and dig query DNS directly, letting you see exactly what record a domain resolves to and from which server, which is essential when the symptom might be a DNS problem rather than a routing problem.
A practical troubleshooting order: ping to confirm reachability, dig/nslookup to rule out DNS, traceroute to localize where in the path a failure or slowdown is happening.
A DoS (Denial of Service) attack tries to make a service unavailable to legitimate users by overwhelming it — typically from a single source. A DDoS (Distributed Denial of Service) attack does the same thing but from many sources at once, often a large botnet of compromised devices, which makes it both far more powerful and much harder to defend against by simply blocking one offending IP address.
Common flavors include volumetric attacks (simply flooding a target with more traffic than its link can handle), protocol attacks (exploiting weaknesses in how a protocol handles state, like SYN floods exhausting a server's half-open connection table), and application-layer attacks (sending seemingly legitimate but expensive requests, like repeated searches against a database, to exhaust backend resources rather than bandwidth).
Port forwarding configures a router to send incoming traffic on a specific external port to a specific internal device and port, essentially punching a deliberate hole through NAT for a service that needs to be reachable from outside the local network. Without it, NAT's normal behavior means unsolicited inbound connections from the internet have no internal device to land on and are simply dropped.
A legitimate everyday reason is hosting something on your home network that outside users need to reach directly — a self-hosted game server, a home security camera's web interface, or a personal media server. The trade-off to mention: every forwarded port is a deliberate exception to NAT's incidental "nothing gets in uninvited" behavior, so it should be scoped as narrowly as possible (specific port, specific device) rather than opened broadly.
A MAC address is a 48-bit hardware address burned into a network interface at manufacture time, used for Layer 2 addressing on a local segment — the first half typically identifies the manufacturer (the OUI), and the second half is unique to that specific device. Unlike an IP address, it isn't meant to change based on what network you plug into.
Devices can legitimately share one in a few specific cases: virtual machines and containers are commonly assigned virtual MAC addresses that don't correspond to real hardware, and some setups deliberately "spoof" a MAC address for privacy or to work around a network policy tied to a specific address. High-availability setups like HSRP/VRRP also use a shared virtual MAC for a redundant gateway pair, so failover is seamless to devices on the segment. Outside of these deliberate cases, two devices with the same MAC on the same segment is a misconfiguration that causes real, hard-to-diagnose connectivity problems, since switches can't reliably tell which port actually owns that address.
Unicast is one-to-one traffic — a single sender to a single specific recipient, which covers the vast majority of everyday traffic like loading a webpage. Broadcast is one-to-all — a single sender to every device on the local broadcast domain, whether they want the data or not; DHCP discovery and ARP requests rely on this. Multicast is one-to-many, but only to devices that have explicitly subscribed to receive that traffic (a multicast group), rather than everyone on the segment.
Multicast is the one candidates most often can't place a real use case for: it shows up in things like IPTV distribution, stock ticker feeds, and some video conferencing and routing protocol traffic (OSPF uses multicast to talk to neighboring routers), where the same stream needs to reach many interested recipients without needlessly duplicating it as many separate unicast streams or blasting it at everyone as a broadcast.
TCP/IP is the model the real internet actually runs on; OSI is a more granular teaching and troubleshooting reference. TCP/IP has four layers — Link, Internet, Transport, Application — and it folds OSI's Physical and Data Link into one Link layer, and folds Session, Presentation, and Application into one Application layer.
The practical difference shows up in how people talk: nobody deploys a "session layer," but everybody deploys IP, TCP, and HTTP, which are TCP/IP-model concepts. Interviewers use this question to check that you know the seven-layer OSI model is a reference framework, not a literal implementation — someone who insists real traffic "passes through the session layer" as a distinct running process is showing they've memorized the diagram without understanding what it represents.
Reference: RFC 1122 — Requirements for Internet Hosts
TCP is connection-oriented: it does the three-way handshake, guarantees delivery through acknowledgments and retransmission, and keeps data in order — at the cost of extra overhead and latency. UDP is connectionless: it fires packets ('datagrams') with no handshake, no guaranteed delivery, and no ordering, which makes it faster and lighter but leaves reliability to the application if it needs any at all.
You choose UDP when a late packet is worse than a lost one. Live video calls, VoIP, and online games use UDP because retransmitting a dropped audio frame half a second late is pointless — you'd rather skip it and stay in real time. DNS also defaults to UDP for its speed on small, single-round-trip queries (falling back to TCP for large responses). The trap here is candidates saying "UDP is just worse TCP" — it isn't worse, it's a different trade-off, and picking the wrong one for the workload is the actual mistake to avoid.
Reference: RFC 768 — User Datagram Protocol
/26 leaves 6 bits for hosts (32 - 26 = 6), giving 2^6 = 64 total addresses. Subtract 2 for the network address (192.168.10.0) and the broadcast address (192.168.10.63), leaving 62 usable host addresses, from 192.168.10.1 through 192.168.10.62.
This is a bread-and-butter subnetting calculation, and interviewers ask it live specifically because it's easy to fake competence on paper but hard to fake on the spot. The trap is forgetting to subtract the two reserved addresses — someone who answers "64" instead of "62" is telling you they know the formula for total addresses but haven't internalized why two of them aren't assignable to hosts.
DNS is the system that translates human-readable domain names into IP addresses. A recursive resolver is the service your device actually queries (like your ISP's DNS or a public resolver such as 1.1.1.1 or 8.8.8.8); its job is to do all the legwork of finding the answer on your behalf. An authoritative nameserver is the source of truth for a specific domain — it's the server that actually holds the DNS records for, say, example.com, and only answers questions about zones it's responsible for.
When your resolver doesn't have an answer cached, it walks the hierarchy: it asks a root server which server is authoritative for .com, asks that TLD server which server is authoritative for example.com, then finally asks that authoritative server for the actual record. The distinction matters operationally — if a website is unreachable, checking whether it's a caching/resolver problem versus the domain's actual authoritative records being wrong points you to a completely different fix.
Reference: Cloudflare: What is DNS?
DHCP (Dynamic Host Configuration Protocol) automatically assigns IP addresses and network configuration (subnet mask, gateway, DNS servers) to devices joining a network, so nobody has to configure addresses by hand. The exchange is commonly remembered as DORA:
Interviewers like this question because it tests whether you understand why it's a four-step broadcast exchange rather than a simple request/response — the broadcasts exist because the client doesn't have an IP yet and might be choosing between multiple competing DHCP servers.
A 169.254.x.x address is APIPA (Automatic Private IP Addressing) — it means the device failed to get a real address from DHCP and self-assigned a fallback address, which only works for talking to other devices on the exact same local segment and has no route out to the internet at all.
The root cause is almost always that the DHCP server is unreachable: it could be down, the client's cable/Wi-Fi link is actually broken at a lower layer, a VLAN or switchport misconfiguration is blocking DHCP broadcasts from reaching the server, or (on a larger network) DHCP relay/IP helper isn't forwarding broadcasts across subnet boundaries. The fix is to chase the DHCP path rather than assume something is wrong with the destination site the user was trying to reach — the trap here is treating this as an application or DNS problem when the device never got past Layer 3 configuration in the first place.
A VLAN (Virtual LAN) logically segments a single physical switch (or set of switches) into multiple separate broadcast domains, as if they were separate physical networks, using tags on each frame (802.1Q) to identify which VLAN it belongs to. Devices in different VLANs can't talk to each other directly at Layer 2 even if they're plugged into the same switch — they need a router or Layer 3 switch to route between VLANs.
The reason to use VLANs instead of physical separation is cost, flexibility, and containment. You get to group, say, finance workstations, guest Wi-Fi, and VoIP phones into isolated segments on shared hardware, and you can move a device between logical networks with a config change instead of running new cable. It also shrinks each broadcast domain, which limits how far broadcast traffic (and broadcast storms) can spread, and it lets you apply different security policies per VLAN without touching the physical topology at all.
Reference: IEEE 802.1Q
ARP spoofing (or ARP poisoning) is when an attacker sends forged ARP replies claiming their own MAC address belongs to another device's IP — commonly the gateway's IP — so other devices on the segment start sending traffic meant for the real gateway to the attacker instead. Because ARP has no built-in authentication, any device on the same broadcast domain can simply lie.
It's dangerous because it enables man-in-the-middle attacks: once traffic is routed through the attacker, they can read, log, or modify it before forwarding it on (or not forwarding it at all, for a denial of service). Defenses include Dynamic ARP Inspection on managed switches, static ARP entries for critical devices, and network segmentation that limits how large a single broadcast domain — and therefore the blast radius of one poisoned ARP table — can get.
STP prevents Layer 2 loops in a switched network that has redundant physical links. Redundant links are good for reliability, but without something managing them, a loop at Layer 2 causes a broadcast storm — frames circulate endlessly and get duplicated at every hop, since Ethernet frames have no TTL the way IP packets do, quickly saturating the network and taking it down.
STP solves this by having switches elect a root bridge and then calculate the shortest path from every other switch to that root, putting any port that would create a loop into a blocking state (it doesn't forward traffic but keeps listening). If an active link fails, STP recalculates and brings a previously blocked port into a forwarding state to restore connectivity. The trade-off interviewers want you to name is convergence time — classic STP can take 30-50 seconds to react to a topology change, which is why faster variants like Rapid STP (802.1w) are used in practice.
Reference: IEEE 802.1D
A forward proxy sits in front of clients and makes requests on their behalf — the server on the other end sees the proxy, not the original client. It's used for things like content filtering, caching, or letting clients on a private network reach the internet through one controlled exit point.
A reverse proxy sits in front of servers and receives requests on their behalf — the client sees the proxy, not the actual backend server. It's used for load balancing across multiple backend servers, TLS termination, caching responses, and hiding internal infrastructure details. The direction of "who is it hiding" is the whole distinction: forward proxies hide/represent the client, reverse proxies hide/represent the server. Nginx and HAProxy are common reverse proxy examples; Squid is a common forward proxy example.
Reference: Cloudflare: Reverse proxy vs. forward proxy
A firewall controls what traffic is allowed to pass based on a set of rules, typically matching on things like source/destination IP, port, and protocol. A stateless firewall evaluates every packet independently against the rule set, with no memory of prior packets — you have to explicitly write rules for both directions of a conversation, since the firewall doesn't know a given inbound packet is a reply to something you sent out.
A stateful firewall tracks active connections and automatically allows return traffic that belongs to a connection it already approved, without needing a separate rule for it. This is both more convenient and more secure by default — an attacker can't just craft a packet with the right port numbers to sneak past a stateful firewall, because it has to actually belong to a tracked connection. Almost all modern firewalls, including the one built into most consumer routers, are stateful.
A VPN (Virtual Private Network) creates an encrypted tunnel between your device and a VPN server, so traffic between the two is unreadable to anyone observing the network in between — like a coffee shop Wi-Fi network or your ISP. Once traffic reaches the VPN server, it's decrypted and sent on to its real destination as if it originated from the VPN server's location.
The privacy benefit is specifically about that middle hop: it hides your traffic content and your real IP address from anyone between you and the VPN provider, and it hides your browsing destinations from your local network/ISP. It does not make you anonymous to the VPN provider itself, which can see everything your ISP normally would — so "a VPN makes you anonymous online" is a common overstatement worth correcting in an answer. Common protocols underneath include IPsec, OpenVPN, and WireGuard.
IPv4 uses 32-bit addresses, giving about 4.3 billion possible addresses — a number the internet has already outgrown, which is the whole reason NAT became so widespread. IPv6 uses 128-bit addresses, an effectively inexhaustible space, and also simplifies header processing, has built-in support for auto-configuration, and drops NAT as a requirement since every device can get its own globally unique address again.
Adoption has been slow mainly because IPv4 and IPv6 aren't directly interoperable — a pure IPv6 host can't natively talk to a pure IPv4 host — so the transition requires dual-stack support (running both simultaneously) or translation mechanisms, and there was never a single moment forcing a hard cutover since NAT let IPv4 keep limping along far longer than anyone originally expected. Most networks today run dual-stack rather than a clean IPv6-only setup.
Reference: RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification
QoS is a set of techniques for prioritizing certain types of traffic over others when a link is congested, rather than treating every packet identically on a first-come-first-served basis. It typically works by classifying traffic (e.g. by port, protocol, or DSCP tag) and then applying queuing and scheduling policies that give higher-priority traffic preferential treatment — more bandwidth, lower latency, or both — during contention.
You need it specifically when a link doesn't have enough headroom for everything at once and some traffic is more latency-sensitive than others — the textbook example is prioritizing VoIP or video conferencing traffic over a large file download, so someone's call doesn't stutter every time a coworker starts a backup job. On a link that's rarely saturated, QoS has nothing to do — it's a congestion management tool, not a general performance booster, and the common wrong answer is treating it as something that speeds up a network rather than something that decides who gets priority when the network is already busy.
A static route is manually configured by an administrator and never changes unless someone edits it — the router has no awareness of whether that path is actually still good. A dynamic routing protocol (like OSPF, EIGRP, or BGP) lets routers automatically discover the network topology, exchange reachability information with neighbors, and recalculate paths when something changes, without human intervention.
Static routing is deliberately chosen in small or simple topologies — a branch office with a single internet connection, for instance — where there's genuinely only one path anyway, and the predictability and lack of protocol overhead outweighs the convenience of automatic failover. It's also common as a default route pointing "everything else goes this way" alongside dynamic routing for known internal networks. The trap in this question is candidates assuming dynamic is always strictly better — it adds real complexity and attack surface (a misconfigured or compromised router can inject bad routes) that isn't worth it when the topology genuinely never changes.
BGP (Border Gateway Protocol) is the routing protocol that exchanges reachability information between autonomous systems (ASes) — the large networks run by ISPs, cloud providers, and big organizations — rather than within a single network. It's what lets a packet find its way from your ISP across potentially a dozen different independently-operated networks to reach, say, a server on the other side of the world.
It's called "the protocol that runs the internet" because that inter-AS path-finding is genuinely how the global internet's routing actually works — there's no single central authority computing every path; each AS advertises which address ranges (prefixes) it can reach and picks routes based on policies it controls, largely business relationships between networks rather than pure shortest-path math. This is also why BGP misconfigurations (a network accidentally advertising routes it shouldn't) can cause visible, sometimes global internet outages — a famous category of real-world incident is exactly this.
Reference: Cloudflare: What is BGP?
A broadcast domain is the set of devices that will all receive a broadcast frame sent by any one of them — routers stop broadcasts from crossing into another network, but switches forward them everywhere within the same Layer 2 network (or VLAN). A collision domain is the set of devices that could have their transmissions collide with each other on a shared medium — this was a big deal with hubs, where every device shared one collision domain, but switches give each port its own collision domain since each link is now point-to-point and full-duplex.
The short version: switches eliminated the collision domain problem almost entirely, but every device still shares a broadcast domain unless it's segmented by VLANs or separated by a router — which is exactly why VLANs and broadcast domain size are still a live design concern even on fully switched, collision-free modern networks.
Symmetric encryption uses one shared key for both encrypting and decrypting data — it's fast, but both sides need to already have that same secret key, which raises the question of how you got it to them securely in the first place. Asymmetric encryption uses a key pair — a public key anyone can use to encrypt, and a private key only the owner has to decrypt — which solves the key-distribution problem but is computationally much slower.
In practice, TLS (what secures HTTPS) uses both together: an asymmetric handshake at the start to safely agree on a shared secret without ever transmitting it in the clear, and then fast symmetric encryption for the actual bulk data transfer for the rest of the session. Knowing this hybrid approach is usually what separates a surface-level answer from one that shows real understanding of how HTTPS actually works end to end.
Reference: Cloudflare: What happens in a TLS handshake?
A load balancer distributes incoming traffic across multiple backend servers so no single server is overwhelmed, and so the service keeps working if one backend goes down. A Layer 4 load balancer makes its routing decision based on IP address and port alone — it doesn't look inside the actual data, just forwards TCP/UDP connections, which makes it fast and protocol-agnostic. A Layer 7 load balancer operates at the application layer and can inspect the actual content of the request — HTTP headers, cookies, URL paths — letting it make much smarter routing decisions, like sending /api/* traffic to one pool of servers and /static/* to another, or routing based on a session cookie for sticky sessions.
The trade-off is that Layer 7 requires terminating and inspecting the connection (often decrypting TLS), which costs more processing overhead than Layer 4's comparatively blind forward-the-packet approach — so the right choice depends on whether you actually need content-aware routing or just need raw throughput distribution.
MTU (Maximum Transmission Unit) is the largest packet size a given link can carry without fragmenting it — a common default is 1500 bytes for Ethernet. If a packet is larger than the MTU of some link along its path, one of two things happens: for IPv4, if fragmentation is allowed, the router splits it into smaller pieces (fragments) that get reassembled at the destination; if the packet has the "Don't Fragment" flag set, the router instead drops it and is supposed to send back an ICMP "Fragmentation Needed" message so the sender can retry with a smaller size — a mechanism called Path MTU Discovery.
The classic real-world failure mode: a firewall somewhere along the path blocks that ICMP message (often for security reasons), so the sender never finds out it needs to shrink its packets, and the connection just silently hangs or times out for certain payload sizes while smaller packets like a basic ping go through fine — a genuinely nasty one to diagnose because everything looks reachable until you send something large enough.
Reference: RFC 1191 — Path MTU Discovery
A CDN (Content Delivery Network) is a distributed set of servers positioned in many geographic locations that cache copies of content close to end users, instead of every request traveling back to one origin server. When a user requests content, they're routed (often via DNS or Anycast) to the nearest edge server that has it cached, rather than to the origin.
The latency reduction comes from physics as much as anything else: a request that has to travel a shorter physical distance has a shorter round-trip time, and if the content is already cached at the edge, it also skips the work the origin server would otherwise have to do to generate a fresh response. CDNs also reduce load on the origin server itself and provide resilience — if the origin goes down temporarily, cached content can often still be served — which is why CDNs are used for far more than raw speed; they're also a common first line of defense against traffic spikes and certain DDoS attacks.
Reference: Cloudflare: What is a CDN?
A Layer 2 switch forwards frames purely based on MAC address, within a single broadcast domain (or VLAN) — it has no concept of IP addresses or routing at all. A Layer 3 switch does everything a Layer 2 switch does, but also has routing capability built in, so it can forward traffic between different VLANs or subnets at wire speed, without needing a separate physical router.
This matters practically because in a modern office or data center, inter-VLAN routing is extremely common (finance VLAN talking to a shared printer VLAN, for example), and doing that routing in dedicated switch hardware is significantly faster than sending every inter-VLAN packet out to a separate router and back. The trade-off is cost and complexity — Layer 3 switches are more expensive and require more configuration than plain Layer 2 switches, so smaller networks with a single flat VLAN often don't need one at all.
A man-in-the-middle (MITM) attack is when an attacker secretly positions themselves between two communicating parties, able to intercept, read, or alter the traffic without either side realizing — a classic example is an attacker running a rogue Wi-Fi access point and intercepting everything sent by anyone who connects to it.
TLS protects against this primarily through certificate-based authentication: when you connect to a site over HTTPS, the server presents a certificate signed by a trusted Certificate Authority, cryptographically proving it's actually who it claims to be, not just someone intercepting the connection and pretending. Combined with the encryption TLS provides after the handshake, an attacker positioned in the middle can still see that a connection exists, but can't read its contents and can't successfully impersonate the real server without a valid certificate for that domain — which is also exactly why browsers show hard warnings for invalid or self-signed certificates instead of quietly proceeding: that warning is the one signal standing between the user and a possible MITM.
A routing loop happens when two or more routers each think the other is the correct next hop for a destination, so a packet bounces back and forth between them instead of ever reaching its actual destination — usually caused by a routing misconfiguration or a race condition during network convergence after a topology change.
TTL (Time to Live) is what keeps this from being catastrophic and permanent: every IP packet has a TTL field that starts at some value and gets decremented by 1 at every router hop; when it reaches zero, the router drops the packet and sends back an ICMP "Time Exceeded" message rather than forwarding it again. So a looping packet doesn't circulate forever consuming bandwidth indefinitely — it gets discarded after a bounded number of hops. TTL doesn't prevent the loop itself (that's the job of loop-avoidance mechanisms inside routing protocols, like split horizon), it just guarantees the symptom of a loop is bounded packet loss and wasted bandwidth for a short window rather than an unbounded, permanent traffic storm. This is also exactly the mechanism traceroute exploits deliberately, sending packets with intentionally low TTLs to map out each hop along a path.
Reference: RFC 791 — Internet Protocol
Jitter is the variation in latency between consecutive packets — not how slow the network is on average, but how inconsistent that speed is from one packet to the next. A link can have a perfectly acceptable average latency and still have bad jitter if some packets arrive quickly and others arrive noticeably later, in no predictable pattern.
This matters enormously for real-time audio and video because those applications need packets to arrive at a steady, predictable cadence to reconstruct a smooth stream — the receiving end typically uses a small buffer (a jitter buffer) to smooth out minor timing variation before playback. If jitter exceeds what that buffer can absorb, the result is audio that cuts out, crackles, or video that stutters, even though a simple average-latency or average-bandwidth measurement for that same link might look completely healthy. This is exactly why "my ping average looks fine but my calls still sound choppy" is a real and common symptom — average latency and jitter are different numbers, and only one of them is what a real-time application actually depends on staying low and consistent.
This is one of the most common scenario questions precisely because there's no single-sentence answer — it forces you to connect almost everything else you know about networking into one narrative.
A strong answer doesn't need perfect factual precision on every RFC detail — it needs to show you understand how DNS, TCP, TLS, and HTTP stack on top of each other, and that a slow page load could be a problem at any one of these layers.
Reference: MDN: How does the Internet work?
This is a trap question if you stop at "the network must be fine because ping works," because ICMP echo only proves basic Layer 3 reachability and low-level round-trip time — it says almost nothing about the actual HTTP path.
Worth checking, roughly in order of how cheap each check is: DNS resolution time (a slow resolver adds delay before the connection even starts — test with dig or nslookup and time it); TCP/TLS handshake time for the actual service port, not just ICMP, since ICMP can be prioritized differently by routers and firewalls than real application traffic; application-layer latency — is the backend itself slow to generate a response, independent of the network at all; packet loss and retransmissions on the actual data path, which ping's low traffic volume may not reveal but a real page load's many parallel connections will; and MTU/fragmentation issues, where large HTTP responses hit a path with a smaller MTU than ping's small packets ever exercised, causing fragmentation or silent drops.
The core lesson to state explicitly: ping tests one narrow thing (ICMP reachability and RTT), and a slow application can have a perfectly healthy ping while still being broken for entirely different reasons further up the stack.
NAT provides a security side effect, not a security feature, and this distinction is exactly what a strong answer needs to draw out. Because NAT hides internal private addresses behind one public address, an outside attacker can't directly address an internal device that hasn't initiated a connection — there's no route to a private IP from the public internet, so unsolicited inbound traffic to, say, an internal file server generally has nowhere to land.
But that's an incidental consequence of address translation, not a designed access-control mechanism, and it breaks down the moment any of several very common things happen: port forwarding explicitly opens a path to an internal device; UPnP lets applications open ports automatically, often without the user realizing it; a compromised device makes an outbound connection to an attacker (NAT does nothing to stop this, since it's the internal device initiating the session); or the network simply moves to IPv6, where NAT is typically no longer in the picture at all and every device can have its own public address. The correct security tool for actually controlling what traffic is allowed is a firewall with an explicit deny-by-default policy — NAT happening to make direct inbound access harder is a bonus, not a substitute.
Because the wired network is unaffected, this narrows the problem to the wireless layer specifically rather than the broader network — which is useful information in itself and shouldn't be discarded by jumping straight to "reboot the AP."
Worth working through: channel interference and congestion — check whether nearby APs (yours or neighboring businesses') are on overlapping channels, and whether the 2.4GHz band specifically is saturated, since it has far fewer non-overlapping channels than 5GHz and is more prone to interference from things like microwaves and Bluetooth devices; physical/RF interference — is anything new on that floor (equipment, furniture, even a change in occupancy density) that could be attenuating or reflecting signal; AP load — is one access point trying to serve far more clients than it's rated for, causing it to degrade rather than outright fail; AP placement and coverage overlap — intermittent drops can mean a client is sitting in a weak-signal zone between two APs and "roaming" badly between them; DHCP scope exhaustion — if the wireless VLAN's DHCP pool is undersized for the number of devices, clients can lose connectivity waiting for a lease that never comes, even though the radio link itself is fine; and firmware/known bugs — checking vendor release notes for the specific AP model, since intermittent, floor-specific drops are a common symptom of a known firmware issue on a batch of hardware.
The reasoning an interviewer wants to see is elimination in a sensible order — ruling out the wired/broader network first (already done, since wired works), then working from the most common causes (interference, congestion) toward the less common ones (firmware bugs), rather than guessing.
Anycast is a routing technique where the same IP address is announced from multiple physical locations simultaneously, and the underlying network's normal routing decisions (via BGP, shortest AS-path and similar metrics) automatically send each user's traffic to whichever announcing location is "closest" from the network's point of view — no DNS trickery or centralized traffic-steering component is required.
The distinction from a traditional load balancer is architectural: a load balancer is a specific device or service sitting in front of a known set of backend servers, actively making per-request decisions about where traffic goes. Anycast has no single component making that decision at all — it relies on the internet's own routing infrastructure to naturally converge each client onto the nearest instance, purely as a side effect of how BGP path selection already works. This is why Anycast is popular for things like public DNS resolvers and DDoS mitigation: there's no single point that can be directly overwhelmed, because an attack against one Anycast location's IP only affects clients whose traffic was already routing to that location, and the network itself — not a piece of application infrastructure — is what's doing the distribution.
Reference: Cloudflare: What is Anycast?
Split-horizon DNS means the same domain name resolves to different answers depending on who's asking — typically, internal users on the corporate network get one answer, and external users on the public internet get a different one, for the same hostname. It's implemented by running two separate DNS zones (or views) for the same domain: an internal-facing one served only to internal clients, and an external-facing one served to everyone else.
The common motivation is pointing internal users directly at a private IP address for a service (skipping the public internet entirely, and often getting lower latency and avoiding hairpinning through a public load balancer) while external users are still directed to the public-facing endpoint. It's also used to hide internal infrastructure hostnames and topology from the public internet as a defense-in-depth measure. The trap worth naming here: this is easy to get wrong in a way that's very hard to debug, because "it works for me" and "it's broken for you" can both be simultaneously true and correct depending only on which network each person is on — a classic source of confusing bug reports if the team supporting it doesn't know split-horizon is in play.
HTTP/1.1 sends requests over a TCP connection largely one at a time per connection (browsers work around this by opening several parallel TCP connections to the same host, but that has its own overhead). Its major pain point is head-of-line blocking: if one request is slow, requests queued behind it on the same connection have to wait.
HTTP/2 fixed this at the application layer with multiplexing — many requests and responses can be interleaved over a single TCP connection simultaneously, removing the need for multiple parallel connections and their setup overhead. But it didn't fully solve head-of-line blocking, because it's still built on a single TCP connection: if a single TCP packet is lost, TCP's guarantee of in-order delivery means everything on that connection stalls waiting for retransmission, even unrelated HTTP/2 streams that had nothing to do with the lost packet.
HTTP/3 fixed that remaining problem by dropping TCP entirely and running over QUIC, a transport protocol built on UDP. QUIC implements its own reliability and multiplexing where each stream is tracked independently, so a lost packet only blocks the one stream it belonged to, not the whole connection. QUIC also folds the TLS handshake into its own connection setup, cutting round trips needed before data can flow. The core narrative an interviewer wants: each version fixed a specific, real bottleneck the previous one still had, not just "newer is faster."
Reference: Cloudflare: What is HTTP/3?
This is a scenario question specifically designed to pull you away from server metrics and into the network path, since the prompt tells you the server itself is healthy.
Worth checking: bandwidth saturation on the link the server or the users are on — plenty of headroom on the server side doesn't mean the path between server and user has any; packet loss and retransmissions, which can silently tank throughput on TCP even without an obvious "down" symptom, since TCP's congestion control backs off aggressively in response to loss; latency and geographic distance — if users are far from the server with no CDN or edge presence in between, every round trip (DNS, TCP handshake, TLS handshake, each HTTP request) pays that distance penalty repeatedly; DNS resolution time, especially if a third-party or slow DNS provider is in the chain; MTU/fragmentation issues on the path, which can cause specific larger payloads to silently stall while smaller test traffic looks fine; connection reuse and keep-alive settings, since if every request is opening a brand-new TCP+TLS handshake instead of reusing connections, that overhead compounds badly under load; and middlebox behavior — proxies, firewalls, or load balancers in the path doing deep packet inspection or TLS termination can add real, easily overlooked latency of their own.
The reasoning to demonstrate is systematic elimination working outward from the server (which is confirmed healthy) along the actual path to the user, rather than guessing at a single likely culprit — a real "it depends" answer is what separates a strong response here from a shallow one.
802.1X is a port-based network access control standard that requires a device (or user) to authenticate — typically against a central server like RADIUS — before it's granted access to the network at all, rather than simply proving it knows a shared secret. It's the mechanism behind "enterprise" Wi-Fi authentication (WPA2/WPA3-Enterprise), where each user logs in with individual credentials or a certificate instead of everyone using the same pre-shared key.
The problem it solves is the fundamental weakness of a shared password: everyone connecting to a PSK-secured network uses the same key, so there's no way to know which specific device or person a given connection belongs to, no way to revoke just one person's access without changing the password for everyone, and no way to grant different levels of access to different people. 802.1X gives each device or user its own identity, which means you can log exactly who connected when, revoke a single compromised credential without disrupting anyone else, and — combined with something like dynamic VLAN assignment — put different users on different network segments automatically based on who they are, rather than everyone landing on the same flat network just because they typed the same password. The trade-off is real infrastructure complexity: you need a RADIUS server and a certificate or credential distribution process, which is why plenty of smaller networks still run PSK despite the security gap.
Reference: IEEE 802.1X
A default-deny posture blocks all traffic except what's explicitly permitted by a rule — nothing gets through unless someone deliberately opened a path for it. A default-allow posture permits all traffic except what's explicitly blocked — everything works by default, and you're reacting by adding blocks only once you notice something you don't want.
For a new internal segment, default-deny is almost always the right choice, and the reasoning is what an interviewer is actually listening for: default-allow means every new, unanticipated service, port, or lateral-movement path an attacker might try is open by default until someone notices and closes it — you're perpetually playing catch-up against things you haven't thought of yet. Default-deny inverts that: nothing works until someone consciously decides it should, which means unexpected traffic — including traffic from something that's already compromised trying to talk to a command-and-control server, or an attacker attempting lateral movement between segments — has no path forward unless it happens to match a rule someone deliberately wrote. The real-world cost is more upfront work: every legitimate service needs an explicit rule, and a rushed default-deny rollout can break things that were quietly relying on being allowed by default. That operational cost is exactly why default-allow still shows up in practice, despite being the weaker security posture — it's the trade-off worth naming rather than presenting default-deny as a free win.