Cilium-Associate Cilium Certified Associate (CCA) Exam Topics and Questions

Architecture carries the most weight on this exam, and it tests whether you understand how Cilium actually works under the hood. You need to know what each component does, how packets move through the datapath, and where IPAM decisions get made. Questions pull apart the control plane from the data plane and expect you to identify which piece handles which responsibility.

– Cilium's role and component responsibilities

Cilium replaces kube-proxy in many deployments, so you need to explain what that replacement means in practice. The agent runs on every node, the operator handles cluster-wide tasks, and the CNI plugin wires pods into the network. Each component has a defined scope, and the exam checks whether you can match a task to the right piece. Know what the agent does locally versus what the operator coordinates across the cluster. The distinction matters when a question describes a failure or asks you to trace a configuration change. Understanding component roles also means knowing where state lives, what talks to the API server, and which piece enforces policy at the kernel level.

– Datapath models and IPAM

Cilium offers multiple datapath modes, and each one changes how packets flow and where processing happens. You need to distinguish between them and know when each mode makes sense. IPAM is the other half of this group: Cilium can allocate pod IPs in several ways, and the choice affects address exhaustion, routing complexity, and integration with external systems. The exam will describe a scenario and expect you to identify which IPAM mode fits, or to explain what happens when a particular mode runs out of capacity. Know the trade-offs, not just the names. A question might describe packet flow and ask which datapath mode is in use, or present an IP allocation problem and ask how a given IPAM strategy would handle it.

How Architecture is tested

Twenty percent means roughly one in five items, so expect multiple questions that probe different corners of the architecture. Items often present a cluster configuration or a failure scenario and ask which component is responsible, or what happens next in the packet path. You lose marks when you confuse agent responsibilities with operator responsibilities, or when you misidentify the datapath mode based on its behaviour. Another common trap is assuming all IPAM modes behave the same way under address pressure. The exam rewards precise knowledge of where decisions are made and how data moves. Vague understanding of "Cilium handles networking" will not get you through a question that asks what happens when the agent restarts, or which component updates the identity allocation. Read each scenario carefully and map it to the specific piece of the architecture that owns that function.

Policy is where Cilium diverges most sharply from traditional Kubernetes networking, and the exam reflects that. You need to read a policy and predict its effect, understand how identity replaces IP-based matching, and know when a Kubernetes NetworkPolicy will not give you what a CiliumNetworkPolicy can. Eighteen percent means this topic appears almost as often as architecture, so weak policy knowledge costs you multiple marks.

– Identity-based security and enforcement modes

Cilium assigns an identity to every pod based on labels, and policy rules reference identities rather than IP addresses. This changes how you write rules and how you reason about connectivity. You need to explain why identity-based matching survives pod restarts and IP changes, and what happens when labels change and identities get reassigned. Enforcement modes control whether policy is default-deny or default-allow, and the mode affects every connection attempt. Know what happens when you enable policy enforcement in a namespace that has no policies yet, and how the mode interacts with rules that allow or deny traffic. The exam will describe a connectivity failure and ask whether it is caused by enforcement mode, missing identity, or a rule gap.

– Policy rule structure and Kubernetes versus Cilium policies

A CiliumNetworkPolicy has ingress and egress sections, selectors, and rules that can match on L3, L4, or L7 attributes. You need to read a YAML block and determine which pods it selects, which traffic it permits, and what happens to everything else. Rule structure includes understanding how multiple rules combine, whether they are additive, and what takes precedence. Kubernetes NetworkPolicies work at L3 and L4 only, so when a question describes L7 filtering or DNS-based rules, you know a CiliumNetworkPolicy is required. The exam tests whether you can spot the limits of a Kubernetes policy and recognize when Cilium extensions are needed. Know the syntax differences and the capability gaps, because a question might present both and ask which one achieves a stated goal.

How Network Policy is tested

