Cilium-Associate Exam Dumps - Linux Foundation Cloud & Containers Questions and Answers

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

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.

Technical explanation

The requirement is that traffic remain encrypted all the way from the external client to the backend Service . Therefore, TLS must not terminate at the Cilium Gateway/Envoy proxy .

With TLS Passthrough , Cilium forwards the encrypted TLS stream to the backend without decrypting the application traffic. Envoy can inspect the TLS ClientHello/SNI sufficiently to select the appropriate backend, but the TLS session itself continues to the Service. Cilium specifically supports TLS passthrough with the Gateway API TLSRoute resource .

By contrast, TLS Terminate + HTTPRoute decrypts the connection at the Gateway. Although a separate encrypted connection to the backend can be configured in some architectures, that is not the same as preserving the original end-to-end TLS session requested here. Cilium's HTTPS Gateway examples use TLS termination when the Gateway itself handles the certificate.

Study Guide topic: Service Mesh.

Technical explanation

The Cilium Operator handles IP address management responsibilities in IPAM modes that require cluster-wide or cloud-integrated allocation. Current documentation identifies the operator as responsible for IPAM in Azure IPAM, AWS ENI, and cluster-scope mode. Cloud-specific operators populate the appropriate allocation information in CiliumNode resources, after which node-local agents allocate addresses to endpoints from the available ranges.

The phrase “when available” is important because responsibilities vary by IPAM mode. Under Kubernetes host-scope IPAM, Kubernetes allocates each node’s PodCIDR, and the Cilium agent consumes that range from the Kubernetes Node object. Nevertheless, among the supplied components, the operator is the component specifically associated with centralized IPAM requests and allocation management.

The Cilium agent implements each node’s datapath and endpoint lifecycle but is not the general cluster-wide IPAM answer intended here. Cilium API Server is not the documented allocation component. The misspelled Cilium CNIPIugin refers to the CNI plugin, which requests networking setup when a pod is created but does not replace the operator’s IPAM responsibilities.

Official references

Cilium Operator , Cilium IP Address Management

Study Guide topic: Cilium Operator responsibilities and IPAM modes.

Technical explanation

Layer 7 protocol visibility redirects traffic matching the relevant L7 rules to Cilium’s node-local proxy, which is Envoy. Envoy parses supported application protocols and supplies the resulting request or response metadata to Cilium’s observability pipeline. Therefore, C correctly identifies the architectural consequence of enabling this visibility.

The feature requires L7 proxy support and an appropriate CiliumNetworkPolicy containing Layer 7 rules. A standard Kubernetes NetworkPolicy is limited to Layer 3 and Layer 4 concepts and cannot express Cilium’s HTTP, DNS, or generic application-protocol rules, so B is incorrect.

A is also incorrect. DNS policy and visibility are commonly applied to pod egress queries, and Cilium’s model is not restricted to ingress-only DNS visibility. D overstates protocol coverage. Cilium supports defined L7 parsers and policy types—most prominently HTTP, DNS, Kafka, and supported generic Envoy-based protocols—but it does not promise arbitrary visibility for every application protocol. SSH, Telnet, and FTP cannot simply be assumed to receive native semantic parsing.

An operational caveat is that L7 visibility rules also affect policy enforcement: they are not merely passive packet logging instructions.

Official references

Layer 7 Protocol Visibility , Cilium Envoy

Study Guide topic: L7 proxy redirection, CiliumNetworkPolicy, protocol parsing, and Hubble visibility.

Technical explanation

A cluster-wide requirement is best implemented with CiliumClusterwideNetworkPolicy , whose correct resource spelling is CiliumClusterwideNetworkPolicy . Unlike a namespaced CiliumNetworkPolicy , this Cilium CRD is non-namespaced and can select endpoints across the entire cluster.

To deny external ingress for every Cilium-managed pod, a cluster-wide policy can use an empty endpointSelector and an ingressDeny rule selecting the world entity. Cilium defines world as network endpoints outside the cluster. An alternative allow-list construction can permit only the cluster entity, thereby excluding external sources, but an explicit deny rule usually communicates the requirement more directly.

