Cilium-Associate Exam Questions & Answers

The intended answer is A because API request limiting corresponds to rate limiting, which Cilium identifies as a core Layer 7 traffic-management capability. Cilium combines its eBPF datapath with Envoy for application-layer processing. The official Service Mesh documentation expressly includes rate limiting among the functions that must understand protocols such as HTTP, REST, gRPC, and WebSocket. It is therefore not merely packet-rate policing at Layer 3 or Layer 4; it can be applied with application-protocol context.

However, this question is no longer valid as a strict single-answer item. Current Cilium documentation also describes proxy-based Layer 7 load balancing as useful for gRPC and provides an Envoy-backed implementation for Kubernetes Services. Consequently, option C is also supportable under the current product documentation, although the feature is identified as beta. API authorization and fault-delay injection are not presented as equivalent first-class Cilium Service Mesh use cases in the cited feature overview.

For certification-bank purposes, retain A as the intended answer, but revise option C or qualify it to restore a unique correct choice.

Official references

Service Mesh; Proxy Load Balancing for Kubernetes Services.

Study Guide topic: Service Mesh.

Cilium tunnel mode supports VXLAN and Geneve encapsulation. In this routing model, Cilium nodes form an overlay mesh, and traffic exchanged between nodes is carried inside UDP-encapsulated packets. VXLAN is the default tunnel protocol and normally uses UDP port 8472. Geneve is the alternative and normally uses UDP port 6081. Operators select the protocol through the tunnel-protocol configuration setting, whose documented values are vxlan and geneve.

Encapsulation reduces the requirements placed on the underlying network. The underlay only needs to provide IP connectivity between the Kubernetes nodes and permit the selected UDP tunnel port. It does not need to learn or route individual PodCIDRs. Cilium also uses the tunnel metadata to carry information such as the source security identity, avoiding an additional identity lookup on the receiving node.

MPLS, OTV, STT, and EVPN are not supported values for Cilium's tunnel-protocol setting. EVPN may be used in broader data-center network designs, and MPLS is a carrier-routing technology, but neither is a Cilium overlay encapsulation choice. Therefore, B is the only supported pair.

Official references

Cilium Routing; System Requirements.

Study Guide topic: Architecture.

Hubble does not obtain Layer 7 protocol visibility exclusively through eBPF without a proxy. By default, Cilium's datapath exposes Layer 3 and Layer 4 flow information. To produce supported application-layer events, traffic is selected through an L7 Cilium policy and redirected to the node-local Envoy proxy. Envoy parses the application protocol and forwards access-log information that Cilium and Hubble expose as Layer 7 flow events.

The other capabilities are supported. Hubble flow records contain the observing node, and the CLI provides node-based filtering. HTTP-aware flows can contain response status codes, enabling inspection or filtering for results such as 200 and 404. Hubble also records forwarding verdicts and drop reasons. Operators can filter for DROPPED traffic and distinguish policy-denied connections from forwarded traffic and other failure conditions.

This separation is fundamental to Cilium's architecture: eBPF provides efficient kernel-level forwarding, security enforcement, and L3/L4 observability, while Envoy supplies protocol parsing when request-level context is required. The integration remains transparent to applications, but the proxy is still present in the traffic path for Layer 7 visibility.

Therefore, B describes the unsupported mechanism and is the correct answer.

Official references

Layer 7 Protocol Visibility; Envoy; Hubble CLI.

Study Guide topic: Network Observability.

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.

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.