Networking

Networking Quiz

Quiz

Question 1 of 25 (0 answered)

Question 1

Which of the following are fundamental requirements of the Kubernetes network model?

All pods can communicate with each other without NAT All nodes can communicate with all pods without NAT The pod’s IP is the same from its own perspective and from others’ perspective All containers within a pod must use different IP addresses Services must use NAT to reach backend pods

✓

Correct!

The Kubernetes network model requires: (1) all pods can communicate without NAT, (2) all nodes can communicate with all pods without NAT, and (3) a pod’s IP is consistent from all perspectives. Containers within a pod share the same IP, and Services use ClusterIPs (not NAT directly).

✗

Incorrect

Think about the flat network model that Kubernetes implements.

Question 2

Which component is responsible for assigning IP addresses to pods?

kube-proxy CoreDNS CNI plugin kube-api-server

✓

Correct!

The CNI (Container Network Interface) plugin is responsible for assigning IP addresses to pods from the node’s pod CIDR range. The kube-api-server assigns Service IPs, while kube-proxy handles routing and CoreDNS handles DNS resolution.

✗

Incorrect

This component also creates network namespaces and configures routes.

Question 3

ClusterIPs are virtual IP addresses that don’t actually exist on any network interface.

True False

✓

Correct!

ClusterIPs are virtual and don’t exist on any interface. They are implemented through iptables or IPVS rules created by kube-proxy. When a pod sends traffic to a ClusterIP, the kernel netfilter intercepts the packet and performs DNAT to rewrite the destination to a real pod IP.

✗

Incorrect

Think about how kube-proxy implements Service networking.

Question 4

Arrange these steps in the correct order for the CNI plugin operation when a pod is scheduled:

Drag to arrange in the correct sequence

⋮⋮ Pod scheduled to node

⋮⋮ kubelet calls CNI plugin

⋮⋮ CNI creates network namespace for pod

⋮⋮ CNI creates veth pair

⋮⋮ CNI assigns IP from node’s pod CIDR

⋮⋮ CNI configures routes

⋮⋮ Returns pod IP to kubelet

✓

Correct!

The CNI workflow follows this exact sequence: scheduling triggers kubelet, which calls the CNI plugin. The plugin then creates the network namespace, assigns an IP, creates the veth pair (virtual ethernet cable), configures routing, and finally returns the pod IP to kubelet.

✗

Incorrect

Question 5

What is the default Service CIDR range in Kubernetes (format: IP/mask)?

✓

Correct!

The default Service CIDR is 10.96.0.0/12, though this is configurable via the --service-cluster-ip-range flag. This range must not overlap with the Pod CIDR or Node CIDR.

✗

Incorrect

The default Service CIDR is 10.96.0.0/12, though this is configurable via the --service-cluster-ip-range flag. This range must not overlap with the Pod CIDR or Node CIDR.

Look at the example IP allocation section showing Service CIDR configuration.

Question 6

A pod with IP 10.244.1.5 on Node 1 wants to communicate with another pod (10.244.1.6) on the same node. Which statement is MOST accurate?

Node 1
├─ Pod CIDR: 10.244.1.0/24
├─ Pod A: 10.244.1.5
└─ Pod B: 10.244.1.6

Pod A → Pod B

What will this code output?

Traffic must go through the CNI overlay network (VXLAN) Traffic is handled locally within the node by the CNI plugin kube-proxy iptables rules handle same-node pod communication Traffic requires cross-node routing to complete

✓

Correct!

Same-node pod-to-pod communication is handled locally within the node by the CNI plugin. The exact mechanism depends on the CNI implementation: bridge-based CNIs (like Flannel) use a bridge (e.g., cni0), while others like Calico use IP routing, and Cilium uses eBPF. Regardless of the implementation, same-node traffic doesn’t need to leave the node or use overlay networks.

✗

Incorrect

Consider whether traffic between pods on the same node needs to leave that node.

Question 7

How do containers within the same pod communicate with each other?

Using the pod’s IP address and different ports Using localhost (127.0.0.1) since they share a network namespace Through the cni0 bridge Via kube-proxy routing rules

✓

Correct!

Containers within the same pod share a network namespace, which means they can communicate using localhost (127.0.0.1). They share the same IP address but use different ports. This is one of the four types of communication in Kubernetes.

