Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. What's the main difference between an overlay and a routed (native) pod network?

   1. AOverlays are more secure
   2. BOverlays encapsulate pod packets inside node packets (VXLAN/IPIP); routed networks make pod IPs directly routable, e.g. via BGP
   3. CRouted networks need no IPs
   4. DThere's no difference
   Show answer

   B. Overlays work on any network but add header overhead (MTU). Routed modes avoid encapsulation but need the underlying network to know pod routes.

   From lesson 05 · CNI plugins compared

2. Q2. Which CNI would you pick if you need NetworkPolicy and deep flow visibility with an eBPF dataplane?

   1. AFlannel alone
   2. BCilium
   3. Ckindnet
   4. DNone
   Show answer

   B. Cilium implements policy (including L7 and FQDN) in eBPF and ships Hubble for flow observability. Flannel alone doesn't enforce NetworkPolicy.

   From lesson 05 · CNI plugins compared

3. Q3. What does Multus do?

   1. AReplaces kube-proxy
   2. BLets a pod have multiple network interfaces by calling several CNI plugins
   3. CEncrypts traffic
   4. DProvides DNS
   Show answer

   B. Multus is a meta-plugin: the default CNI provides eth0, and extra NetworkAttachmentDefinitions add net1, net2… (common in telecom and storage).

   From lesson 05 · CNI plugins compared

4. Q4. Why do large clusters move away from kube-proxy's iptables mode?

   1. Aiptables is insecure
   2. BRules grow linearly with Services and endpoints, making updates slow and lookups costly at scale
   3. Ciptables can't do NAT
   4. DIt doesn't support UDP
   Show answer

   B. Thousands of Services mean very long chains. IPVS and nftables use hash-based lookups; eBPF uses efficient maps.

   From lesson 06 · Services, kube-proxy & eBPF

5. Q5. What does externalTrafficPolicy: Local do for a LoadBalancer Service?

   1. ABlocks external traffic
   2. BSends traffic only to pods on the node that received it, preserving the client source IP (nodes without pods fail health checks)
   3. CEncrypts traffic
   4. DMakes the Service internal
   Show answer

   B. With Cluster (default), traffic may hop to another node and get SNATed, which hides the client IP. Local avoids the hop and keeps the IP.

   From lesson 06 · Services, kube-proxy & eBPF

6. Q6. What does an eBPF 'kube-proxy replacement' change?

   1. AThe Service API
   2. BHow Service load balancing is implemented: in eBPF programs at the socket or packet level instead of iptables/IPVS rules
   3. CPod IPs
   4. DDNS names
   Show answer

   B. Services look the same to users. The dataplane underneath changes, often with better performance and visibility.

   From lesson 06 · Services, kube-proxy & eBPF

7. Q7. A pod's resolv.conf has 'options ndots:5'. What happens when it looks up 'api.example.com'?

   1. AOne query, straight to the internet
   2. BThe name has fewer than 5 dots, so the search domains are tried first (api.example.com.<ns>.svc.cluster.local, …) before the name as given
   3. CThe lookup fails
   4. DOnly AAAA is queried
   Show answer

   B. ndots:5 makes most external names go through every search domain first, multiplying queries and adding latency. A trailing dot or lower ndots avoids it.

   From lesson 07 · DNS end to end

8. Q8. What does a headless Service (clusterIP: None) return from DNS?

   1. AThe node IP
   2. BThe IPs of the individual ready pods (and per-pod names for StatefulSets)
   3. CNothing
   4. DA random IP
   Show answer

   B. Headless Services skip the virtual IP. Clients get pod IPs directly, which StatefulSets use for stable names like db-0.db.

   From lesson 07 · DNS end to end

9. Q9. How do you make pods resolve names in corp.internal via the company's DNS servers?

   1. AEdit every pod
   2. BAdd a forward block for corp.internal (a stub domain) to the CoreDNS Corefile
   3. CUse hostNetwork
   4. DIt's impossible
   Show answer

   B. CoreDNS can forward specific zones to specific upstream servers, and everything else to the node's resolvers.

   From lesson 07 · DNS end to end

10. Q10. A LoadBalancer Service on bare metal stays <pending> forever. Why?

    1. AThe pods are broken
    2. BNothing in the cluster implements LoadBalancer on bare metal until you install something like MetalLB or kube-vip
    3. CDNS is missing
    4. DRBAC blocks it
    Show answer

    B. Clouds provide a controller that creates load balancers. On bare metal you need your own implementation.

    From lesson 08 · Load balancing & proxies

11. Q11. What's the main trade-off between MetalLB L2 mode and BGP mode?

    1. AL2 is encrypted
    2. BL2 is simple (one node answers ARP for the IP) but that node carries all traffic for it; BGP spreads traffic across nodes via routers but needs router cooperation
    3. CBGP needs no configuration
    4. DL2 supports IPv6 only
    Show answer

    B. L2 mode is great for small sites; BGP gives real load distribution and faster failover in data centres.

    From lesson 08 · Load balancing & proxies

12. Q12. Your app behind an L4 load balancer and a proxy sees every request coming from the proxy's IP. What can restore the real client IP?

    1. ARestarting the app
    2. BPROXY protocol between the L4 hop and the proxy, then X-Forwarded-For from the proxy to the app (with trusted-proxy settings)
    3. CA NodePort
    4. DMore replicas
    Show answer

    B. Each hop must pass the client IP along: PROXY protocol at L4, forwarded headers at L7, and the app must trust only known proxies.

    From lesson 08 · Load balancing & proxies