# Interview Questions: Networking Deep Dive

Companion question bank for the 5-part tutorial series in this folder:
`01-routing-bgp-and-internet-architecture.md`, `02-load-balancing-and-traffic-management.md`,
`03-cloud-network-architecture.md`, `04-tls-http-evolution-and-secure-transport.md`,
`05-cdn-edge-and-service-mesh-dataplanes.md`.

Answers are short and plain — expand out loud using the diagrams and worked scenarios in the tutorials.

---

# Part 1 Questions: Routing, BGP & the Internet's Architecture

## Conceptual

### 1. What's the difference between eBGP and iBGP?
eBGP runs between routers in two different Autonomous Systems — it's the actual internet-facing protocol. iBGP runs between routers inside the *same* AS, distributing externally-learned routes so every router in that AS knows how to reach them, without adding an AS-path hop.

### 2. Name the first three steps of the BGP best-path selection algorithm, in order.
Weight (Cisco-proprietary, local), then Local Preference (highest wins, set by policy), then whether the route is locally originated. Local Preference is evaluated before AS_PATH length — a shorter path can lose to a longer one with higher Local Preference.

### 3. What does RPKI's Route Origin Validation actually protect against, and what does it NOT protect against?
It validates that the AS originating a route announcement is actually authorized to, via a signed ROA — stopping the most common hijack pattern (a wrong origin AS). It does not validate the full AS path, so a path-preserving route leak that keeps the correct origin AS can still slip through.

### 4. Why does ECMP hash a fixed set of packet header fields instead of round-robining every packet?
Per-packet round robin would reorder packets within a single TCP connection across different-latency paths. Hashing a 5-tuple keeps every packet of one flow on the same path (no reordering) while still spreading different flows across the available paths.

### 5. How does anycast failover actually work at the mechanism level?
The failing/draining location withdraws its BGP announcement for the shared anycast IP. Every client whose traffic was entering there re-converges onto the next-nearest surviving location within BGP's normal convergence window — no DNS change, no client awareness.

### 6. What's the difference between BGP peering and BGP transit?
Peering is a direct, usually settlement-free exchange limited to traffic destined for each network's own customers. Transit is a paid arrangement where a provider carries your traffic to the entire rest of the internet, not just its own customers.

### 7. Why do route reflectors need to be deployed in redundant pairs?
A single route reflector is a single point of failure for internal route distribution — if it goes down, every client router loses its only path to learn externally-sourced routes, even though no external BGP session actually failed. Pairing reflectors, with every client peered to both, avoids that blast radius.

## Applied / Scenario

### 8. A prefix is reachable from your office network but not from a specific cloud region on the other side of the world, and your own router's BGP session looks healthy. What do you check first?
A route filtering issue somewhere between you and that region — most likely a prefix-length filter (if the block is longer than /24) or an outdated IRR object. A public looking-glass query from near the failing region confirms whether the route is present there at all.

### 9. Your organization announces both a /22 aggregate and, separately, one of the /24s it contains. Which one does a router elsewhere on the internet prefer, and why?
The more specific /24 wins — longest-prefix-match always beats a coarser aggregate covering the same address, the same principle BGP's best-path algorithm and a local route table both apply.

### 10. Your team is under a volumetric DDoS attack that's saturating your transit link and taking down unrelated services sharing it. What's the fastest network-layer mitigation, and what's the real cost of using it?
Remote Triggered Black Hole (RTBH) — announce a /32 for the attacked host tagged with your transit provider's blackhole community, next-hop set to a discard address. It restores the rest of your traffic within the normal BGP convergence window, but it makes the targeted host fully unreachable, not just degraded — a deliberate tradeoff reserved for attacks large enough to threaten collateral damage.

---

# Part 2 Questions: Load Balancing & Traffic Management

## Conceptual

### 11. What's the fundamental tradeoff between L4 and L7 load balancing?
L4 only sees IP/port and can't inspect content, but is very fast and preserves client IP more easily. L7 can route on path/headers and terminate TLS, but adds real overhead from parsing and often re-encrypting.

### 12. Why is least-connections generally preferred over round robin in production?
Round robin assumes every request costs the same amount of backend work, which is false for almost any real API. Least-connections adapts to real, observed load instead of assuming it away.

### 13. Why does consistent hashing matter for a caching layer but not for a stateless web service?
A stateless service can be served by any healthy backend, so a scaling event's key reassignment doesn't matter. A cache's whole value depends on "which node has this key," so a naive modulo-hash rehash on scaling can wipe most of the cache at once — consistent hashing bounds that reassignment to only the keys near the topology change.

