Free CILIUM-ASSOCIATE Practice Test Questions and Answers (2026)

Cilium is fundamentally designed as a Container Network Interface (CNI) plugin for Kubernetes. The CNI specification defines how network interfaces are configured and managed for Linux containers. By implementing the CNI standard, Cilium seamlessly integrates with Kubernetes to provide highly scalable and performant pod-to-pod connectivity, network policy enforcement, and load balancing. It leverages eBPF (Extended Berkeley Packet Filter) technology within the Linux kernel to efficiently route traffic and enforce security rules at the network and application layers. While Cilium also offers advanced observability (via Hubble) and security features, its foundational role within a Kubernetes cluster architecture is to serve as the primary CNI provider managing the cluster's data plane and network lifecycle.

A: While Cilium provides observability through Hubble, its primary architectural role in Kubernetes is as a CNI, not just a metrics monitoring tool.

B: The Container Storage Interface (CSI) is used for storage provisioning (like volumes), which is entirely unrelated to Cilium's networking focus.

C: Cilium is not a logging mechanism for pod operations; it handles network connectivity and security, though it can export network flow logs.

1. Cilium Official Documentation, "Introduction to Cilium & Hubble", Section: What is Cilium?

2. Cloud Native Computing Foundation (CNCF), "Cilium Project Summary", Section: CNI Implementation.

Cilium natively supports Layer 7 load balancing for gRPC, HTTP, and other protocols as a core component of its Service Mesh capabilities. By leveraging its embedded Envoy proxy, Cilium can parse gRPC traffic, perform advanced Layer 7 traffic management, and intelligently load balance requests across backend pods based on specific gRPC methods, paths, or headers. This native integration allows Kubernetes administrators to achieve deep visibility, traffic control, and resilient load balancing for modern microservices without the overhead of deploying and managing a separate, standalone service mesh. Cilium's eBPF-based datapath ensures that this Layer 7 routing and load balancing is performed with high performance and minimal latency, making it an ideal solution for gRPC-heavy cloud-native environments.

A: API request limiting is typically handled by API gateways or advanced Envoy configurations, not natively as a core, standalone Cilium feature without specific L7 proxy rules.

B: While Cilium provides L7 network policies for authorization, broad "API authorization" (like OAuth/OIDC) is not considered a native, standalone Cilium feature.

D: Fault injection can be configured via Envoy, but Layer 7 Load Balancing of gRPC is explicitly highlighted as a core, native use case in Cilium Service Mesh documentation.

1. Cilium Official Documentation, "Service Mesh - L7 Load Balancing", Section: gRPC Load Balancing. Available at: https://docs.cilium.io/en/stable/network/servicemesh/

2. Linux Foundation Training, "Cilium Associate (LFCs) Courseware", Module: Cilium Service Mesh Capabilities.

The Hubble Server is a core observability component embedded directly within the Cilium Agent. It connects to the eBPF data path to retrieve deep visibility into network traffic, extracting detailed flow data and metrics. By running inside the agent, the Hubble Server efficiently processes eBPF events locally on each node without requiring a separate daemon. Hubble Relay then connects to these distributed Hubble Servers to aggregate the visibility data across the entire cluster. This architecture ensures that high-volume network telemetry is processed efficiently at the source, minimizing overhead while providing real-time insights into service-to-service communication, network policies, and potential security threats.

A. The Cilium CNI plugin is responsible for network interface creation and IP address management (IPAM), not for retrieving eBPF visibility data.

B. The Cilium Operator manages cluster-wide operations like IPAM and garbage collection, rather than extracting local eBPF visibility data.

C. Hubble Relay aggregates data from multiple nodes, but it relies on the embedded Hubble Server to actually retrieve the eBPF data from the agent.

1. Cilium Official Documentation, "Architecture" -> "Hubble": https://docs.cilium.io/en/stable/overview/architecture/#hubble

In a CiliumEgressGatewayPolicy manifest, the egressGateway specification dictates how egress traffic should be routed. This specification requires a nodeSelector to identify the egress node and allows specifying either an egressIP or an interface. However, you cannot specify both simultaneously. If both an interface and an egress IP are defined in the same manifest, the policy is considered invalid and will be rejected. This restriction exists because Cilium needs a single, unambiguous source of truth for the egress IP address. It must either use the explicitly provided IP address or dynamically select the first available IPv4 address assigned to the specified network interface, preventing configuration conflicts and routing ambiguities.

B. Cilium egress gateway manifests fully support multiple label selectors within the nodeSelector or podSelector fields to accurately target nodes and pods.

C. The egress IP is not required to be a public IP address; it can be any private IP address that is routable within the target network.

D. Network interfaces are not restricted to the eth naming convention; any valid and operational network interface name on the node can be utilized.

- Cilium Official Documentation, Network Policy, "Egress Gateway" section.

In the context of Cilium network policies, special entities are used to define broad categories of network endpoints. The host entity specifically represents the local node where the evaluating pod is currently running. Crucially, this entity explicitly includes the host network namespace. As a result, any containers or pods that are running with hostNetwork: true on that specific local node are automatically considered part of the host entity. This allows administrators to easily write network policies that permit or deny traffic between a pod and the underlying host system, including any host-networked services running alongside it on the same node.