Expect items that show you a policy and ask what it permits or denies, or that describe a desired security posture and ask which policy achieves it. You lose marks when you misread a selector, when you assume default-allow behaviour in a default-deny namespace, or when you pick a Kubernetes NetworkPolicy for a requirement that needs L7 filtering. Another trap is confusing ingress and egress perspectives: a rule allowing ingress on the destination does not help if egress is blocked at the source. The exam rewards careful reading of selectors and rule clauses. Do not skim the YAML and guess. Trace through the policy line by line, match it against the described traffic, and confirm that every part of the connection is permitted. Questions often include a distractor policy that looks right but selects the wrong pods or matches the wrong protocol.

Service mesh functionality in Cilium covers ingress routing, encryption, and the architectural choice between sidecars and sidecarless operation. At sixteen percent, this topic appears frequently enough that you cannot afford to skip the Gateway API material or the encryption options. Questions test whether you know when to use which ingress mechanism and what changes when you remove sidecars from the data path.

– Ingress, Gateway API, and routing decisions

Cilium supports both the Ingress resource and the newer Gateway API. You need to know what each one offers and when Gateway API gives you capabilities that Ingress cannot match. Gateway API provides more expressive routing, better role separation, and a clearer model for multi-tenant clusters. The exam will describe a routing requirement and ask which API satisfies it, or present a configuration and ask what happens to a request. Know how routes attach to gateways, how listeners work, and what happens when multiple routes match the same host. Questions often describe a scenario where Ingress falls short and expect you to identify Gateway API as the solution, or vice versa.

– Encryption and architecture models

Cilium can encrypt traffic in transit using WireGuard or IPsec, and you need to know when encryption is applied and what it costs in terms of performance and configuration complexity. The exam asks what gets encrypted, where keys are managed, and how encryption interacts with policy enforcement. Sidecar versus sidecarless architecture is the other major decision point. Traditional service meshes inject a sidecar proxy into every pod, while Cilium can deliver mesh features without sidecars by running everything in the kernel via eBPF. You need to explain the operational and performance differences, and recognize which architecture a question is describing based on the components it mentions or the behaviour it exhibits.

How Service Mesh is tested

Items present a use case and ask which feature or API solves it, or they describe a deployment and ask what behaviour results. You lose marks when you recommend Ingress for a requirement that needs Gateway API's advanced routing, or when you claim encryption is automatic without considering configuration. Another trap is assuming sidecarless means no proxying at all, when in fact Cilium still proxies traffic but does so in the kernel rather than in a separate container. The exam rewards understanding of what each feature enables and what it costs. A question might describe latency or resource consumption and ask which architecture is in use, or it might present a routing rule and ask whether it requires Gateway API or can be satisfied with Ingress. Read the requirement carefully and match it to the right tool.

Hubble is Cilium's observability layer, built on top of eBPF to give you flow visibility without tapping interfaces or parsing logs. At ten percent, this topic is lighter than architecture or policy, but it still appears often enough that you need working knowledge of the CLI and an understanding of what L7 visibility costs and delivers. Questions assume you have used Hubble to troubleshoot connectivity and can interpret its output.

How Network Observability is tested

Because this topic has only three sub-topics, expect items that focus on practical use rather than deep theory. A question might show you a Hubble CLI command and ask what it returns, or describe a connectivity problem and ask which Hubble query reveals the cause. You lose marks when you confuse L3/L4 flow data with L7 protocol visibility, because L7 requires explicit enablement and adds overhead. Another trap is assuming the UI and the CLI offer identical capabilities when in fact the CLI gives you more filtering options and the UI gives you a topology view. Know how to enable L7 visibility for a protocol, what that visibility includes, and how to query flows by pod, namespace, or verdict. The exam rewards candidates who have actually run Hubble commands and interpreted the output, not those who have only read about it.

Installation and configuration centres on the Cilium CLI, the tool you use to install, configure, and validate a Cilium deployment. This topic is practical: you need to know which commands install Cilium, which flags modify behaviour, and how to run connectivity tests to confirm everything works. Ten percent means several questions, and they assume you have run these commands in a real cluster, not just read the documentation.