### 14. What's the difference between circuit breaking and outlier detection?
Circuit breaking sets static, cluster-wide limits (max connections/requests) and rejects excess traffic once hit. Outlier detection watches individual hosts' real traffic outcomes and temporarily ejects a specific misbehaving host from the pool — one caps aggregate damage, the other removes the specific bad actor.

### 15. Why can naive automatic retries make an incident worse instead of better?
A backend that's momentarily slow starts timing out requests; naive immediate retries add MORE load to the same already-struggling backend, and if the retry also times out and is retried again, the effective request rate can multiply several times over — turning a blip into the thing that actually causes overload.

### 16. What's the difference between token bucket and leaky bucket rate limiting?
Token bucket allows a burst up to the bucket's capacity, then throttles to the steady refill rate — tolerates legitimate burstiness. Leaky bucket smooths everything into a constant output rate with no burst allowance at all.

## Applied / Scenario

### 17. A WebSocket service round-robins with no session affinity, and users report their connection resets on every deploy. What's happening, and what's the fix if the app can't be made stateless?
Round robin has no concept of "this client already has a pod-local session" — a reconnect after a deploy can land on a different pod, losing in-memory state. Enable session affinity (commonly cookie-based) as a stopgap, while the better long-term fix is externalizing that state so any pod can serve the reconnect.

### 18. Envoy circuit breaking rejects requests with fast 503s well before individual backend hosts show signs of being unhealthy, during a traffic spike. Is this a bug?
No — this is circuit breaking working as designed, protecting the backend cluster from being driven into overload in the first place. A fast, explicit rejection a client can retry is preferable to letting requests queue against an already-saturated fleet.

### 19. A team enables automatic retry-on-5xx for every route, including a payment-charge endpoint, and later discovers customers were double-charged during a brief database failover. What went wrong?
The charge endpoint had no idempotency-key mechanism, so a legitimately-processed charge whose response was lost in transit got retried and processed again. Retry policy should exclude non-idempotent, financially-sensitive endpoints unless the endpoint itself can safely detect and reject a duplicate.

---

# Part 3 Questions: Cloud Network Architecture

## Conceptual

### 20. Why is a VPC's CIDR block one of the most consequential early decisions in cloud network design?
It can't be freely resized once subnets and resources depend on it, and an overlapping CIDR between two VPCs blocks peering and Transit Gateway routing between them entirely — a mistake usually only discovered later, when it requires a disruptive re-IP to fix.

### 21. What actually makes a subnet "public" vs. "private"?
Purely its route table — a subnet with a default route to an Internet Gateway is public by that fact alone; one without it (or routed to a NAT Gateway instead) is private. It's not a special subnet flag.

### 22. What's the key functional difference between a Security Group and a NACL?
Security Groups are stateful (return traffic is automatically allowed) and apply per-resource; NACLs are stateless (need explicit inbound AND outbound rules) and apply per-subnet, with first-match-wins numbered rules including explicit DENY.

### 23. Why does VPC peering's scaling problem mirror BGP's iBGP full-mesh problem from Part 1?
Both need every pair to connect directly — N peering connections require N(N-1)/2 links, the same combinatorial growth as an iBGP full mesh. Transit Gateway (like a route reflector) replaces that with a hub-and-spoke model needing only N attachments.

### 24. Why is a route table entry with no match for a destination different from a Security Group block, in terms of diagnosis?
A Security Group block shows up in VPC Flow Logs as an explicit REJECT. A missing route never generates a logged packet at all for that destination — the packet never leaves the routing decision. Comparing "REJECT present" vs. "nothing logged at all" is how you tell the two apart.

### 25. What's an egress-only Internet Gateway, and why doesn't IPv6 need a NAT Gateway?
It enforces the same "outbound only" directionality as a NAT Gateway, but performs no address translation, because every IPv6 address is globally routable by design — there's no private-to-public mapping to do.

## Applied / Scenario

### 26. Two VPCs have CIDRs `10.0.0.0/16` and `10.0.128.0/17`. What's wrong before you even attempt to peer them?
`10.0.128.0/17` is entirely contained within `10.0.0.0/16` — they overlap, and peering between overlapping CIDRs is rejected outright. The only fix at that point is re-IPing one of them.

### 27. An application in a private subnet reaches a peered VPC fine but times out reaching the public internet, and a NAT Gateway exists in the VPC. What's the likely gap?
The subnet's route table is very likely missing (or has an incorrect) default route (0.0.0.0/0) to the NAT Gateway — a working specific route to one destination says nothing about a separate, unconfigured default route.

