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

Answer : D

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.

Answer : D

Cilium primarily improves Kubernetes network security through identity-aware policy enforcement across Layers 3 through 7. Standard Kubernetes NetworkPolicy resources provide Layer 3 and Layer 4 controls, while CiliumNetworkPolicy extends enforcement to application-layer rules. Policies can select workloads by labels and identity, restrict protocols and destination ports, control communication with CIDRs or entities, apply DNS/FQDN rules, and authorize supported HTTP or gRPC operations. This multi-layer enforcement is the capability described by D.

API Gateway and Gateway API configurations can contribute to controlling north-south traffic, but they are not Cilium's primary or comprehensive security mechanism. Database encryption is implemented by database, storage, or encryption-management systems rather than being a general function of Cilium. Persistent-volume backup is similarly outside Cilium's CNI, network-policy, and observability responsibilities.

Cilium's identity model is especially important in dynamic Kubernetes environments. Security policy follows workload identities derived from labels instead of depending exclusively on changing pod IP addresses. At Layer 7, traffic is redirected to Envoy when protocol-aware inspection or enforcement is required, while eBPF supplies the efficient kernel datapath for lower-layer processing.

Official references

Introduction to Cilium and Hubble; Network Policy; Layer 7 Policies.

Study Guide topic: Network Policy.

Answer : A

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.

Answer : A

cilium config view is the Cilium CLI command used to display the current Cilium configuration. It reads the configuration associated with the selected Kubernetes context, Cilium namespace, and Helm release. The command belongs to the cilium config command group, which manages installation configuration.

Option B reverses the expected command structure and does not correspond to a documented Cilium CLI operation. Option D resembles command syntax used on traditional network appliances but is not part of the Cilium CLI. Option C is both textually corrupted and conceptually inaccurate: Cilium configuration is not generally exposed through a cluster-wide resource named ciliumconfig.cilium.io. Runtime settings are commonly represented through the Cilium ConfigMap and Helm release values, while specialized resources such as CiliumNodeConfig apply targeted per-node configuration.

The wording ''display show'' is a source-bank editing defect but does not affect the answer. Administrators should also distinguish the external cilium management CLI from cilium-dbg, which runs with or communicates with the node-local Cilium agent and provides detailed datapath and agent diagnostics.

Official references

cilium config view, Cilium Component Overview

Study Guide topic: Cilium CLI configuration inspection and command structure.

Answer : D

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.

Answer : B

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.

Answer : B

B expresses the principal scalability distinction intended by the question. In kube-proxy's iptables mode, Kubernetes Services and endpoints are represented by chains of netfilter rules. As the number of Services and backends grows, rule creation, synchronization, and packet traversal can involve increasingly large rule sets. Matching through those chains is generally described as having linear scaling characteristics.

Cilium's kube-proxy replacement stores service and backend state in eBPF maps. Hash-map lookups allow the datapath to locate service entries without sequentially scanning a rule for every Service, providing effectively constant-time lookup behavior for the relevant map operations. This makes the approach better suited to large and frequently changing Kubernetes environments.

Option A is false because iptables and netfilter also operate within the Linux kernel. Option C is false because kube-proxy's iptables implementation supports IPv6 when the surrounding Kubernetes and host configuration supports it. Option D does not explain kube-proxy's primary scaling limitation and introduces an unrelated SmartNIC/XDP claim.

The constant-time description is a useful architectural simplification; total performance still depends on map sizing, backend selection, connection tracking, and kernel behavior.

Official references

Cilium eBPF Datapath, Cilium Tuning Guide

Study Guide topic: kube-proxy replacement, eBPF maps, and datapath scalability.