33 Networking Interview Questions (2026)

Networking knowledge helps backend, DevOps, and SRE engineers distinguish name-resolution, routing, transport, TLS, proxy, and application failures without guessing.

This guide covers the networking fundamentals that come up in DevOps, SRE, and backend interviews. Not certification-level theory, but practical knowledge for debugging real systems.

Table of Contents

1. Networking Fundamentals Questions
2. DNS Questions
3. HTTP and HTTPS Questions
4. Load Balancing Questions
5. Firewall and Security Questions
6. Network Troubleshooting Questions
7. Classic Interview Scenario Questions
8. Quick Reference

Networking Fundamentals Questions

Understanding the core networking concepts is essential for any DevOps or backend engineer interview.

What is the OSI model and which layers matter most for troubleshooting?

The OSI model is a conceptual framework that describes how data moves through a network in seven layers. While you don't need to memorize all seven layers for most interviews, understanding the practical layers helps you systematically debug network issues.

When troubleshooting, move from the observed symptom through name resolution, routes, transport, TLS, and application behavior. A failed ping does not prove a Layer 3 fault because ICMP may be filtered, and a successful ping does not prove that a TCP, UDP, or application path is allowed.

Layer 7 - Application    HTTP, DNS, SSH (what your app speaks)
Layer 4 - Transport      TCP, UDP (how data gets delivered)
Layer 3 - Network        IP, routing (where data goes)
Layer 2 - Data Link      MAC addresses, switches (local network)
Layer 1 - Physical       Cables, signals (hardware)

What is the difference between TCP and UDP?

TCP and UDP expose different transport semantics. TCP is a connection-oriented, reliable, ordered byte stream with flow and congestion control. UDP is a minimal datagram service that preserves message boundaries but leaves loss recovery, ordering, pacing, and congestion behavior to the application or a higher-level protocol.

TCP establishes state with a three-way handshake. Sequence numbers, acknowledgements, retransmission, and checksums provide an ordered byte stream or an error if the connection cannot continue; they do not guarantee that a remote application successfully processed a message. HTTP/1.1 and HTTP/2, SSH, SMTP, and many database protocols commonly use TCP.

