Free Linux Foundation Cilium-Associate Practice Exam with Questions & Answers | Set: 2

Technical explanation

Policy Audit Mode allows administrators to evaluate the consequences of network policies before enforcing their deny decisions. Traffic that would ordinarily be rejected remains permitted, while Cilium records an audit verdict. These verdicts can be examined with Cilium monitoring tools and used to identify legitimate communications that are missing from the proposed policies.

This is especially valuable when introducing host policies or default-deny controls into an existing environment. An incomplete policy might otherwise block access to the Kubernetes API, node-management interfaces, DNS, monitoring systems, or other operational dependencies. The recommended workflow is to enable audit mode, observe traffic and policy verdicts, adjust the rules, confirm that all required communications receive allow verdicts, and then disable audit mode to begin enforcement.

DNS enforcement mode and HTTP audit mode are not the general Cilium configuration requested. “Policy enforcement mode” describes whether policies are normally enforced, but it does not provide the non-disruptive learning behavior in the question.

Audit mode should be treated as a temporary validation mechanism because it does not actually block disallowed traffic and does not persist across every agent-restart scenario.

Official references

Cilium Policy Audit Mode

Study Guide topic: Policy validation, audit verdicts, and safe policy rollout.

Technical explanation

The intended answer is D, but the option contains a source-bank typographical error. The valid command is cilium sysdump , not cilium sysduwp . Read literally, none of the four displayed commands exactly answers the question.

The Cilium CLI’s sysdump operation gathers cluster-wide troubleshooting material, including Cilium configuration and endpoint state, agent and operator logs, Kubernetes workload information, routing and interface details, kernel messages, service state, policies, and selected eBPF-map output. This consolidated archive is the preferred diagnostic package when investigating Kubernetes networking or preparing a support report.

cilium status --verbose provides expanded health and deployment status, but it does not collect the comprehensive diagnostic archive requested. debuginfo is associated with the in-agent debug client—currently documented as cilium-dbg debuginfo —and produces useful local-agent API information; in Kubernetes environments it is already included as part of the system dump. cilium bugtool is not the current cluster-wide Cilium CLI command requested here.

For an exam-ready correction, option D should read cilium sysdump .

Official references

Cilium Troubleshooting and Sysdump

Study Guide topic: Cilium CLI troubleshooting, system dumps, and diagnostic collection.

Technical explanation

Both Kubernetes Ingress and the north-south use of Gateway API provide declarative Layer 7 routing from clients outside the cluster to Kubernetes workloads. They express host- and path-based routing through Kubernetes resources and can be implemented by controllers such as Cilium’s Envoy-based ingress implementation. A therefore captures their shared purpose most accurately.

The remaining choices describe differences rather than universal similarities. Gateway API is explicitly role-oriented: infrastructure administrators manage GatewayClass and often Gateway , while application owners manage route resources such as HTTPRoute . The Ingress API does not provide the same formal separation of administrative and application-facing resources, making C unsuitable as a statement about both.

Implementation-specific annotations are historically common with Ingress because its core API is limited. Gateway API was deliberately designed with more expressive, portable resource fields so that implementations do not need to depend as heavily on vendor-specific annotations; D is consequently not true of both. Namespace behavior also differs because Gateway API provides controlled cross-namespace attachment and reference mechanisms. B is therefore not the defining common capability.

Official references

Cilium Kubernetes Ingress Support , Cilium Gateway API Support , Migrating from Ingress to Gateway API

Study Guide topic: Kubernetes north-south routing, Ingress, and Gateway API.

Technical explanation

B is the best answer, with two qualifications. First, “pop-to-pod” is evidently a source typo for “pod-to-pod.” Second, default WireGuard mode encrypts traffic between Cilium-managed pods on different nodes; node-to-node, pod-to-node, and node-to-pod coverage requires enabling the additional encryption.nodeEncryption=true mode.

Cilium creates WireGuard peers per node, not per pod. Each Cilium agent generates a node key pair, advertises the public key through its CiliumNode resource, and forms secure tunnels with other known nodes. This makes D incorrect. Same-node packets do not traverse a WireGuard tunnel because encryption cannot protect them from an observer already able to inspect raw traffic on that host, so A reverses the documented behavior.

C also reverses the encapsulation sequence. In tunnel-routing mode, pod traffic is first encapsulated for the VXLAN or Geneve overlay and is then encapsulated by WireGuard. The result is double encapsulation, with WireGuard protecting the overlay packet while it crosses the network between nodes.

Thus, B describes WireGuard’s supported traffic coverage most closely, but exam candidates should remember the separate node-encryption configuration requirement.

Official references

WireGuard Transparent Encryption

