Networking for DevOps — FAQ

Why does everyone say "always check DNS first" when troubleshooting connectivity — isn't that just one of many possible causes?

It's specifically recommended first because it's cheap and fast to rule out (dig +short takes a second), and because a DNS failure produces symptoms that can easily be mistaken for something deeper — an application that "can't connect to the database" might simply be failing to resolve the database's hostname at all, which looks identical from the outside to a real connectivity or firewall problem until you actually check. Ruling out the cheap, fast-to-check layer first isn't about DNS being the most likely cause statistically — it's about eliminating an easy possibility before spending time investigating a harder one.

If TCP guarantees reliable, ordered delivery, why does anything ever need to worry about packet loss at the application level?

Because TCP's guarantee is about the connection's byte stream arriving correctly, in order, eventually — not about when. Retransmission takes time, and an application that's sensitive to latency (a video call, a multiplayer game) can be badly hurt by TCP faithfully waiting for a retransmission and delivering everything in order, even though the underlying data would have been "good enough" arriving slightly out of order or with a tiny gap. This is exactly why those use cases pick UDP instead — they'd rather handle occasional loss themselves (or simply tolerate it) than accept TCP's correctness-over-speed tradeoff.

Why do NetworkPolicies in Kubernetes only apply once you add ANY policy at all — doesn't that seem like a confusing default?

This behavior is intentional and worth understanding precisely: before any NetworkPolicy selects a given pod, that pod has no restrictions at all (the default flat network). The moment any NetworkPolicy's selector matches a pod, that pod's traffic becomes default-deny for whatever traffic type that policy covers (ingress, egress, or both), and only explicitly allowed traffic gets through from then on. The "confusing" part is that adding a policy for one specific purpose (e.g., "allow the frontend to reach the API") can accidentally lock out traffic you didn't think to allow for, simply by virtue of that pod now being selected by a policy at all — which is exactly why testing what gets blocked, not just what you intended to allow, matters as much as writing the policy in the first place.

Is a Network Load Balancer (L4) strictly worse than an Application Load Balancer (L7), since L7 can do more?

No — L4 isn't a worse, more limited version of L7; it trades off capability for speed and protocol-agnosticism in a way that's genuinely the better choice for some workloads. Because an L4 load balancer never inspects packet content, it has meaningfully lower latency and overhead, and it works for any TCP/UDP-based protocol, not just HTTP (a raw TCP-based service, a gaming protocol, a database connection pool) — an L7 load balancer inherently can't route traffic it doesn't understand the content of. The right choice depends entirely on whether you need L7 features (path-based routing, SSL termination at the LB, HTTP-aware health checks) or whether raw protocol-agnostic speed matters more.

Why does a "ping" succeeding not guarantee an application actually works?

Because ping only tests ICMP reachability at L3 — it confirms a path exists to the destination IP and that the destination responds to ICMP Echo Requests, and nothing more. It says nothing about whether the specific port your application uses is open, whether the application process is even running, whether TLS negotiates correctly, or whether the application returns a correct response. This is exactly why this course's own troubleshooting sequences move through layers in order (ping → port check → TLS check → actual HTTP response) rather than stopping once ping succeeds — a successful ping only rules out the lowest layers, and most real application failures live above where ping can see at all.

Why do cloud providers reserve extra IP addresses in every subnet (AWS reserves 5 per subnet, for example) — doesn't that waste address space?

Those reserved addresses aren't waste; each one has a specific, necessary function the cloud platform needs regardless of what you deploy in that subnet — typically the network address itself, the VPC router, the DNS server address, a reserved-for-future-use address, and the broadcast address. This is genuinely different from traditional on-premises subnetting (where you might only lose the network and broadcast addresses), and it's a common real surprise for engineers used to traditional subnet math — a /28 that "should" have 14 usable hosts by classic subnetting rules only has 11 usable on AWS specifically, which matters when sizing a subnet close to its actual expected host count rather than leaving headroom.

Does using HTTPS everywhere make internal service-to-service traffic within a Kubernetes cluster unnecessary to secure further?

Not on its own — HTTPS/TLS protects data in transit between two points, but it doesn't control which services are allowed to talk to which other services in the first place. A compromised pod with valid TLS certificates can still make encrypted requests to services it shouldn't have access to at all — TLS secures the channel, it doesn't restrict who's allowed to open a channel. This is exactly why NetworkPolicies (controlling which connections are allowed) and mTLS/service mesh (verifying both ends' identity, not just encrypting the channel) are complementary controls, not substitutes for each other — one restricts the "who can talk to whom" question, the other secures and authenticates the actual traffic that's already been permitted.

Why does BGP matter for a DevOps engineer who isn't managing physical network hardware or an ISP relationship?

Because BGP shows up in cloud networking in ways that aren't obvious from the name alone — AWS Direct Connect and Azure ExpressRoute both use BGP to exchange routes between on-premises infrastructure and the cloud, and tools like MetalLB (for bare-metal Kubernetes load balancing) and Calico's BGP mode use it internally to advertise pod/service routes to physical routers. You don't need deep ISP-level BGP expertise for most DevOps work, but recognizing when BGP is the underlying mechanism (a hybrid-cloud connectivity issue, a bare-metal Kubernetes routing problem) versus assuming it's a simpler routing misconfiguration saves real diagnostic time.

Is `traceroute`/`mtr` output showing a "high latency" hop in the middle of the path always a real problem?

Not necessarily — many routers deprioritize or rate-limit the ICMP responses traceroute relies on (since generating those responses isn't their primary job), which can make an intermediate hop show artificially high latency or even show as unresponsive ( ) even though it's forwarding your actual traffic just fine. The reliable way to confirm an intermediate hop is a genuine problem is checking whether latency to the final* destination is actually elevated, not just a single hop in the middle — a "slow" hop that doesn't translate into elevated end-to-end latency is very often just that router's ICMP handling, not a real bottleneck.

Why does this course keep separating "liveness" from "readiness" probes in Kubernetes instead of treating health checks as one concept?

Because they answer genuinely different questions with different consequences if you get them mixed up. A liveness probe failing causes Kubernetes to restart the pod — appropriate only if the process itself is actually broken (deadlocked, crashed internally) and a restart would plausibly fix it. A readiness probe failing just removes the pod from load balancer rotation temporarily, without restarting anything — appropriate for "this pod is temporarily unable to serve traffic" (still warming up, a downstream dependency is briefly unavailable) where restarting would be pointless or actively harmful (restarting doesn't fix a downstream database being briefly overloaded, and would just cause unnecessary churn). Using the same shallow check for both, or worse, using a deep dependency check as the liveness probe, can cause a cascading restart loop when a downstream dependency has a brief hiccup — the pod itself was fine, but the liveness probe restarted it anyway.