UDP sends datagrams without a transport handshake and provides no delivery or ordering guarantee. Its smaller transport surface does not automatically make an application faster: DNS can use UDP, TCP, TLS, or HTTPS, and modern media often uses reliable HTTP delivery. QUIC and HTTP/3 build secure reliable streams, loss recovery, and congestion control over UDP.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: SYN (I want to connect)
    S->>C: SYN-ACK (OK, I acknowledge)
    C->>S: ACK (Great, let's talk)
    C->>S: DATA (Connection established)

When would you choose UDP over TCP?

Choose UDP when datagram semantics, multicast, application-controlled recovery, or a UDP-based protocol such as QUIC fits the requirement. For some real-time media, late retransmission is less useful than timely newer data, but the application still needs congestion control and an explicit loss strategy.

Interactive voice, game-state updates, and discovery protocols are common datagram use cases. DNS normally tries UDP for conventional queries but uses TCP in defined cases and may run over TLS or HTTPS. Do not infer transport only from the product category: streaming video delivered over HTTP commonly uses TCP or QUIC.

How do IP addressing and subnetting work?

IP addressing and subnetting are fundamental to network design and troubleshooting. IPv4 addresses consist of four octets (0-255 each), like 192.168.1.100. Subnetting allows you to divide networks into smaller, more manageable segments.

Private IP ranges defined in RFC 1918 are not routable on the internet and can be used freely within your network. The 10.0.0.0/8 range provides 16 million addresses for large networks. The 172.16.0.0/12 range offers 1 million addresses for medium networks. The 192.168.0.0/16 range provides 65,536 addresses for home and small networks.

CIDR notation combines the network address with a prefix length indicating how many bits are used for the network portion:

10.0.0.0/8    = 10.0.0.0 - 10.255.255.255   (16,777,216 IPs)
10.0.0.0/16   = 10.0.0.0 - 10.0.255.255     (65,536 IPs)
10.0.0.0/24   = 10.0.0.0 - 10.0.0.255       (256 IPs)
10.0.0.0/32   = 10.0.0.0                     (1 IP - single host)

Subnet math shortcut: Each one-bit increase in IPv4 prefix length halves the address count. A /24 contains 256 addresses, /25 contains 128, and /26 contains 64. Keep address count separate from usable host count: traditional subnet rules, RFC 3021 /31 links, and cloud-provider reservations differ. IPv6 subnetting has different conventions and no broadcast address.

How would you design IP addressing for a VPC with three subnets?

When designing cloud address space, leave room for availability zones, managed services, containers, growth, IPv6, and future peering without overlapping on-premises or partner ranges. A /16 VPC with /24 subnets is only an example, not a default suitable for every provider or workload.

Mathematically this split contains 256 /24 ranges, but usable addresses per subnet depend on the platform and may be fewer than the traditional 254. Validate quotas and provider reservations before treating the plan as capacity.

VPC: 10.0.0.0/16 (65,536 addresses total)

Subnets:
- Public:  10.0.1.0/24  (web servers, load balancers)
- Private: 10.0.2.0/24  (application servers)
- Data:    10.0.3.0/24  (databases)

Each subnet contains 256 addresses; provider-reserved addresses reduce usable capacity.

What ports should every developer know?

Default and registered ports are useful clues, not proof of the service behind a socket: applications can listen elsewhere and port forwarding can change the observed endpoint. Check the actual listener and configuration.

DNS Questions

DNS (Domain Name System) translates human-readable domain names to IP addresses. It's involved in almost every network issue you'll debug.

How does DNS resolution work step by step?

DNS resolution is a hierarchical lookup process that converts domain names to IP addresses. Understanding each step helps you debug DNS issues and optimize DNS performance.

The application or operating system stub resolver asks a configured recursive resolver. That resolver may answer from cache; otherwise it usually performs iterative queries from a root referral to a TLD referral and then an authoritative answer. Exact browser, OS, encrypted-DNS, search-domain, and cache behavior varies.

1. Browser cache      → Already know google.com? Use cached IP
2. OS cache           → Check /etc/hosts and system DNS cache
3. Resolver           → Ask configured DNS server (ISP, 8.8.8.8, etc.)
4. Recursive resolver → Query root, TLD, then authoritative servers as needed
5. Authoritative NS   → Return an answer, referral, or negative response
6. Cache the result   → Respect TTL and resolver policy

Recursive vs iterative resolution: A stub normally asks a recursive resolver for a complete result. The recursive resolver commonly follows iterative referrals itself; the end-user client does not usually query every hierarchy level.

What are the main DNS record types and when do you use each?

DNS records serve different purposes, and choosing the right record type is essential for proper domain configuration. Each record type stores specific information about how to handle requests for a domain.

Important CNAME restriction: A CNAME owner cannot have other DNS data. A zone apex must have SOA and NS records, so a standards-compliant apex cannot also be a CNAME. Provider-specific ALIAS/flattening features are not a standard DNS record type; A, AAAA, or supported flattening are deployment choices.

What is TTL and how do you choose the right value?

TTL (Time To Live) determines how long DNS records are cached by resolvers and clients. Choosing the right TTL involves balancing between quick propagation and reduced DNS query load.

Lower TTLs let compliant caches refresh positive answers sooner, at the cost of more resolver and authoritative traffic. They do not make DNS failover immediate: clients, applications, load balancers, and resolvers can have additional cache and connection behavior.

Higher TTLs improve cache hit rates and reduce DNS query load, but keep old answers valid longer. Negative answers have their own caching rules, and authoritative changes are not actively pushed to existing caches.

Planned change: Lower the TTL far enough in advance for the old TTL to expire, verify authoritative data, then restore the chosen steady-state value after the migration. This reduces—but does not eliminate—old answers and long-lived connections.

How do you troubleshoot DNS issues?

DNS troubleshooting requires systematic investigation using command-line tools. These commands help you identify whether DNS is the root cause of connectivity problems.

# Basic lookup
dig example.com
nslookup example.com
 
# Query specific record type
dig example.com MX
dig example.com TXT
 
# Query specific nameserver
dig @8.8.8.8 example.com
 
# Trace the full resolution path
dig +trace example.com
 
# Check TTL remaining
dig example.com | grep -E "^example"
# example.com.    234    IN    A    93.184.216.34
#                 ^^^-- seconds until cache expires
 
# Reverse lookup
dig -x 93.184.216.34

Common DNS error codes:

• NXDOMAIN: Domain doesn't exist (check spelling or registration)
• SERVFAIL: The resolver could not complete resolution; causes include DNSSEC validation, lame delegation, upstream failure, or server error
• Timeout: No response before the client deadline; investigate routing, filtering, server health, packet size, and transport fallback
• Unexpected answer: Compare authoritative and recursive results, TTLs, split-horizon views, search domains, and local overrides

HTTP and HTTPS Questions

Understanding HTTP is essential for debugging web applications and APIs.

What are the HTTP methods and what makes them idempotent or safe?

HTTP methods define the intended action for a request. Understanding idempotence and safety helps you design APIs correctly and debug unexpected behavior.

Idempotent means the intended server effect of multiple identical requests is the same as one request; responses and incidental effects such as logging can still differ. Safe means the client does not request a state change. These method semantics inform retry and cache behavior but do not make arbitrary application implementations correct.

What HTTP status codes should you know and what do they mean?

HTTP status codes communicate the result of a request. Knowing the common codes helps you quickly understand what's happening when debugging issues.

1xx - Informational (100 Continue, 101 Switching Protocols)
2xx - Success (200 OK, 201 Created, 204 No Content)
3xx - Redirection (301 Permanent, 302 Found, 304 Not Modified)
4xx - Client Error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found)
5xx - Server Error (500 Internal Error, 502 Bad Gateway, 503 Service Unavailable)