Study Guide topic: WireGuard peer architecture, encrypted traffic matrix, same-node behavior, and encapsulation order.

Technical explanation

Cilium uses Envoy as its userspace Layer 7 proxy. When a Cilium policy contains HTTP or another supported application-layer rule, Cilium’s eBPF datapath identifies matching traffic and redirects it to a node-local Envoy instance. Envoy evaluates the application-layer attributes—such as HTTP method, path, or headers—against the generated policy configuration and then forwards or rejects the request.

The proxy can operate in embedded mode as a separate process inside the Cilium agent pod or as the independently life-cycled cilium-envoy DaemonSet. Both deployment forms use Cilium’s optimized Envoy distribution and custom policy-enforcement filters. Communication between the agent and Envoy uses local UNIX-domain sockets for configuration, access logs, and administrative operations.

HAProxy is a capable general-purpose load balancer, but it is not Cilium’s L7 policy proxy. Squid primarily serves forward and caching proxy use cases. linkerd2-proxy belongs to the Linkerd service mesh and is not used by Cilium for network-policy enforcement. Consequently, only D identifies the proxy integrated into Cilium’s L7 datapath.

Official references

Cilium Envoy , Cilium eBPF Datapath Introduction

Study Guide topic: Envoy proxy integration and Layer 7 policy enforcement.

Technical explanation

C accurately describes eBPF host-routing. In a conventional datapath, packets may traverse substantial portions of the host networking stack and its iptables hooks even when Cilium performs routing decisions with eBPF. eBPF host-routing takes a more direct datapath, bypassing iptables and the upper host stack while providing a faster transition between the host and pod network namespaces. This reduces processing and context-switching overhead and can improve throughput and latency.

Option A describes load-balancing behavior rather than host routing. Backend distribution is implemented through Cilium’s service load-balancer maps and algorithms. Host routing can improve the path used by resulting packets, but it does not itself guarantee even backend selection.

Option B is the description of BIG TCP. BIG TCP increases the size of internal GSO and GRO packets to reduce stack traversal. Although BIG TCP requires eBPF host-routing in supported Cilium configurations, the two are distinct features.

Option D is overly specific and does not define the feature. Host routing optimizes compatible pod traffic generally, subject to kernel, kube-proxy-replacement, masquerading, netfilter, encryption, and integration constraints.

Official references

Cilium eBPF Host-Routing

Study Guide topic: eBPF host-routing, host-stack bypass, veth traversal, and performance.

Technical explanation

The host entity represents the local node on which the selected Cilium endpoint resides. It also includes processes and containers using the local host network namespace. Therefore, A reproduces the official entity definition accurately.

The remote-node entity does not represent arbitrary unmanaged endpoints. It represents hosts other than the local node across the local cluster and connected clusters, including host-networked containers on those nodes. Unmanaged endpoints instead have the reserved unmanaged identity.

Option C gives the definition of the separate kube-apiserver entity, not cluster . The cluster entity is the logical collection of endpoints and reserved identities inside the local cluster, including Cilium-managed endpoints, unmanaged local endpoints, hosts, remote nodes, health, ingress, initialization, and kube-apiserver identities. Current documentation separately provides a cluster-mesh entity for endpoints in connected clusters.

Option D confuses all with world . world represents endpoints outside the cluster. all covers all identities and is not simply equivalent to the IPv4 CIDR 0.0.0.0/0 , particularly in identity-aware, node, and IPv6 contexts.

Official references

Cilium Layer 3 Policy Entities , Cilium Reserved Identities

Study Guide topic: Reserved entities and identity-based Layer 3 policies.

Technical explanation

Masquerading performs source network address translation for qualifying traffic that leaves the cluster. Because pod addresses are often private and not routable by the external network, Cilium replaces the pod’s source address with an address belonging to the egress node. Return traffic can then reach that node, which reverses the translation and delivers the response to the originating pod. B correctly summarizes this behavior.

Masquerading is a form of SNAT, not DNAT. DNAT modifies the destination address, commonly to direct incoming traffic toward another endpoint, so C is incorrect.

Cilium documents its eBPF-based masquerading implementation as the more efficient implementation. The iptables version is the legacy alternative, making A false. Conversely, eBPF masquerading depends on appropriate kernel eBPF capabilities and Cilium’s BPF NodePort functionality. It cannot be assumed to work on every kernel version, so D is false. The legacy iptables implementation is the mode documented as broadly working across kernel versions.

Cilium can exclude natively routable CIDRs from masquerading, and administrators may configure separate IPv4 and IPv6 masquerading behavior.

Official references

Cilium Masquerading , Cilium System Requirements

Study Guide topic: SNAT, native-routing exclusions, and eBPF versus iptables masquerading.