CKS Practice Question: A cluster administrator wants to monitor network…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Configure Fluentd to collect network logs from each node.

  Why it's wrong here

  Fluentd is a log aggregator that collects structured or unstructured logs from containers, files, and systemd, but it cannot capture or decode raw network packets or connection flows. Forwarding node-level logs to a centralized store still leaves you blind to pod-to-pod communication paths, protocol-level details, and connection duration. Network flow visibility demands kernel-level instrumentation such as eBPF or dedicated packet capture, not log forwarding.

• ✗

  Use Prometheus to scrape network metrics from kube-proxy.

  Why it's wrong here

  Prometheus is built to scrape time-series metrics from HTTP endpoints, and kube-proxy's /metrics endpoint primarily exposes counters about its own operational state, such as iptables sync counts, sync failures, and endpoint changes. These metrics indicate how well the proxy is functioning, but they do not describe the actual traffic flows between workloads: which pod talked to which pod, on which ports, with how much data. To monitor network traffic at the flow level, you need a tool that captures connections, not just a metrics exporter.

• ✗

  Run kube-bench to audit network policies.

  Why it's wrong here

  kube-bench is a static compliance scanner that validates cluster configurations against CIS Kubernetes benchmarks, checking things like file permissions on kubelet certificates or API server authorization flags. It does not inspect live traffic or analyze network policy enforcement at the data plane; it can only verify that NetworkPolicy resources are defined or that a CNI is configured, never what actually happened on the wire. Real-time network observability requires a separate solution that captures and correlates packet flows with Kubernetes workload identities.

• ✓

  Deploy Cilium with Hubble for network flow visibility.

  Why this is correct

  Cilium operates as a CNI data plane using eBPF, and Hubble builds on it to deliver deep network observability by capturing every TCP, UDP, and ICMP flow between pods, services, and external endpoints. Each flow is enriched with Kubernetes labels and security identities, providing timestamped source/destination IPs, ports, protocols, and byte counts at pod granularity. Because Hubble observes traffic in the kernel without sidecar proxies, it gives complete and low-overhead visibility into actual network behavior, making it the correct choice for this requirement.

Go deeper

Related to this question