Key distinctions:

• 401 vs 403: 401 means the request lacks valid authentication credentials and is accompanied by a challenge; 403 means the server understood the request but refuses it, which does not require that authentication succeeded
• 502 vs 503 vs 504: 502 means bad response from upstream server, 503 means server is overloaded or down for maintenance, 504 means upstream server timed out

How does the TLS/SSL handshake work?

TLS (Transport Layer Security) encrypts communication between client and server. Understanding the handshake helps you debug certificate issues and performance problems.

The TLS handshake negotiates protocol parameters, derives traffic keys, and usually authenticates the server certificate. In TLS 1.3, most handshake messages after ServerHello are encrypted. Resumption and 0-RTT change the sequence, and 0-RTT application data has replay constraints.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello (versions, suites, key share, SNI/ALPN)
    S->>C: ServerHello (selection and key share)
    S->>C: EncryptedExtensions, Certificate, CertificateVerify, Finished
    Note over C: Verify identity, chain, validity, policy, and signature
    C->>S: Finished
    C->>S: Protected application data

Certificate chain verification:

1. Server certificate (your domain)
2. Intermediate certificate(s)
3. Root certificate (trusted by browsers)

Common TLS issues and how to debug them:

• Certificate expired: Check the notAfter date
• Name mismatch: Certificate doesn't match the domain you're connecting to
• Incomplete chain: Missing intermediate certificate
• Self-signed: Not trusted by default (need to add to trust store)

# Check certificate
openssl s_client -connect example.com:443 -servername example.com
 
# Check expiration
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

What are the differences between HTTP/1.1, HTTP/2, and HTTP/3?

HTTP has evolved significantly to address performance limitations. Each version introduces improvements in how data is transmitted between clients and servers.

HTTP/1.1: Persistent connections can carry multiple requests, and pipelining exists but requires responses in request order and has limited deployment. Browsers usually use several connections per origin. Repeated textual header fields and per-connection ordering add overhead.

HTTP/2: Binary framing multiplexes streams over one TCP connection and HPACK compresses fields. Packet loss can still stall all streams at the TCP transport layer. Server push is optional and has seen limited browser use, so it should not be presented as the main reason to adopt HTTP/2.