✗

Incorrect

Containers in a pod share more than just storage—they share networking too.

Question 8

What is the purpose of CoreDNS in a Kubernetes cluster?

CoreDNS provides DNS-based service discovery within the cluster.

It watches the API server for service creation/changes and automatically creates DNS records. When a pod makes a DNS query, CoreDNS resolves service names to their ClusterIPs, enabling pods to communicate using service names instead of IPs.

DNS Format: <service-name>.<namespace>.svc.<cluster-domain>

Example: my-service.default.svc.cluster.local → 10.96.100.50

Did you get it right?

✓

Correct!

✗

Incorrect

Question 9

Which CNI plugins support Network Policy enforcement?

Calico Flannel Cilium Weave Net AWS VPC CNI

✓

Correct!

Calico, Cilium, and Weave Net support Network Policy enforcement. Flannel does not support Network Policies (it’s designed to be simple). AWS VPC CNI also doesn’t natively support Network Policies, though you can use Calico alongside it for policy enforcement.

✗

Incorrect

Review the Popular CNI Plugins table to see which ones list ‘Network policies’ as a feature.

Question 10

Complete the DNS configuration that automatically appears in every pod:

Fill in the missing nameserver IP

# /etc/resolv.conf inside a pod
nameserver _____
search default.svc.cluster.local
search svc.cluster.local
search cluster.local
options ndots:5

Your answer:

✓

Correct!

Every pod’s /etc/resolv.conf is automatically configured to use 10.96.0.10 as the nameserver, which is the CoreDNS ClusterIP. The search domains allow pods to use short service names within their namespace or cluster-wide.

✗

Incorrect

This is the ClusterIP address assigned to the CoreDNS service.

Question 11

Arrange the complete traffic flow from an external client to a backend pod in the correct order:

Order the steps from client request to pod response

⋮⋮ Client DNS lookup resolves to LoadBalancer IP

⋮⋮ Cloud LoadBalancer routes to NodePort

⋮⋮ First DNAT: NodePort → Service ClusterIP

⋮⋮ kube-proxy intercepts NodePort traffic

⋮⋮ Second DNAT: ClusterIP → Pod IP

⋮⋮ CNI routes packet to destination pod

⋮⋮ Application in pod receives request

✓

Correct!

External traffic follows this exact path: DNS resolution → LoadBalancer → NodePort on any node → kube-proxy intercepts → DNAT to ClusterIP → DNAT to actual pod IP → CNI routing → pod receives request. The return path follows the reverse with SNAT.

✗

Incorrect

Question 12

What happens when a pod sends a packet to a Service ClusterIP?

The packet is routed directly to a backend pod The packet goes to the default gateway where kernel netfilter intercepts it and performs DNAT CoreDNS forwards the packet to the correct pod The CNI plugin routes it through the cni0 bridge

✓

Correct!

When a pod sends traffic to a ClusterIP, the packet goes to the default gateway (the node). The kernel netfilter then intercepts the packet using iptables or IPVS rules created by kube-proxy, performs DNAT to rewrite the destination to a real pod IP, and then normal routing takes over to deliver the packet.

✗

Incorrect

Remember that ClusterIPs are virtual and implemented through netfilter rules.

Question 13

The kube-proxy component actively routes network traffic between services and pods.

True False

✓

Correct!

This is a common misconception. kube-proxy does NOT actively route traffic. Instead, it creates iptables or IPVS rules on each node. The actual traffic routing is performed by the kernel’s netfilter subsystem using these rules. kube-proxy’s role is to watch the API server and maintain the correct routing rules.

✗

Incorrect

Think about what ‘proxy’ really means in this context—it’s not a traditional proxy.

Question 14

In the DNS format <service-name>.<namespace>.svc.<cluster-domain>, what is the default value for cluster-domain?

✓

Correct!

The default cluster domain is ‘cluster.local’, resulting in FQDNs like ‘my-service.default.svc.cluster.local’. This is configurable but rarely changed. Pods can use short forms within the same namespace (just ‘my-service’) thanks to the search domains in /etc/resolv.conf.

✗

Incorrect

Look at the Service DNS Format examples.

Question 15

Given this network configuration, identify which statement is CORRECT:

