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

Answer : C

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.

Answer : C

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.

Answer : D

cilium config view is the Cilium CLI command intended to display the current configuration. It reads the configuration associated with the selected Kubernetes context, Cilium namespace, and Helm release and presents the relevant settings for inspection. This makes D the direct answer.

cilium status performs a different function. It reports the health and readiness of Cilium components such as the agent DaemonSet, operator, Envoy, Hubble Relay, and Cluster Mesh. Although status output may reveal a small amount of deployment information, it is not a complete configuration-viewing command.

cilium sysdump collects a comprehensive troubleshooting archive containing Kubernetes resources, component logs, command output, configuration data, and other diagnostic evidence. It is appropriate when preparing a support bundle, but it is unnecessarily broad for simply consulting the current configuration. cilium context deals with Kubernetes context selection or inspection rather than displaying Cilium's configured values.

The Cilium CLI organizes configuration operations under the cilium config command group. Related subcommands include set, delete, and view. Because the requested action is read-only inspection of the existing settings, view is the appropriate subcommand.

Official references

Cilium CLI `config view`.

Study Guide topic: Installation and Configuration.

Answer : D

D is the accurate general description because eBPF programs can attach at kernel and application-related hook points where data may already be decrypted, depending on the program and the selected hook. The statement says ''could,'' not that every packet-processing eBPF program automatically decrypts TLS. Cilium's documented TLS-aware inspection uses controlled TLS termination and a userspace Envoy proxy; the broader point is that eBPF is not restricted to observing encrypted wire-format packets at a single network interface.

The other choices are directly contradicted by Cilium's eBPF documentation. XDP and traffic-control programs can be replaced atomically at runtime without rebooting the host or restarting network services, so A is false. Traffic-control BPF supports both ingress and egress hook points, making B false. Cilium also applies eBPF-based security to the host through its Host Firewall and host-policy capabilities; therefore, eBPF security is not inherently confined to container traffic, and C is false.

A critical distinction is that inspecting application plaintext depends on where the program attaches and where encryption occurs. Cilium's ordinary L3/L4 datapath does not magically decrypt TLS, while its documented TLS interception workflow explicitly terminates and re-originates selected connections to expose application-layer content.

Official references

Cilium eBPF program types; eBPF datapath introduction; Inspecting TLS Encrypted Connections.

Study Guide topic: eBPF.

Answer : A

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.

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 : D

Hubble provides network and security flow observability derived from Cilium's datapath. Its flow records include source and destination workloads, namespaces, identities, ports, protocols, forwarding verdicts, and drop reasons. Hubble can therefore identify services or workloads whose connections were rejected by network policy. The Hubble CLI supports filtering by verdict, such as --verdict DROPPED, and official examples show events labeled Policy denied DROPPED. These capabilities directly answer the question posed in option D.

Option B, which is marked as correct in the supplied bank, is not supported by the stated functionality. Hubble may expose network-layer or supported application-layer metadata, including DNS and HTTP information when Layer 7 visibility is configured, but it is not a database query profiler and cannot determine which internal SQL statement ran longest merely from ordinary Hubble flows. Similarly, CPU utilization is a workload-resource metric normally obtained through Kubernetes metrics, Prometheus, or another monitoring system. Cilium BGP configuration is examined through Cilium configuration and BGP status commands rather than inferred from Hubble network flows.

The supplied answer key should therefore be corrected from B to D.

Official references

Inspecting Network Flows with the Hubble CLI; Hubble internals.

Study Guide topic: Network Observability.