B. The remote-node entity represents other nodes in the cluster. Unmanaged endpoints are not part of the cluster entity; they fall under the unmanaged entity.

C. The cluster entity represents all endpoints within the cluster. The kube-apiserver is represented by its own distinct kube-apiserver entity.

D. The all entity represents all traffic anywhere. Endpoints strictly outside the cluster are represented by the world entity, not all.

- Cilium Official Documentation, Network Policy, "Special Entities" section.

www.dumpsplanet.com

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

HTTP Migration Example.

Study Guide topic: Service Mesh.

To establish a Cilium Cluster Mesh for cross-cluster service discovery and load balancing, one of the fundamental prerequisites is that each participating cluster must be assigned a unique cluster name and a unique cluster ID (an integer between 1 and 255). This unique identifier is critical because Cilium uses it to distinguish nodes, endpoints, and identities across the meshed environment, ensuring accurate routing and policy enforcement. Without unique cluster IDs, the mesh cannot properly differentiate between resources originating from different clusters, leading to IP and identity collisions. Other factors like geographical location, identical Kubernetes distributions, or strictly identical Cilium versions are not mandatory requirements for Cluster Mesh functionality.

A. Cluster Mesh supports multi-region and multi-cloud deployments; clusters do not need to be in the same geographical location.

B. Cluster Mesh is agnostic to the underlying Kubernetes distribution and version, allowing heterogeneous cluster environments.

C. While running compatible versions is recommended, clusters do not strictly need to run the exact same version of Cilium to mesh successfully.

1. Cilium Official Documentation, "Cluster Mesh Prerequisites", Section: "Setting up Cluster Mesh". (https://docs.cilium.io/en/stable/network/clustermesh/clustermesh/)

2. Linux Foundation Training, "LFS246: Cilium for Kubernetes", Section: "Multi-Cluster Networking with Cluster Mesh".

The L2 Announcements feature in Cilium is designed to make Kubernetes services (such as those of type LoadBalancer) visible and reachable on the local area network (LAN). It achieves this by having Cilium nodes respond to ARP (for IPv4) or NDP (for IPv6) requests for the external IP addresses of the services. This eliminates the need for external tools like MetalLB in Layer 2 environments, allowing external clients on the same subnet to seamlessly route traffic to the services. By natively integrating this capability, Cilium simplifies the network architecture and provides a robust mechanism for exposing services to the local network without relying on additional third-party load balancing software.

A: L2 Announcements are used for service IP reachability via ARP/NDP, not for routing Layer 2 multicast traffic.

C: DNS-based service discovery is handled by CoreDNS or Cilium's DNS proxy, not by L2 Announcements.

D: Network security policies are enforced by CiliumNetworkPolicies, not by the L2 Announcements feature.

- Linux Foundation, Cilium Official Documentation, "L2 Announcements", Section: Overview.

- Linux Foundation, Cilium Official Documentation, "Load Balancing", Section: L2 Announcements.

The Kubernetes Ingress API was originally designed to expose HTTP and HTTPS routes from outside the cluster to services within the cluster using a relatively simple, declarative syntax. However, it lacks advanced routing capabilities and support for non-HTTP protocols. The Gateway API is the modern evolution of Kubernetes service networking. It exposes a much more general and extensible API that supports a wider array of protocols, including HTTP, TCP, UDP, and gRPC. Furthermore, the Gateway API introduces a role-oriented resource model (GatewayClass, Gateway, and Route resources) that maps directly to the organizational roles of infrastructure providers, cluster operators, and application developers, offering significantly better deployment and management flexibility.

A. They are not identical; Gateway API is a completely new, role-oriented, and more extensible API compared to the older Ingress API.

C. Ingress does not inherently rely on iptables; its implementation depends entirely on the specific Ingress controller used (e.g., NGINX, HAProxy, or Cilium).

D. Gateway API is designed for both external (north-south) and internal (east-west) traffic management, not just internal routing.

1. Kubernetes Gateway API Official Documentation, "Introduction", Section: "Gateway API vs Ingress". (https://gateway-api.sigs.k8s.io/)

2. Cilium Official Documentation, "Gateway API", Section: "Introduction". (https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/)

The status output reports Operator: OK, followed by Deployment cilium-operator Desired: 1, Ready:

1/1, Available: 1/1. This establishes that the Cilium Operator is deployed and healthy, making B the

intended answer. Cilium uses Kubernetes CustomResourceDefinitions as its default mechanism for

storing and propagating cluster state, while the operator performs cluster-wide duties that should be

handled once centrally rather than independently on every node.

Option A is contradicted by the exhibit: both hubble-ui and hubble-relay appear as ready

deployments and running containers. Option C is incorrect because the resource is explicitly

identified as a Deployment; the cilium agents, by contrast, are shown as a DaemonSet. Option D

incorrectly treats the displayed desired replica count as a permanent restriction. A desired count of

one describes this installation’s current configuration, not a universal maximum.

The exhibit also shows embedded Envoy mode and three healthy Cilium agent instances, but neither

detail changes the operator conclusion.

Official

Cilium Component Overview, Setting up Hubble Observability

Study Guide topic: Cilium components, Cilium Operator, CRD-backed state, and status interpretation.