HTTP/3: HTTP runs over QUIC, which uses UDP but implements secure reliable streams and congestion control. Loss in one QUIC stream does not block delivery on unrelated streams, although congestion and network loss still affect the connection. QUIC combines transport and TLS 1.3 handshakes and supports connection migration; real performance depends on network, implementation, and connection reuse.

Load Balancing Questions

Load balancers distribute traffic across multiple servers to improve availability and performance.

What is the difference between Layer 4 and Layer 7 load balancing?

Layer 4 and Layer 7 load balancing operate at different levels of the network stack and offer different capabilities. Your choice depends on what information you need to make routing decisions.

Layer 4 load balancers route flows using network and transport metadata without understanding HTTP semantics. They often do less application parsing, but actual latency and throughput depend on implementation, termination, proxying mode, and hardware. Use them for passthrough and non-HTTP protocols.

Layer 7 (Application) load balancers inspect HTTP headers, URLs, and cookies. They can route based on content, perform SSL termination, and modify requests. Use them for HTTP routing, path-based routing, and A/B testing.

flowchart LR
    subgraph L4["Layer 4 Load Balancer"]
        C1["Client"] --> L4LB["L4 LB<br/>(routes by IP:port)"]
        L4LB --> S1["Server"]
    end
 
    subgraph L7["Layer 7 Load Balancer"]
        C2["Client"] --> L7LB["L7 LB"]
        L7LB -->|"/api/*"| API["API Servers"]
        L7LB -->|"/static/*"| CDN["CDN"]
    end

What load balancing algorithms exist and when do you use each?

Load balancing algorithms determine how traffic is distributed across backend servers. The right choice depends on your server capacities and request characteristics.

How would slow responses be affected by load balancing algorithm choice?

If backends have different capacity, unweighted round robin can overload the smaller instances. Weighted algorithms may help after weights are measured. First confirm whether slowness comes from backend capacity, request mix, queues, dependencies, retries, or the load balancer itself.

When request durations vary, round robin can temporarily concentrate expensive work. Least-connections uses active connection count as a proxy for load, but HTTP/2 multiplexing, keep-alive, streaming, and unequal request cost can make that proxy inaccurate. Least-request, latency-aware, power-of-two-choices, or application-aware policies may perform better after measurement.

How do health checks work in load balancing?

Health checks allow load balancers to detect unhealthy backends and stop sending traffic to them. Without proper health checks, users may be routed to failed servers.

Health check types:

• TCP Check: Can we connect to the port? Fast but basic.
• HTTP Check: Does GET /health return 200? Application-aware.
• Custom Check: Does /health return {"status": "ok", "db": "connected"}? Deep verification.

Health check parameters:

• Interval: How often to check (e.g., 10 seconds)
• Timeout: How long to wait for response (e.g., 5 seconds)
• Threshold: How many failures before marking unhealthy (e.g., 3)
• Recovery: How many successes before marking healthy (e.g., 2)

What are sticky sessions and what are the trade-offs?

Sticky sessions (session affinity) keep a user connected to the same backend server throughout their session. This simplifies applications that store session state locally but introduces operational challenges.

Methods for implementing sticky sessions:

• Cookie-based: Load balancer sets a cookie with server ID
• IP-based: Hash client IP (problems with NAT and mobile users)
• Application-based: App sets session cookie, load balancer reads it

Trade-offs:

Common alternative: Keep application instances stateless and store session state in a replicated external system or use self-contained, appropriately revocable credentials. This reduces affinity dependence but adds consistency, latency, availability, and security trade-offs.

Firewall and Security Questions

Understanding firewalls and network security is essential for secure infrastructure design.

How do firewall rules work?

Firewalls filter traffic using rules over interfaces, directions, addresses, protocols, ports, state, and other metadata. Evaluation semantics vary—first match, last match, explicit priority, chained policy, or combined allow/deny—so verify the actual platform rather than assuming one universal order.

Rules typically specify priority, action (allow/deny), protocol, source address, destination address, and port.

Rule Structure:
[Priority] [Action] [Protocol] [Source] [Destination] [Port]

Example rules:
1. ALLOW  TCP  10.0.0.0/8    any         22     # SSH from internal
2. ALLOW  TCP  any           any         443    # HTTPS from anywhere
3. ALLOW  TCP  any           any         80     # HTTP from anywhere
4. DENY   any  any           any         any    # Default deny