A standard Kubernetes NetworkPolicy and a CiliumNetworkPolicy are namespaced, requiring repeated resources in every applicable namespace. CiliumGlobalPolicy is not a valid Cilium resource type. Although the option capitalizes “Wide” differently from the actual kind, D unmistakably identifies the intended cluster-scoped policy.

Official references

Cilium Deny Policies , Cilium Network Policy Types

Study Guide topic: Cluster-scoped policies, external traffic, and reserved entities.

Technical explanation

Kubernetes host-scope IPAM can be used with both Cilium tunnel routing and native direct routing. The IPAM mechanism determines how each node receives and locally allocates pod addresses; it does not inherently require a particular packet-forwarding model. The current IPAM feature matrix explicitly marks both tunnel routing and direct routing as supported for Kubernetes host-scope mode.

In this mode, Kubernetes allocates a PodCIDR to each node and publishes it through the standard v1.Node resource, normally in spec.podCIDR or spec.podCIDRs . The Cilium agent waits for the relevant range and allocates individual pod addresses from that node-specific CIDR. The correct configuration is ipam: kubernetes or the Helm equivalent ipam.mode=kubernetes , not ipam: crd ; therefore, C is false.

The documented feature matrix does not provide multiple CIDRs per cluster or multiple CIDRs per node for this mode, eliminating A and B. Multi-pool IPAM is the Cilium mode designed for allocating per-node CIDRs from multiple configurable pools.

Because Kubernetes host-scope IPAM supports either overlay tunneling or direct routing while the other statements contradict its capabilities or configuration, D is correct.

Official references

IP Address Management ; Kubernetes Host Scope .

Study Guide topic: Installation and Configuration.

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

For every pod managed by Cilium, the responsible node-local Cilium agent creates a CiliumEndpoint object with the same name and namespace. The object exposes endpoint state such as labels, the allocated security identity, addressing information, and effective policy. The agents also create endpoint objects for their inter-agent health endpoints. B is therefore correct.

The other responsibilities belong primarily to the Cilium Operator. The operator normally registers Cilium’s CustomResourceDefinitions, manages addresses for LoadBalancer Services when LB IPAM is active, and performs configured cluster-wide synchronization or shared-state operations. It also garbage-collects orphaned CiliumEndpoint resources when their associated pods no longer exist or have permanently completed.

The Cilium agent itself runs on each node. It responds to workload lifecycle events, creates and manages local endpoints, loads eBPF programs, applies policies, and maintains the node’s datapath. This division ensures that latency-sensitive forwarding and endpoint operations remain node-local while logically cluster-wide activities are consolidated in the operator.

Official references

CiliumEndpoint CRD , Cilium Operator Responsibilities

Study Guide topic: Cilium agent, Cilium Operator, and CiliumEndpoint lifecycle.

Technical explanation

The policy’s endpointSelector selects the ship workload in the namespace containing the CiliumNetworkPolicy , which is ns-cca . It also explicitly includes io.cilium.k8s.policy.cluster: cluster1 , confirming that the selected source endpoint belongs to cluster1.

The egress rule authorizes communication to an endpoint carrying name: base and the cluster label io.cilium.k8s.policy.cluster: cluster2 . Because the namespaced policy does not specify a different destination namespace through k8s:io.kubernetes.pod.namespace , the intended destination is the corresponding base workload in ns-cca on cluster2. Therefore, A matches the policy.

Options C and D incorrectly describe the rule as a deny rule. Cilium policy rules use an allow-list model unless an explicit egressDeny or ingressDeny section is present. The exhibit contains an ordinary egress rule, so matching traffic is authorized. Option B incorrectly places the destination in default .

Current Cilium versions require explicit cluster targeting for remote endpoints, which this policy provides through the cluster label.

Official references

Cluster Mesh Network Policy , Namespaces in Cilium Policy

Study Guide topic: Cluster Mesh labels, namespaced policies, and cross-cluster endpoint selection.