How Installation and Configuration is tested

Items describe a task and ask which CLI command accomplishes it, or they present a command and ask what it does or what output it produces. You lose marks when you confuse installation flags, when you assume connectivity tests run automatically, or when you do not know how to query the current configuration. Another trap is not understanding what the status command reveals: it checks agent health, operator health, and basic connectivity, but it does not validate policy enforcement or advanced features. Know the difference between installing with default settings and installing with specific datapath or IPAM options. The exam rewards candidates who can construct a correct command from memory and interpret its success or failure. A question might describe a failed connectivity test and ask which component or configuration is at fault.

Cluster Mesh connects multiple Kubernetes clusters so that pods in one cluster can reach services in another, with identity and policy spanning the mesh. At ten percent, this topic tests whether you understand what Cluster Mesh enables, how service discovery works across cluster boundaries, and what happens to load balancing when endpoints exist in multiple clusters. Questions assume you know the operational model and the benefits over alternative multi-cluster approaches.

How Cluster Mesh is tested

Expect items that describe a multi-cluster requirement and ask whether Cluster Mesh solves it, or that present a Cluster Mesh deployment and ask what happens when a service in one cluster is called from another. You lose marks when you claim Cluster Mesh provides high availability without understanding that it requires shared identity and compatible IPAM, or when you assume service discovery is automatic without considering cluster naming and DNS. Another trap is not knowing how load balancing distributes traffic when endpoints exist in both the local and remote clusters. The exam rewards understanding of what Cluster Mesh does and what it does not do. A question might describe a connectivity failure between clusters and ask whether it is a Cluster Mesh configuration issue, a policy issue, or a routing issue. Read the scenario carefully and confirm that all the prerequisites for cross-cluster connectivity are met.

eBPF is the foundation Cilium is built on, and this topic tests whether you understand what eBPF enables, why it outperforms iptables, and where Cilium uses it. Ten percent means you will see several questions, and they expect you to explain the benefits in concrete terms: performance, programmability, and observability. Vague claims about "modern networking" will not survive a question that asks for a specific advantage or a trade-off.

How eBPF is tested

Items ask what eBPF provides that iptables cannot, or they describe a performance or observability outcome and ask which technology enables it. You lose marks when you overstate what eBPF does, when you claim it eliminates all kernel overhead, or when you confuse user-space processing with kernel-space processing. Another trap is assuming eBPF alone is enough, when in fact Cilium also needs the agent, the operator, and the CNI plugin to deliver a complete solution. Know the specific benefits: eBPF programs run in the kernel without context switches, they can be updated without restarting, and they provide per-packet visibility that iptables cannot match. The exam rewards candidates who can articulate why eBPF matters in a Cilium deployment and what it costs in terms of kernel version requirements or complexity. A question might compare an eBPF-based platform to an iptables-based one and ask which handles a given scenario more efficiently.

BGP and external networking covers how Cilium-managed clusters connect to networks outside Kubernetes, including egress traffic and BGP peering. At six percent this is the lightest topic, but you still need to know the options and when each one applies. Questions focus on egress requirements and the mechanisms Cilium offers to integrate with external routers and services.

How BGP and External Networking is tested

Expect one or two items that describe an external connectivity requirement and ask which Cilium feature or configuration satisfies it. You lose marks when you assume egress is always NAT-based, when you do not know that Cilium can announce pod CIDRs or service IPs via BGP, or when you confuse egress gateways with load balancer integration. Another trap is not understanding when BGP is needed versus when static routes or other mechanisms suffice. The exam rewards candidates who know the options and can match them to the requirement. A question might describe a scenario where pod IPs must be routable outside the cluster and ask how Cilium achieves that, or it might present an egress policy requirement and ask which feature enforces it. Read the requirement carefully and confirm that the solution you choose actually addresses the stated need.