What is the difference between stateful and stateless firewalls?

Stateful and stateless firewalls differ in how they track connections. This affects both configuration complexity and resource usage.

Stateful firewalls remember that an outbound connection was made and automatically allow the return traffic. Stateless firewalls require you to explicitly allow traffic in both directions.

How should you segment networks for security?

Network segmentation divides your infrastructure into security zones, limiting the blast radius of a breach and controlling traffic flow between components.

The principle is defense in depth—multiple layers of security that an attacker must breach. Even if someone compromises your web servers, they shouldn't automatically have access to your databases.

flowchart TB
    Internet["Internet"]
    Internet --> LB["Load Balancer<br/>(Public)"]
 
    subgraph DMZ["DMZ Zone"]
        Web["Web Servers"]
    end
 
    subgraph Private["Private Zone"]
        App["App Servers"]
    end
 
    subgraph Data["Data Zone"]
        DB["Databases"]
    end
 
    LB --> Web
    Web -->|"Firewall"| App
    App -->|"Firewall"| DB

What is NAT and how does it work?

NAT rewrites address and often port information between network realms. Source NAT/PAT lets many private addresses share public egress. Address hiding is not an authorization control: use firewall policy, routing, identity, and application security explicitly.

Types of NAT:

• SNAT (Source NAT): Changes source IP for outbound traffic
• DNAT (Destination NAT): Changes destination IP for inbound traffic
• PAT (Port Address Translation): Many private IPs share one public IP using different ports

flowchart LR
    Private["Private<br/>10.0.1.50"] -->|"source IP changed"| NAT["NAT Gateway<br/>203.0.113.5:12345"]
    NAT -->|"translated to public IP + port"| Internet["example.com"]

NAT gateway/instance: Commonly provides outbound IPv4 connectivity for private subnets and state for returning packets. The lack of an unsolicited inbound mapping can reduce exposure, but security still comes from routing and policy controls. IPv6 normally uses global addressing with explicit egress and firewall policy rather than NAT as a requirement.

Network Troubleshooting Questions

Systematic debugging is essential for resolving network issues quickly.

What tools do you use for connectivity testing?

Connectivity tools provide observations from one source and protocol. Test the exact destination, address family, port, SNI/Host value, and credentials used by the application; ping and traceroute can follow different policy or paths and are not conclusive reachability tests.

# Basic connectivity
ping example.com
ping -c 4 example.com          # Stop after 4 pings
 
# Trace route to destination
traceroute example.com         # Linux/Mac
tracert example.com            # Windows
mtr example.com                # Better traceroute (continuous)
 
# Test specific port
telnet example.com 80
nc -zv example.com 80          # Netcat
nc -zv example.com 20-25       # Port range

How do you check what ports are in use on a system?

Knowing what ports are in use and which processes own them is essential for debugging services that won't start or for security auditing.

# Show listening ports
netstat -tulpn                 # Linux
netstat -an | grep LISTEN      # Mac
 
# Modern alternative to netstat
ss -tulpn                      # Show listening ports
ss -s                          # Socket statistics
 
# What's using a port?
lsof -i :80                    # What process has port 80
fuser 80/tcp                   # Alternative

How do you capture and analyze network packets?

A packet capture shows traffic visible at one interface and point in the path. Offloading, encryption, asymmetric routing, capture drops, and sampling can hide or reshape what you see. Capture only what is authorized and necessary because payloads and headers can contain credentials or personal data.

# Capture packets
tcpdump -i eth0                        # All traffic on interface
tcpdump -i eth0 port 80                # Only port 80
tcpdump -i eth0 host 10.0.1.50         # Only specific host
tcpdump -i eth0 -w capture.pcap        # Save to file
 
# Read capture file
tcpdump -r capture.pcap
wireshark capture.pcap                  # GUI analysis
 
# Useful filters
tcpdump 'tcp[tcpflags] & (tcp-syn) != 0'  # Only SYN packets
tcpdump -A port 80                         # ASCII for unencrypted payloads only

What curl commands are essential for HTTP debugging?

