Pass the Linux Foundation Cloud & Containers Cilium-Associate Questions and answers with ExamsMirror

Technical explanation

Hubble is Cilium’s integrated observability layer and consumes flow events produced by Cilium’s eBPF datapath and embedded Hubble servers. The Hubble CLI is only a client; downloading its binary does not install a standalone datapath or create flow data on a cluster that lacks Cilium. Option B is therefore the operation that is not possible.

The other approaches represent recognized Cilium deployment or migration models. A direct migration can replace the CNI configuration and recycle workloads or nodes, although a naive cluster-wide transition can disrupt connectivity. CNI chaining allows Cilium to operate with another CNI: the existing plugin continues to provide basic connectivity and IP address management, while Cilium attaches eBPF programs to the created interfaces to provide visibility, policy, and other functions. Cilium also documents migration through dual overlays. In that model, the old and new networks coexist temporarily, nodes are moved in a controlled sequence, and workloads attached to either overlay retain connectivity when the documented addressing and routing requirements are met.

The supplied bank incorrectly marks A. The verified answer is B because Hubble requires Cilium-managed observability data.

Official references

Setting up Hubble Observability ; CNI Chaining ; Migrating a cluster to Cilium .

Study Guide topic: Installation and Configuration.

Technical explanation

Cilium functions as a Kubernetes Container Network Interface implementation. When Kubernetes creates or removes a pod sandbox, the container runtime invokes the configured CNI plugin. Cilium establishes the pod’s network connectivity, connects the workload to the node’s networking environment, allocates or obtains an address through the configured IPAM mode, and coordinates the endpoint with the Cilium agent. Its eBPF datapath then supplies routing, service load balancing, policy enforcement, and network visibility.

Cilium provides substantially more functionality than the minimum CNI contract, but those additional capabilities do not change its primary Kubernetes networking role. Hubble supplies integrated network observability, yet Cilium is not merely a container-metrics monitor. Resource utilization such as CPU and memory is normally handled through Kubernetes metrics and monitoring systems.

Cilium is also not a Container Storage Interface. CSI drivers manage storage volumes, attachment, mounting, and lifecycle operations, which are unrelated to Cilium’s primary responsibilities. Nor is Cilium simply a pod-operation logging mechanism. It can emit datapath events and diagnostic logs, but those are supporting capabilities.

Accordingly, D provides the correct architectural classification for Cilium in a Kubernetes cluster.

Official references

Introduction to Cilium and Hubble ; Cilium Helm Installation .

Study Guide topic: Architecture.

Technical explanation

SPIRE supplies workload identities as SPIFFE Verifiable Identity Documents, including X.509 key material used for mutual authentication. SPIFFE’s identity model supports automatic issuance, rotation, and revocation, allowing short-lived certificates to be renewed without manually distributing static credentials. This makes D the correct statement.

Option A reverses the documented default. Cilium’s default SPIRE installation requires persistent-volume support. In-memory storage can be selected for laboratory environments by disabling server data storage, but that setting causes SPIRE data to be recreated if the server pod restarts. Option B also reverses the relationship between the projects: SPIFFE defines the identity standards and APIs, while SPIRE is a production-ready implementation of SPIFFE. Cilium’s mutual-authentication integration has been validated with SPIRE.

Option C overstates the operational requirement. A SPIRE server is involved, but Cilium’s Helm chart can deploy and configure the supported SPIRE server and per-node agents. Administrators may provide their own deployment, yet a completely manual installation is not mandatory.

Current documentation classifies this mutual-authentication implementation as beta and notes limitations, including incompatibility with Cluster Mesh trust domains. Those maturity constraints do not change the certificate-management behavior described in D.

Official references

Cilium Mutual Authentication .

Study Guide topic: Service Mesh.

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

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

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

The Hubble Server is embedded in each Cilium agent and consumes the eBPF-derived visibility data produced on that node. It exposes gRPC services through which clients can retrieve flow events, node and namespace information, server status, and related observability data. Embedding the server in the agent enables high-performance collection with comparatively low overhead.

Hubble Relay has a different role. It is a standalone component that discovers and connects to the Hubble Server instances running across the cluster. Relay aggregates their individual APIs to provide multi-node or cluster-wide visibility to clients such as the Hubble CLI and Hubble UI. It is therefore not the component embedded in the agent.

The Cilium CNI plugin is invoked when Kubernetes creates or removes pods and asks the local agent to configure their networking and datapath. The Cilium Operator performs cluster-wide management duties such as selected IPAM and shared-state operations. Neither component is responsible for exposing eBPF flow visibility.

This server–relay distinction is central to understanding Hubble’s distributed architecture: Server provides node-local visibility, while Relay combines multiple servers into a cluster-wide view.

Official references

Hubble Internals , Cilium Component Overview

Study Guide topic: Hubble Server, Hubble Relay, and distributed flow observability.

Technical explanation

Cluster Mesh extends Cilium’s identity-aware networking and policy enforcement across connected Kubernetes clusters. A CiliumNetworkPolicy can authorize communication with workloads in a particular remote cluster by selecting their workload labels together with the synthetic io.cilium.k8s.policy.cluster label. Therefore, A accurately describes a direct network-policy function.

The policies themselves are not automatically copied between clusters. Administrators remain responsible for applying the required policy resources in the appropriate clusters, but enforcement can select and govern remote endpoints once Cluster Mesh has propagated their identities.

Option B confuses authorization with transport encryption. WireGuard or IPsec configuration enables transparent encryption; it is not established by a network-policy rule. Option C is also separate from policy enforcement: cross-cluster load balancing is configured through global-service facilities and service annotations, not through CiliumNetworkPolicy . Option D is incorrect under current documentation because Cilium mutual authentication does not provide a single trust domain spanning Cluster Mesh clusters and is not presently compatible with that multi-cluster arrangement.

Official references

Cluster Mesh Network Policy , Cluster Mesh Services , Mutual Authentication Limitations

Study Guide topic: Cross-cluster identity, endpoint selection, and policy enforcement.

Technical explanation

Option B correctly represents the Ingress as a Gateway and an attached HTTPRoute . The Gateway is named cilium , uses gatewayClassName: cilium , and exposes an HTTP listener on port 80. The HTTPRoute uses parentRefs with the same Gateway name, cilium , so the route attaches to the declared listener. Its two rules preserve the original routing behavior: /details with PathPrefix targets the details Service on port 9080, while / with PathPrefix targets productpage on port 9080.

Option A declares a Gateway named cilium but attaches its route to nginx-gateway . Because the parent reference does not identify the displayed Gateway, it is not equivalent. Options C and D use kind: Route ; the correct resource kind for HTTP path routing is HTTPRoute . They also contain malformed or altered backend and matching fields. Option D changes the details backend name, while option C contains incorrect route structure and path content.

Cilium’s official migration example uses the same conversion pattern: the Ingress class becomes the Gateway’s class, paths move into HTTPRoute.rules , and the route identifies its Gateway through parentRefs .

The supplied key incorrectly identifies A. The verified answer is B.

Official references

HTTP Migration Example .

Study Guide topic: Service Mesh.

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.