Cluster Configuration:
Pod CIDR:     10.244.0.0/16
Service CIDR: 10.96.0.0/12
Node CIDR:    192.168.0.0/24

Node 1: 192.168.0.10
  ├─ Pod CIDR: 10.244.1.0/24
  └─ Pod 1: 10.244.1.5

Services:
  └─ my-service: 10.96.100.50

What will this code output?

The CIDRs are overlapping which will cause routing issues All CIDRs are properly non-overlapping and correctly configured The service IP is outside the Service CIDR range The pod IP is outside its node's Pod CIDR range

✓

Correct!

This configuration is correct! The CIDRs are properly non-overlapping: Pod CIDR (10.244.0.0/16), Service CIDR (10.96.0.0/12), and Node CIDR (192.168.0.0/24) don’t overlap. The node IP (192.168.0.10) is in the node range, pod IP (10.244.1.5) is correctly in its node’s pod CIDR (10.244.1.0/24), and service IP (10.96.100.50) is within the service range. CIDR quick reference: /24 -> only last octet varies, /16 -> last two octets vary, /8 -> last three octets vary.

✗

Incorrect

Check each CIDR range and verify that none of the IP addresses fall outside their designated ranges.

Question 16

Which CNI plugin would be most appropriate for a production environment with strict security requirements and need for network policies?

Flannel - Simple overlay with VXLAN Calico - L3 routing with Network policies and BGP AWS VPC CNI - Native VPC IPs for pods Weave Net - Mesh network with encryption

✓

Correct!

Calico is specifically designed for production, security-focused environments. It provides L3 routing, robust Network Policy enforcement, BGP support for advanced routing, and excellent scalability. While AWS VPC CNI is good for AWS environments, it lacks native Network Policy support. Flannel is best for simple setups and learning, not production security.

✗

Incorrect

Check the ‘Use Case’ column in the Popular CNI Plugins table.

Question 17

What is a veth pair and how does it work in Kubernetes pod networking?

A veth (virtual ethernet) pair is like a virtual ethernet cable with two ends. Traffic sent into one end appears on the other.

In Kubernetes:

One end is placed in the pod’s network namespace (appears as eth0)
The other end is in the host namespace (appears as vethXXXX)

Purpose:

Connects isolated pod network namespace to host network
Allows pods to send and receive traffic via the node
Serves as the basic building block for pod networking
The host end is managed by the CNI plugin (via a bridge, IP routing, or eBPF depending on the implementation).

Analogy: Like a network cable connecting two separate computers, except both ‘computers’ are on the same physical machine.

Did you get it right?

✓

Correct!

✗

Incorrect

Question 18

A NetworkPolicy with the configuration shown will apply to which traffic?

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Ingress traffic to pods with label app=backend Egress traffic from pods with label app=backend Traffic from pods with label app=frontend to pods with label app=backend on TCP port 8080 Traffic from any pod to pods with label app=backend All traffic on all ports between frontend and backend

✓

Correct!

This NetworkPolicy applies to ingress traffic (policyTypes: Ingress) for pods labeled app=backend (podSelector). It only allows traffic FROM pods labeled app=frontend (ingress.from.podSelector) on TCP port 8080. It does not control egress, restricts the source to only frontend pods, and limits to port 8080 only.

✗

Incorrect

Look at the policyTypes and the podSelector fields to understand what this policy controls.

Question 19

When a pod on Node 1 (10.244.1.0/24) needs to communicate with a pod on Node 2 (10.244.2.0/24), the CNI plugin must handle cross-node routing.

True False

✓

Correct!

Correct. Cross-node pod communication requires the CNI plugin to route traffic between nodes. The packet travels from the source pod through the source node’s networking stack, across the network to the destination node, and then to the destination pod. Different CNI plugins use different mechanisms: overlay networks (VXLAN), BGP routing, or direct routing, depending on the implementation.

✗

Incorrect

Review the ‘Pod-to-Pod (Different Nodes)’ section.

Question 20

In the complete DNS resolution flow, after CoreDNS returns the Service ClusterIP to a pod, what happens next?

CoreDNS forwards the traffic to the backend pod The pod connects to the ClusterIP and kube-proxy iptables intercepts the traffic The CNI plugin routes directly to the backend pod The pod queries CoreDNS again for the actual pod IP

✓

Correct!