curl is your Swiss Army knife for debugging HTTP issues. Knowing these commands helps you quickly isolate whether problems are with DNS, TLS, or the application.

# Basic request
curl https://example.com
 
# Show headers
curl -I https://example.com             # HEAD request (headers only)
curl -i https://example.com             # Include headers in output
 
# Verbose output (see handshake)
curl -v https://example.com
 
# Follow redirects
curl -L https://example.com
 
# Custom headers
curl -H "Authorization: Bearer token" https://api.example.com
 
# POST with data
curl -X POST -d '{"key":"value"}' -H "Content-Type: application/json" https://api.example.com
 
# Time the request
curl -w "@curl-format.txt" -o /dev/null -s https://example.com
 
# curl-format.txt:
#     time_namelookup:  %{time_namelookup}s\n
#        time_connect:  %{time_connect}s\n
#     time_appconnect:  %{time_appconnect}s\n
#        time_total:    %{time_total}s\n

Classic Interview Scenario Questions

These scenarios test your end-to-end understanding of networking concepts.

What happens when you type google.com in a browser?

This classic question tests comprehensive understanding of web request lifecycle. Interviewers want to see that you understand each layer and can explain how they connect.

1. URL Parsing: Browser extracts protocol (https), hostname (google.com), path (/)

2. DNS Resolution:

• Check browser cache
• Check OS cache
• Query DNS resolver
• Recursive lookup through root → TLD → authoritative
• Cache result based on TTL

3. Connection establishment:

• HTTP/1.1 or HTTP/2 usually establishes TCP to port 443
• HTTP/3 establishes QUIC over UDP, often discovered through an HTTPS DNS record or Alt-Svc

4. TLS Handshake:

• Client Hello (supported ciphers)
• Server Hello (chosen cipher, certificate)
• Certificate verification
• Key exchange
• Encrypted channel established

5. HTTP Request:

• Send a GET using the negotiated HTTP version
• Headers (Host, User-Agent, Accept, etc.)

6. Server Processing:

• Load balancer routes request
• Web server processes
• Backend calls if needed
• Response generated

7. Response:

• Status code (200 OK)
• Headers (Content-Type, Cache-Control)
• Body (HTML)

8. Rendering:

• Parse HTML
• Fetch CSS, JS, images (parallel requests)
• Build DOM and CSSOM
• Execute JavaScript
• Paint to screen

How do you systematically debug connectivity issues?

A systematic approach prevents you from chasing red herrings. Work through the network stack layer by layer until you find where it breaks.

# 1. Can we resolve the hostname?
dig api.example.com
# If NXDOMAIN → DNS issue
 
# 2. Can we reach the IP?
ping 93.184.216.34
# A timeout may be ICMP policy, routing, filtering, or host behavior
 
# 3. Can we reach the port?
nc -zv 93.184.216.34 443
# Refused usually means an active reject/no listener; timeout suggests silent loss or filtering
 
# 4. Is TLS working?
openssl s_client -connect api.example.com:443
# Failure may involve trust, name, protocol, cipher, SNI/ALPN, or middleboxes
 
# 5. Does HTTP work?
curl -v https://api.example.com/health
# Separate HTTP status, proxy behavior, application errors, and client policy

How do you design for high availability?

High availability starts from a measurable objective and removes or mitigates failure modes that threaten it. Redundancy alone is insufficient: shared dependencies, correlated zones, configuration errors, overload, and unsafe retries can defeat nominally duplicated components.

Key patterns:

1. Multiple availability zones: Servers in different data centers
2. Load balancer with health checks: Automatically remove failed instances
3. Traffic failover: Health-based routing with tested TTL, cache, connection, and recovery behavior
4. Connection draining: Graceful shutdown for existing connections
5. Bounded retry with backoff and jitter: Only for safe/idempotent operations and within a deadline

flowchart TB
    R53["Route53<br/>(DNS with health checks)"]
    ALB["ALB<br/>(Cross-zone load balancing)"]
 
    R53 --> ALB
 
    subgraph AZ1["AZ-1"]
        App1["App"]
    end
 
    subgraph AZ2["AZ-2"]
        App2["App"]
    end
 
    subgraph AZ3["AZ-3"]
        App3["App"]
    end
 
    ALB --> App1
    ALB --> App2
    ALB --> App3