### 28. A compliance requirement demands a subnet's traffic never reach the public internet, even if a future engineer misconfigures a route table. What's the most robust enforcement?
Layer multiple independent controls, not just "don't add the route": no IGW/NAT route configured, a restrictive NACL denying anything outside known private ranges (survives even an accidental route-table change), and an IaC pipeline check that fails a deploy introducing a 0.0.0.0/0 route on a compliance-tagged subnet.

---

# Part 4 Questions: TLS, mTLS & the HTTP Protocol Evolution

## Conceptual

### 29. What did TLS 1.3 actually remove to cut the handshake from 2-RTT to 1-RTT?
It narrowed the negotiable cipher suite/key-exchange set drastically, letting the client send its key share speculatively in the ClientHello itself — collapsing what TLS 1.2 needed two round trips for into one bundled exchange.

### 30. What's the real security tradeoff of TLS 1.3's 0-RTT mode?
0-RTT data is sent before the server can verify it isn't a replay of a previously captured message — an attacker who intercepts a 0-RTT flight can resend it. It should never be used for non-idempotent operations.

### 31. What's the mechanical difference between standard TLS and mTLS?
mTLS adds one exchange to the same handshake: the server sends a CertificateRequest, and the client responds with its own certificate plus a CertificateVerify — both sides now cryptographically prove identity, not just the server.

### 32. Why do service meshes issue certificates with very short lifetimes (often under 24 hours) instead of long-lived ones?
Because certificate issuance and rotation are already fully automated by the mesh's control plane, there's no operational-toil argument for a longer lifetime — only added risk, since a compromised key's usable window scales with the certificate's validity period.

### 33. What's the difference between what hybrid post-quantum key exchange protects and what it doesn't?
It protects the confidentiality of the session's encrypted data against a future "harvest now, decrypt later" attack. It does NOT protect the certificate's own signature — that's usually still a classical algorithm, so server-identity forgery risk from a future quantum adversary remains a separate, unsolved piece.

### 34. Why did HTTP/2's multiplexing not fully solve head-of-line blocking?
It solved application-layer HOL blocking, but since HTTP/2 still runs over TCP, a single lost packet forces TCP to hold every subsequent packet — including ones from unrelated streams — until it's retransmitted. The problem moved down a layer instead of disappearing.

## Applied / Scenario

### 35. A client gets `unable to get local issuer certificate` but the same URL works fine in a browser. What's the likely cause?
The server is very likely not sending its full intermediate certificate chain. Browsers often mask this because they cache intermediates seen from other sites signed by the same CA; a fresh client has no such cache and correctly reports the gap.

### 36. A node rejects freshly-issued, correctly-signed short-lived mTLS certificates as "not yet valid" or "expired," and every certificate-chain diagnostic comes back clean. What's actually wrong?
The node's system clock has drifted from wall-clock time — certificate validity windows are checked against clock time on both ends, so an NTP misconfiguration on that specific node can cause this even though the certificates themselves are perfectly correctly issued.

### 37. Why would a team enable HTTP/3 alongside HTTP/2 via ALPN rather than making HTTP/3 the only supported protocol?
HTTP/3 runs over UDP, and some corporate firewalls and restrictive networks block or heavily rate-limit UDP far more aggressively than TCP port 443 — an HTTP/3-only endpoint would be genuinely unreachable from those networks. ALPN-negotiated fallback to TCP-based HTTP/2 is a real reachability safety net, not just old-browser compatibility.

---

# Part 5 Questions: CDN, Edge Networking & Service Mesh Data Planes

## Conceptual

### 38. How does anycast CDN routing directly reuse Part 1's BGP mechanics?
The same anycast IP is announced via BGP from every edge PoP simultaneously, and ordinary BGP best-path selection routes each client to the topologically nearest one — failover is the same BGP-withdrawal mechanism from Part 1, just operated across hundreds of PoPs instead of two regions.