After DNS resolution returns the ClusterIP, the pod connects to that virtual IP address. The traffic is then intercepted by kube-proxy’s iptables/IPVS rules, which perform DNAT to rewrite the destination to an actual backend pod IP. Finally, the CNI plugin routes the packet to the destination pod. CoreDNS’s job ends after returning the ClusterIP.

✗

Incorrect

Follow the Complete DNS Resolution Flow diagram step-by-step.

Question 21

Complete the NetworkPolicy to allow only frontend pods to access backend pods on port 8080:

Fill in the missing selector field

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - _____:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Your answer:

✓

Correct!

The podSelector field in the ingress.from section specifies which pods are allowed to send traffic. This NetworkPolicy allows ingress only from pods with label app=frontend. Note this is different from the top-level podSelector which defines which pods the policy applies to (app=backend).

✗

Incorrect

This selector defines the SOURCE of allowed traffic in the ingress rules.

Question 22

Explain why Pod CIDR, Service CIDR, and Node CIDR must not overlap.

Non-overlapping CIDRs are critical for proper routing and avoiding conflicts.

Why they must be separate:

Routing ambiguity: If ranges overlap, the network stack can’t determine whether a destination IP belongs to a pod, service, or node
Service ClusterIP uniqueness: Service IPs must be in a distinct range so kube-proxy can create specific iptables rules
Pod connectivity: CNI needs to route pod traffic correctly without conflicting with node infrastructure traffic

Example of bad config:

❌ Pod CIDR: 10.0.0.0/16
❌ Node CIDR: 10.0.0.0/24  ← Overlap!

Correct config:

✅ Pod CIDR: 10.244.0.0/16
✅ Service CIDR: 10.96.0.0/12
✅ Node CIDR: 192.168.0.0/24

Did you get it right?

✓

Correct!

✗

Incorrect

Question 23

What is the primary difference between how Flannel and Calico implement pod networking?

Flannel uses iptables while Calico uses IPVS Flannel uses overlay networks (VXLAN) while Calico uses L3 routing with BGP Flannel supports Network Policies while Calico does not Flannel assigns pod IPs while Calico does not

✓

Correct!

The key architectural difference is that Flannel typically uses overlay networks (VXLAN or host-gw modes) to create a virtual network on top of the existing infrastructure, while Calico uses L3 routing with BGP to route pod traffic at the network layer. Both assign pod IPs, but their routing mechanisms differ significantly. Calico also supports Network Policies while Flannel does not.

✗

Incorrect

Look at the ‘Features’ column in the Popular CNI Plugins comparison table.

Question 24

The ndots:5 option in a pod’s /etc/resolv.conf means that any name with 5 or more dots will be treated as a fully qualified domain name.

True False

✓

Correct!

Correct. The ndots:5 option controls when the resolver treats a name as fully qualified. If a name has 5 or more dots, it’s queried as-is first before trying the search domains. If it has fewer than 5 dots, the search domains are tried first (e.g., ‘my-service’ becomes ‘my-service.default.svc.cluster.local’). This is why short service names work within Kubernetes.

✗

Incorrect

Consider how ‘my-service’ (0 dots) versus ‘my-service.default.svc.cluster.local’ (4 dots) would be resolved.

Question 25

Order the layers from closest to the pod to farthest in the network architecture:

Arrange from innermost (pod) to outermost (external)

⋮⋮ Pod network namespace (eth0)

⋮⋮ Host namespace (vethXXXX)

⋮⋮ veth pair connection

⋮⋮ CNI routing layer (cni0 bridge, IP routing, or eBPF depending on implementation)

⋮⋮ Host eth0 interface

⋮⋮ External network / Other nodes

✓

Correct!

Network traffic flows outward from the pod: starts in the pod’s isolated network namespace (eth0) → through veth pair → emerges in host namespace (vethXXXX) → processed by the CNI routing layer (cni0 bridge for bridge-based CNIs, IP routing for Calico, or eBPF for Cilium) → routes through host’s eth0 interface → reaches external network or other nodes. This architecture allows pods to be isolated yet connected.

✗

Incorrect

Follow the Pod Network Architecture diagram from inside a pod to outside the node.

Quiz Results

Score

0/0

Accuracy

Right

Wrong

Skipped

Last updated on February 23, 2026

Worker Nodes Pods