Free Linux Foundation Cilium Certified Associate (CCA) Cilium-Associate Exam Questions

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.

Every cluster participating in a Cilium Cluster Mesh must have a unique cluster name and numeric cluster ID. The numeric ID becomes part of Cluster Mesh security identities and allows Cilium to distinguish identities originating in different clusters. Reusing an ID would create ambiguity in endpoint identity, policy enforcement, and synchronized service information. Current documentation permits IDs from 1 through 255 under the default scaling configuration.

Geographical colocation is not required. Cluster Mesh is specifically designed to extend connectivity, policy, service discovery, and load balancing across clusters that may reside in different regions, clouds, or premises, provided the documented network-connectivity requirements are satisfied. The clusters also do not need to use an identical Kubernetes distribution or exact Kubernetes version.

Option C is unnecessarily strict. Current Cilium documentation permits connected clusters to differ by no more than one minor Cilium release; exact version equality is not mandatory. Other prerequisites include unique and non-conflicting PodCIDRs, compatible datapath modes, node connectivity, and appropriate inter-cluster communication.

The supplied bank incorrectly marks A. The verified answer is D.

Official references

Setting up Cluster Mesh.

Study Guide topic: Cluster Mesh.

Cilium derives an endpoint's security identity from its security-relevant labels rather than from its current IP address. When multiple endpoints possess the same relevant label set, they receive and share the same numeric security identity. This enables policies to follow an application as pods are recreated, rescheduled, or scaled across nodes.

In Kubernetes, the Cilium agent obtains workload metadata through the Kubernetes API and associates the pod's labels with the corresponding Cilium endpoint. Identity allocation converts the relevant label set into a cluster-wide identity. Policy enforcement then matches that identity in the eBPF datapath instead of depending exclusively on short-lived pod addresses.

Option A incorrectly makes the IP address the source of identity and says that identities cannot be shared. Option B incorrectly identifies annotations as the identity foundation. Annotations may configure behavior, but Cilium's security model is label-based. Option D is also incorrect because operators do not ordinarily assign each pod's numeric security identity manually. Identity allocation and lifecycle management are automatic.

Official references

Cilium Terminology and Identities, Limiting Identity-Relevant Labels

Study Guide topic: Label-derived identities and identity-based policy enforcement.

If a global Service has no healthy local endpoints matching its selector, every available backend can be remote. Cluster Mesh synchronizes remote service and endpoint information, allowing the local Cilium datapath to load-balance requests to backend pods in connected clusters. The absence of local endpoints therefore provides a direct explanation for the observed behavior.

If the local cluster were not part of the Cluster Mesh, its Cilium agents would not normally receive the remote endpoint state needed to route traffic through the global Service, so B does not explain successful remote-only selection. An affinity value of none is the default behavior and expresses no preference between local and remote endpoints. When both categories exist and are healthy, this permits load balancing across both; it does not require every connection to use remote backends.

Setting service.cilium.io/shared: 'false' prevents the local Service's backends from being shared with remote clusters. It does not instruct the local cluster to direct all requests toward remote endpoints.

A separate possible cause, not presented among the choices, would be service.cilium.io/affinity: 'remote'. Among the supplied answers, however, A is the valid explanation.

Official references

Service Affinity; Cluster Mesh.

Study Guide topic: Cluster Mesh.

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.

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.

C is not a valid description. A service-mesh sidecar externalizes networking functions into a proxy container running beside the application; it does not force the instrumentation logic into the application's source code. In fact, a core service-mesh objective is to provide connectivity, security, traffic management, and observability transparently without requiring application-code changes.

The operational concerns in the other choices are characteristic of sidecar implementations. A proxy must be injected into each workload pod, increasing container count and potentially affecting pod initialization, resource consumption, ordering, and readiness. Adding a sidecar to an existing pod template normally requires the pods to be recreated because Kubernetes cannot dynamically add a new container to an already-running pod.

Traffic interception also directs application traffic through the sidecar proxy and its network namespace paths, adding network-stack traversal and proxy-processing overhead. Cilium's service-mesh design can instead use node-level Envoy proxies together with eBPF traffic redirection, avoiding one proxy container in every application pod. This preserves transparent application behavior while reducing the per-workload operational burden.

Official references

Cilium Service Mesh, Cilium Ingress and Network Policy Example

Study Guide topic: Sidecar-based and sidecar-free service-mesh architectures.

Option D uses the correct structure for permitting egress from selected endpoints to the local host entity. The endpointSelector selects endpoints whose label env equals dev. Because the intended traffic travels from those endpoints toward the host, the policy must contain an egress rule. An egress peer is expressed through toEntities, and host is the reserved entity representing the local host, including host-networked containers on that node.

Option A is invalid because fromEntities is an ingress-oriented field and cannot express an egress destination. Option B uses nodeSelector, which selects nodes rather than workload endpoints and is only valid for node-level rules in a CiliumClusterwideNetworkPolicy; it is not valid in the displayed namespaced CiliumNetworkPolicy. It also combines ingress with toEntities, reversing the rule direction. Option C has a valid workload selector but again uses toEntities under ingress; ingress rules describe sources through constructs such as fromEntities.

Applying option D places the selected endpoints into egress default-deny mode and then expressly permits traffic whose destination is the host entity. Other egress traffic must be allowed separately.

Official references

Policy Enforcement and Rule Basics; Endpoint Lifecycle policy examples.

Study Guide topic: Network Policy.

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.

Ingress provides a comparatively simple API for exposing HTTP and HTTPS applications through host- and path-based routing. Gateway API is a broader, extensible family of resources that separates infrastructure configuration from application routing. Resources such as GatewayClass, Gateway, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, and UDPRoute model listeners, routes, protocols, ownership, and attachment relationships explicitly.

Gateway API was designed around operational roles. An infrastructure provider can manage the GatewayClass, a cluster operator can provision a Gateway, and an application team can own a route attached to that Gateway. This offers clearer delegation than the single Ingress resource and supports protocols and traffic-management functions beyond the original Ingress model.

The two APIs are not simply different names for identical functionality, so A is false. Option C is also inaccurate because Cilium's implementations of both Ingress and Gateway API integrate with its eBPF datapath and Envoy; Ingress is not inherently an iptables-only implementation. Option D incorrectly limits Gateway API to internal routing. It can expose internet-facing applications through generated LoadBalancer or NodePort Services or through host-network listeners.

Official references

Migrating from Ingress to Gateway; Gateway API Support.

Study Guide topic: Service Mesh.