### 39. What's the difference between a cache key that's too narrow and one that's too broad, and why aren't they equally bad?
Too narrow (missing an attribute that changes the response) can serve the WRONG content to a user — a correctness/security problem. Too broad (including an attribute that doesn't affect the response) only fragments the cache and hurts hit rate — a performance problem. Correctness failures are the more severe class.

### 40. What specific problem does an origin shield solve that auto-scaling doesn't?
Many independent edge PoPs can experience a cache miss for the same content at the same moment, producing a synchronized wave hitting the origin all at once. An origin shield collapses that into at most one origin request; auto-scaling only reacts after the spike is already underway.

### 41. What are ztunnel and waypoint proxies in Istio's ambient mesh, and what does each handle?
ztunnel is a lightweight, Rust-based, per-NODE proxy handling only L4 concerns (mTLS, identity-based authorization) — one instance serves every pod on that node. Waypoint proxies are full Envoy instances, deployed per-NAMESPACE, activated only when L7 traffic management is actually needed.

### 42. Why does mesh-level telemetry not replace application-level tracing?
Mesh telemetry is uniform and automatic, but it stops at the service boundary — the sidecar has no visibility into what happens inside the application process itself. Fine-grained, in-process tracing spans are still needed to pinpoint which internal function call was actually slow.

### 43. Why should a partner's mTLS certificate never be trusted directly by a service mesh's internal CA?
The mesh's internal trust model assumes every trusted certificate belongs to a mesh-managed workload under the platform's own control. Extending that trust to an external partner means a compromise of that one relationship could be used to impersonate any internal service to any other.

## Applied / Scenario

### 44. A CDN's cache hit rate is under 5% despite highly repetitive traffic, and the cache key includes a client-generated unique request-ID header. What's the fix?
Exclude the unique header from the cache key — including a genuinely per-request-unique value guarantees a miss on every single request regardless of how identical the actual content would be. Only headers that genuinely change the response (per `Vary`) belong in the key.

### 45. A platform with about a dozen services and no specific compliance driver is debating adopting a full sidecar-based service mesh "while it's small, since retrofitting later is harder." Evaluate this.
The argument inverts the real cost curve — retrofitting sidecar injection later is mechanical, well-tooled migration work, while adopting a mesh early means paying its ongoing operational cost (control-plane operation, upgrades) for years before the platform's service count, team structure, or compliance need actually justifies the benefit.

### 46. `checkout-service` needs mTLS specifically for a payment processor's settlement webhook. Should this reuse the internal mesh's own certificate authority?
No — this is a fundamentally different trust domain. The endpoint should validate the partner's certificate against a narrow, separately-configured trust anchor specific to that one relationship, kept entirely separate from the mesh's internal CA.

---

## Quick-Fire Recall Table

| Term / Question | One-line answer |
|---|---|
| eBGP vs. iBGP | Between ASes vs. within one AS |
| BGP best-path step order (first 3) | Weight → Local Preference → Locally originated |
| What RPKI's ROV validates | Origin AS only, not the full path |
| ECMP's job | Spread flows (not packets) across equal-cost paths via 5-tuple hash |
| Anycast failover mechanism | BGP route withdrawal from the failing location |
| RTBH tradeoff | Stops an attack by making the target fully unreachable |
| L4 vs. L7 load balancing | IP/port only vs. full request content, at real overhead cost |
| Best default LB algorithm | Least-connections (or power-of-two at scale), not round robin |
| Consistent hashing's purpose | Bound key reassignment to a small fraction on topology change |
| Circuit breaking vs. outlier detection | Static cluster-wide cap vs. dynamic per-host ejection |
| Retry storm cause | Naive retries add load to an already-struggling backend |
| Token bucket vs. leaky bucket | Allows bursts vs. strictly smooths to constant rate |
| Public vs. private subnet | Defined by the route table, not a special flag |
| Security Group vs. NACL | Stateful/per-resource vs. stateless/per-subnet with explicit DENY |
| VPC peering's scaling limit | N(N-1)/2 connections — same curve as iBGP full mesh |
| Egress-only Internet Gateway | NAT Gateway's IPv6 equivalent, no translation needed |
| TLS 1.3's speed win | 1-RTT via speculative key share, down from TLS 1.2's 2-RTT |
| 0-RTT's risk | Replay attack — never use for non-idempotent requests |
| mTLS vs. TLS | One extra exchange — client also presents and proves a certificate |
| Why mesh certs are short-lived | Automation removes the toil argument for long-lived ones |
| HTTP/2's unsolved problem | Transport-layer (TCP) head-of-line blocking |
| HTTP/3's fix | QUIC gives streams transport-level independence, isolating packet loss |
| Anycast CDN routing | Same BGP anycast mechanics from Part 1, at hundreds of PoPs |
| Cache key failure severity | Too narrow (wrong content) is worse than too broad (low hit rate) |
| Origin shield's job | Collapse many simultaneous edge misses into one origin request |
| ztunnel vs. waypoint | Per-node L4 only vs. per-namespace L7, activated only when needed |
| Mesh telemetry's limit | Stops at the service boundary — no in-process visibility |
| Partner mTLS trust rule | Never share the mesh's own internal CA with an external party |