Quick Reference

What are the essential networking commands?

These commands cover the most common debugging scenarios. Memorizing them allows you to quickly diagnose issues.

What is the quick reference for common ports?

22   SSH         443  HTTPS TCP/UDP  6379  Redis
80   HTTP        3306 MySQL       27017 MongoDB
53   DNS         5432 PostgreSQL  9200  Elasticsearch
25   SMTP        8080 Alt HTTP    2379  etcd

What is your troubleshooting checklist?

□ DNS resolving correctly?
□ Actual address family and route correct? (ping is only supporting evidence)
□ Port open (nc/telnet)?
□ Firewall rules allow traffic?
□ Service running on target?
□ TLS certificate valid?
□ Application responding?
□ Correct response code?

Related Articles

• Linux Commands Interview Guide - Command-line fundamentals
• Docker Interview Guide - Container networking
• Kubernetes Interview Guide - Service networking, ingress
• AWS Interview Guide - VPCs, security groups, ELB
• System Design Interview Guide - Designing distributed systems

Standards and Official References

• RFC 9293: Transmission Control Protocol
• RFC 768: User Datagram Protocol
• RFC 9000: QUIC
• RFC 9114: HTTP/3
• RFC 9110: HTTP semantics
• RFC 8446: TLS 1.3
• RFC 1034: DNS concepts
• RFC 9460: SVCB and HTTPS DNS records
• RFC 1918: private IPv4 address space
• IANA service name and port registry

Frequently Asked Questions

What is the difference between TCP and UDP?

TCP provides a reliable, ordered byte stream or reports connection failure; it has connection state, flow control, and congestion control. UDP preserves datagram boundaries but does not provide delivery, ordering, retransmission, or congestion control. Choose from application semantics and protocol ecosystem—not a simple reliability-versus-speed rule. QUIC, for example, implements reliable streams and congestion control over UDP.

What happens when you type a URL in a browser?

The browser parses the URL and applies cache, proxy, HSTS, service-worker, and security policy as relevant. A stub resolver asks a recursive DNS resolver, which may use cached data or query authoritative hierarchy. HTTPS then uses TCP plus TLS for HTTP/1.1 or HTTP/2, or QUIC for HTTP/3. Connections may be reused or coalesced. The browser processes the response and discovers additional resources while parsing and rendering.

What is the difference between Layer 4 and Layer 7 load balancing?

Layer 4 load balancing routes transport flows using addresses, ports, and connection state without understanding HTTP semantics. Layer 7 terminates and parses an application protocol such as HTTP, enabling host, path, header, cookie, or method-based policy. L4 often has less per-request work; choose it for passthrough and non-HTTP traffic, and L7 for application-aware routing or termination.

How do you troubleshoot a connection timeout?

Define the exact source, destination, protocol, and timeout first. Resolve DNS with dig, test the actual transport port with nc or curl, inspect routes and policy, and compare client, load-balancer, and server evidence. Ping and traceroute are hints because ICMP can be blocked or routed differently. Packet captures show only the observation point and may contain sensitive data.

What is CIDR notation and how does subnetting work?

CIDR combines an address with a prefix length: IPv4 10.0.0.0/24 fixes 24 network bits and contains 256 addresses; /32 selects one address. Usable capacity is platform- and purpose-specific: traditional IPv4 subnets reserve network and broadcast addresses, /31 is valid for point-to-point links, and cloud providers reserve additional addresses. Plan IPv4 and IPv6 ranges from growth, routing, availability zones, and overlap constraints.

What DNS record types should developers know?

A and AAAA map names to IPv4 and IPv6 addresses. CNAME aliases one owner name and cannot coexist with other data at that name, which normally rules it out at a zone apex containing SOA and NS. MX, TXT, NS, PTR, SOA, and modern HTTPS/SVCB records cover mail, policy, delegation, reverse lookup, zone metadata, and service binding. TTL controls cache lifetime, not guaranteed propagation time.