Cilium Certified Associate (CCA): Complete 2026 Study Guide

What the active CCA exam measures

The Cilium Certified Associate validates foundational knowledge for connecting, securing, and observing Kubernetes clusters with Cilium. The Linux Foundation identifies the intended audience as entry-level platform or cloud engineers interested in networking, security, and observability. That word “foundational” should not be confused with superficial. The exam can ask candidates to distinguish components, reason about packet paths, interpret policy intent, select an ingress model, understand Hubble output, and connect Cluster Mesh or BGP behavior to the correct control plane.

As verified on August 20, 2026, the official product page describes an online, proctored, multiple-choice exam lasting 90 minutes. It lists the experience level as beginner and certification validity as two years. Purchase conditions, scheduling eligibility, attempts, retake rules, price, identity requirements, and test-delivery procedures can change independently of the technical curriculum. Read the current product page, candidate handbook, confidentiality agreement, and multiple-choice exam instructions rather than relying on a study site's snapshot.

The public blueprint currently divides the exam into eight domains:

The 50-question CCA practice bank translates those percentages into exact whole-question counts: 10, 9, 8, 5, 5, 5, 5, and 3. That distribution prevents a common preparation error: spending most of the study period on eBPF internals while neglecting architecture, policy, and service mesh, which together account for more than half of the blueprint.

Domain 1: architecture from Kubernetes intent to Linux datapath

Cilium is a Kubernetes networking, security, and observability system whose datapath is built primarily with eBPF. Kubernetes resources describe desired state. The Cilium control components observe that state, derive endpoint identities and network configuration, and program the Linux kernel. Envoy participates where supported Layer 7 processing is needed, while Hubble exposes flow evidence generated from the datapath. Each component has a clear boundary, and CCA scenarios often become straightforward once that ownership is correct.

The cilium-agent runs on every managed node. It watches workload and Kubernetes events, receives networking and policy configuration, allocates or consumes endpoint information according to the selected IPAM design, and manages eBPF programs and maps. If a question describes local endpoint policy, Service translation, node health, or kernel datapath state, the agent is usually central.

The Cilium Operator handles duties that should occur once or a small number of times per cluster rather than independently on every node. Its exact controllers depend on enabled features and IPAM mode. Crucially, it is not in the critical packet-forwarding or policy-decision path. Existing traffic may continue during a temporary Operator outage, although new address allocation, reconciliation, and other cluster-wide workflows can degrade. “Not in the forwarding path” is not the same as “unimportant.”

The cilium-cni binary participates in the Container Network Interface lifecycle. When the runtime creates or deletes a Pod sandbox, Kubernetes invokes the CNI plugin. It communicates with the local Cilium API so endpoint networking, identity, routes or links, and datapath state can be created or removed. It does not schedule Pods, aggregate Hubble flows, or configure external BGP peers.

The cilium CLI is a cluster-facing management tool generally run from an administrator workstation using kubeconfig. It installs and manages Cilium, reports status, enables Hubble, runs connectivity tests, and collects diagnostic information. The cilium-dbg client is different: it is installed alongside the agent and communicates with the local agent API for node-specific troubleshooting and map inspection. Learn the distinction instead of treating every command as interchangeable.

Cilium's default state propagation uses Kubernetes custom resources. Depending on topology and feature, a key-value store can serve supported synchronization or scalability roles. Hubble Server is embedded in each Cilium agent and exposes node-local flow information. Hubble Relay discovers and connects to those servers to provide a cluster-wide API. The Hubble CLI queries flows, and Hubble UI uses Relay to draw service relationships and list recent events.

IPAM is an architecture decision

IP address management allocates and manages addresses for endpoints. Cilium supports multiple modes because environments differ. Cluster-pool IPAM lets Cilium allocate per-node prefixes from configured cluster pools. Kubernetes host-scope consumes PodCIDRs assigned through Kubernetes. Multi-pool can provide multiple address pools. CRD-backed and cloud-integrated modes support other infrastructure models, including cloud interfaces and externally managed address space.

Do not memorize mode names without asking four questions: who owns the source CIDR, who allocates a node or endpoint address, whether addresses are natively routable, and which component needs cloud or infrastructure API access. The choice affects routes, address capacity, scheduling, permissions, and recovery. Official documentation warns against casually changing IPAM mode on an existing cluster because existing workloads and routes depend on it. Use only a documented migration path; otherwise build a new cluster and move workloads deliberately.

Encapsulation versus native routing

In encapsulation mode, nodes tunnel cross-node traffic with a protocol such as VXLAN or Geneve. The underlying network needs ordinary node-to-node IP reachability and must allow the chosen tunnel port. It does not need to learn every PodCIDR. This reduces underlay integration complexity, but the additional header lowers effective MTU and consumes bandwidth. A blocked tunnel port or incorrect MTU can produce failures that look application-specific until same-node and cross-node paths are compared.

Native routing avoids the tunnel and delegates non-local forwarding to Linux and the surrounding network. The underlay must know how to reach PodCIDRs, either through directly connected routes, a router, cloud-native routing, or a route-distribution system. Native does not automatically mean simpler: it exchanges encapsulation overhead for routing responsibility. A strong answer names the prerequisite rather than calling one mode universally better.

Trace representative paths. A Pod's veth connects its namespace to the host. Cilium attaches programs at supported hooks, looks up endpoint identity and policy in maps, performs Service translation where needed, routes or encapsulates traffic, and generates visibility. L7 policy can redirect supported traffic to Envoy. Encryption can add processing at an appropriate layer. The exact path varies with same-node versus remote-node traffic, kube-proxy replacement, routing mode, socket acceleration, L7 policy, and encryption.

Domain 2: identity-based network policy

Kubernetes Pods are ephemeral. Their IP addresses change, but application intent often follows labels such as application, tier, environment, or service account. Cilium creates numeric security identities from relevant labels and distributes identity information so datapath policy can reason about workload identity rather than maintaining policy as a list of changing IP addresses. This is one of the most important concepts in the certification.

Identity is only as trustworthy and useful as the labels and governance behind it. If an untrusted team can assign a privileged label, a selector can become an authorization bypass. Label schemas, namespace ownership, admission, service accounts, and deployment permissions therefore belong in the policy threat model. Do not equate convenient identity derivation with complete identity governance.

Enforcement modes and per-direction isolation

In the default enforcement mode, endpoints begin without ingress or egress restrictions. When a policy selects an endpoint and defines a direction, that endpoint becomes default-deny for that direction, with matching allow rules reopening required flows. Ingress and egress are independent. A policy containing only ingress does not automatically isolate egress.

The always mode enables policy enforcement for all endpoints, including those not explicitly selected. This demands supporting rules for required infrastructure paths such as health checks. The never mode disables enforcement even when rules exist. That can aid narrow troubleshooting but represents a major security change and should never become an undocumented permanent workaround.

Allow policies are additive. If one rule permits a broad set and another permits a narrow set, the effective allow set is their union. There is no “most specific allow wins” rule that subtracts the broader permission. Review effective policy across every applicable resource. A perfectly written narrow CNP cannot compensate for an accidental allow-all elsewhere.

KNP, CNP, and CCNP

The standard Kubernetes NetworkPolicy offers portable L3/L4 constructs: Pod and namespace selectors, CIDR blocks, ports, protocols, ingress, and egress. Its meaning remains subject to the enforcing network implementation, but the API itself does not define HTTP methods, URL paths, DNS names, or Cilium-specific entities.

CiliumNetworkPolicy is namespace-scoped and extends the model with Cilium capabilities such as richer identity selection, supported Layer 7 protocol rules, DNS-aware and FQDN-based policy, entities, and other documented fields. CiliumClusterwideNetworkPolicy applies at cluster scope and supports cluster-level use cases, including relevant host or node selection. Choose the narrowest ownership scope that satisfies the requirement.

A rule selects the protected endpoint and defines ingress and/or egress allowances. Source and destination constructs may identify endpoints, namespaces, entities such as the world or host, CIDRs, services, or FQDNs depending on rule direction and resource type. Port rules constrain protocol and destination port. Supported L7 rule sections can constrain HTTP method and path, DNS queries, or other protocols. L7 enforcement generally introduces Envoy into the path, which means proxy readiness, certificates, resources, and telemetry become part of policy availability.

Default-deny egress frequently breaks DNS. The application reports a destination failure, but the first blocked packet is to the resolver. Allow the actual DNS endpoints over required UDP and TCP port 53, then permit only required destinations. If using FQDN policy, understand resolver observation, DNS TTL, wildcard semantics, IP reuse, and how the installed version represents DNS proxy behavior. Test DNS and the subsequent connection separately.

For troubleshooting, ask: Does the endpoint have the labels I think it has? Which numeric identity did Cilium assign? Which policy resources select it? Is the affected direction isolated? What source identity, destination identity, port, and verdict did Hubble observe? If L7 is involved, what did Envoy see? These questions are safer than disabling all policy and hoping the symptom disappears.

Domain 3: service mesh, Ingress, Gateway API, and encryption

Service mesh is not one feature. It combines service connectivity, traffic management, identity or policy, encryption, resilience, and observability. Cilium's architecture can provide many of these capabilities without injecting a sidecar into every application Pod. eBPF can steer and process traffic efficiently at kernel hooks, while a shared or node-level Envoy instance handles supported L7 functions. The precise statement is sidecarless, not universally proxyless.

Ingress and exposure modes

Cilium supports the standard Kubernetes Ingress API with ingressClassName: cilium. It can implement path-based routing and TLS termination. Current documentation requires kube-proxy replacement and an enabled L7 proxy for the Cilium Ingress controller. By default, generated exposure commonly uses a LoadBalancer Service, so a local cluster needs an implementation that supplies such addresses or an explicitly selected NodePort or supported host-network alternative.

Shared mode places multiple Ingress configurations behind shared load-balancer infrastructure, saving addresses and resources. Dedicated mode creates isolated load-balancer configuration for an Ingress, reducing some conflict and ownership concerns at higher resource cost. Changing the mode can allocate a new address and interrupt active connections. Treat it as a network migration, not a harmless annotation edit.

Why Gateway API matters

Gateway API was designed as a role-oriented successor to Ingress. A GatewayClass associates infrastructure with a controller. A Gateway represents listener infrastructure and policy boundaries. HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, and UDPRoute express protocol routes where supported. BackendTLSPolicy describes backend TLS expectations in supported versions. ReferenceGrant allows a target namespace to authorize a cross-namespace reference.

The role separation matters. A platform team can operate Gateways and listeners; an application team can own Routes in an allowed namespace. Listener allowedRoutes settings define which Routes may attach. A Route's parent status and conditions reveal whether the controller accepted it. A cross-namespace backend does not become trusted merely because a Route names it: the target side must explicitly grant the reference where the API requires it.

Do not memorize a static support matrix from a blog. Gateway API and Cilium evolve. Verify the installed Gateway API CRDs, Cilium release documentation, conformance profile, enabled controller, and conditions. A resource accepted by the Kubernetes API can still be rejected by the controller or remain unresolved.

Encryption claims require scope

Cilium supports transparent encryption for supported traffic using technologies such as WireGuard or IPsec. Configuration can protect traffic between managed endpoints and selected host traffic according to mode and version. Encryption does not authorize traffic; network policy still decides whether identities may communicate. TLS at a Gateway is also distinct from node-to-node transparent encryption and from service-to-service mutual authentication.

Validate rather than infer. Check node encryption state, key or peer health, routing mode, interfaces managed by Cilium, same-node versus cross-node paths, Pod versus host traffic, and external traffic. Use a packet capture only with synthetic data and at a legitimate lab observation point. State “the tested cross-node Pod path was encrypted” rather than “all cluster traffic is encrypted” unless every relevant scope has been proven and supported.

Domain 4: Hubble network observability

Hubble turns datapath events into network and security visibility. The embedded node server obtains eBPF-based flow information and offers a gRPC API and metrics. Relay connects to node servers and presents an aggregated API. The Hubble CLI queries that API, while the UI draws service relationships and recent flows. This division explains why Relay can fail while the Cilium data plane remains healthy.

After enabling Hubble and Relay, cilium status should report their state. Relay must reach node Hubble APIs; official setup guidance notes TCP port 4244 between relevant nodes. The CLI can use an automatically managed local port forward. hubble status confirms API health, flow buffer information, and connected nodes. Check the connected-node count: a working command with only part of the cluster connected is partial coverage.

hubble observe returns flows and supports filters. Filter by namespace, Pod, labels, protocol, port, verdict, or other supported fields to answer a defined question. For a policy incident, identify source and destination identities, direction, protocol, port, verdict, and drop reason. For service debugging, compare the requested Service, selected backend, DNS response, and return path. Preserve timestamps and version context.

Layer 7 visibility can show fields such as HTTP method, path, status, DNS query, or protocol-specific details when Cilium's supported L7 path can observe them. It may require policy or visibility annotations that redirect traffic through Envoy. End-to-end TLS is not automatically decrypted. More visibility can increase proxy load, cardinality, storage, and privacy exposure. Use a field allowlist and short retention in labs; do not place real credentials or personal data into requests.

The Hubble UI is excellent for learning dependencies. Its graph shows observed relationships in the selected namespace and time window. It does not prove that an unobserved path is impossible, that every displayed path is authorized by application logic, or that all cluster nodes are represented. Pair it with policy manifests, CLI filters, connected-node status, synthetic tests, and application evidence.

Domain 5: installation and configuration

Before installation, check current system requirements. Kernel, architecture, Kubernetes version, container runtime, cloud platform, kube-proxy mode, firewall, IPAM, routing, and existing CNI state affect the supported design. Pin a Cilium release and preserve the effective values. The most recent release is not automatically the correct release for a managed platform or organizational change window.

The Cilium CLI supports a default installation through cilium install, while Helm supports explicit chart-based lifecycle management. Whichever method you use, review what will change. A production configuration should not be reconstructed from command history after an incident. Store reviewed values, version them, and protect any credentials or certificates referenced by the deployment.

Use cilium status --wait to wait for and inspect Cilium, Operator, Envoy where enabled, Hubble Relay, and managed Pod readiness. Then run cilium connectivity test. The connectivity suite exercises a range of paths and features supported by the environment. A pass is strong evidence for those scenarios, but it is not proof for every application dependency. Add workload-specific DNS, Service, cross-node, ingress, egress, policy, and encryption tests.

After changes, compare effective configuration and rerun targeted and full regression tests. Avoid editing eBPF maps directly as a persistent fix: maps are runtime implementation state managed by the agent. If one node fails, start with scoped status, Pod and node events, agent logs, kernel and runtime compatibility, routes, and configuration. cilium sysdump can collect broad diagnostics, but that bundle may contain topology, logs, addresses, and other sensitive metadata. Restrict and delete it according to policy.

Domain 6: Cluster Mesh and global services

Cluster Mesh connects Cilium-managed clusters so selected workloads can communicate under identity-aware policy and Services can use backends across clusters. It can improve regional resilience and shared-service access, but it also joins failure and trust domains. Begin only after each cluster is healthy independently.

Use unique cluster names and numeric IDs. Plan Pod addressing so remote endpoints remain unambiguous, unless deliberately using a currently documented overlapping-CIDR mode with all its requirements. Confirm version compatibility, node and control endpoint reachability, required ports, certificates or authentication, and the selected Cluster Mesh architecture. Do not expose mesh APIs publicly merely for convenience.

A global service lets matching Service definitions discover and use healthy backends across connected clusters according to current configuration. Decide whether traffic should prefer local backends, balance across all clusters, or fail in a particular way. Give regional backends distinguishable synthetic responses during testing. Then stop one region, sever the mesh link, or remove a backend and measure continuity and convergence.

Cluster Mesh does not authorize all cross-cluster traffic. Cilium policy can distinguish endpoints and, where supported, cluster identity. Test approved and denied paths. If local Services work but remote backends disappear, inspect Cluster Mesh status, remote cluster connectivity, synchronized nodes and identities, global-service intent, and Hubble flows before rewriting the application.

Domain 7: eBPF without mythology

eBPF lets verified programs execute at defined Linux kernel hooks. Cilium uses hooks at points such as XDP, traffic control ingress and egress, cgroups, and sockets. Programs read context, call allowed helpers, and use maps to share state with userspace or other programs. The kernel verifier checks whether a program is safe to load under its model, and a JIT compiler can translate bytecode into architecture-specific instructions.

XDP runs very early in packet receive processing and is suitable for efficient filtering. Traffic-control hooks on interfaces offer packet and metadata access useful for endpoint policy, redirect, and forwarding. Cgroup and socket hooks support additional service and socket-layer acceleration. You do not need to write these programs for CCA, but you should understand why hook placement affects performance and available context.

Cilium composes maps and programs into higher-level functions. Identity and policy maps help enforce L3/L4 decisions. Service maps map virtual Services to backends. Connection-tracking and NAT maps maintain flow state. The IP cache relates addresses to identities and metadata. L7 policy can redirect traffic to Envoy. Hubble receives visibility linked to these datapath outcomes.

Compared with relying only on long iptables chains, map lookups and programmable hooks can improve scalability, enable earlier processing, integrate Service load balancing, and expose richer flow context. This is not “free networking.” Programs and maps consume CPU and memory. Map capacity is bounded. Kernel compatibility matters. Agent rollout and state reconciliation matter. Envoy remains involved for supported L7 processing.

The verifier does not prove that a policy implements business intent, that a selector is correct, that map capacity is sufficient, that every packet was observed, or that configuration is secure. Keep semantic policy tests, negative connectivity tests, Hubble evidence, map-pressure monitoring, and upgrade regression tests.

Domain 8: BGP and external networking

Kubernetes Services and Pod networks eventually need to communicate with the surrounding network. Cilium provides several options depending on requirements: native routing, load-balancer address management, BGP advertisements, NodePort or LoadBalancer Services, Gateway or Ingress exposure, and Egress Gateway for selected outbound traffic. Start from who must reach what, which source and destination addresses must be visible, and where route ownership lives.

The Cilium BGP Control Plane establishes sessions with external peers and advertises selected reachability according to its current resources and policy model. Common use cases include PodCIDR and Service-address advertisements. BGP is a control plane: it exchanges route information. Linux and the network datapath forward the packets. A healthy BGP session does not prove that a route was accepted upstream or that return routing and policy are correct.

Validate peer address, local and peer ASN, timers, session state, address family, and authentication where supported. Inspect exactly which prefixes Cilium advertises and which prefixes the router accepts and installs. Use prefix filters and a private isolated lab ASN. Test reachability, then stop a peer or node and verify route withdrawal and reconvergence. An accidental default route or production prefix advertisement is not a harmless lab mistake.

Egress Gateway solves a different problem: selected Pods can send traffic through designated gateway nodes and present controlled source addresses to external systems. This supports external allowlists and audit requirements. Select both sources and destination CIDRs narrowly, plan gateway node availability, understand SNAT and routing behavior, combine the feature with egress policy, and test gateway loss. Hubble Relay is not a NAT gateway, and hostNetwork is not a safe substitute.

Three projects that make the domains concrete

The CCA project collection contains three substantial labs with at least nine steps each. The first installs and validates Cilium, captures architecture evidence, enables Hubble, diagnoses DNS, MTU, and Relay failures, measures cost, and removes the cluster. It connects Architecture, Installation, Observability, and eBPF rather than treating them as separate flashcards.

The second lab creates a synthetic frontend, API, and payments service. It starts with default-deny, compares KNP and CNP, adds HTTP-aware controls, deploys Gateway API resources under separate platform and application ownership, validates sidecarless data flow and transparent encryption scope, and injects selector, DNS, route, certificate, Envoy, and encryption faults.

The third lab connects two clusters with Cluster Mesh, publishes a global service, applies cross-cluster policy, peers with an isolated software router, advertises only private test prefixes, and assigns one workload to an Egress Gateway. It then breaks the mesh, remote backend, BGP peer, route, and gateway node and requires observable withdrawal, bounded failure, documented recovery, cost review, and complete teardown.

An eight-week blueprint-weighted plan

Use the CCA roadmap as the weekly checklist. Use 40 CCA flashcards for spaced retrieval. Complete all 50 original practice questions under a 90-minute timer at least once, but do not optimize for option letters. Explain why the correct answer fits the described layer and why every distractor belongs to another component or violates a prerequisite.

Multiple-choice reasoning strategy

First classify the layer. Is the scenario about Pod network setup, kernel datapath, cluster-wide reconciliation, L7 proxying, flow aggregation, multi-cluster discovery, or external route exchange? Component questions become easier when each noun has one primary job. Hubble observes; it does not enforce. BGP advertises routes; it does not authorize HTTP. The Operator reconciles cluster-wide state; it does not process every packet.

Second identify direction and scope. Ingress and egress policy are independent. CNP is namespaced, while CCNP is cluster-wide. Hubble Server is node-local, while Relay aggregates. Ingress and Gateway API provide north-south routing, while Cluster Mesh connects cluster domains. Transparent encryption has a tested scope; it is not equivalent to every form of TLS or mTLS.

Third look for the prerequisite. Native routing requires PodCIDR reachability. Encapsulation requires node reachability and allowed tunnel traffic. L7 policy requires a proxy path. Relay requires connectivity to node Hubble servers. Gateway resources require compatible CRDs, controller support, and accepted conditions. BGP requires an established peer and accepted advertisements. A correct feature with a missing prerequisite is not a complete answer.

For multi-select, evaluate each option independently, then ensure the selected set is internally consistent. Words such as “always,” “automatically,” “all traffic,” and “zero overhead” often hide an overclaim. Cilium has powerful automation, but networking remains bounded by kernel, addressing, route, policy, proxy, certificate, and external infrastructure state.

Common CCA preparation mistakes

• Memorizing commands without architecture. A command is useful only when you know which component and state it affects.
• Treating an IP as workload identity. Cilium policy is built around label-derived security identities, while IP-to-identity mapping remains datapath state.
• Assuming policy priority. Allow rules are additive; a broad permission is not canceled by a later narrow rule.
• Forgetting direction. Ingress isolation and egress isolation are separate, and DNS commonly becomes the first egress dependency.
• Calling sidecarless proxyless. Envoy still handles supported L7 processing even when application Pods have no sidecar.
• Equating Hubble with enforcement. Hubble reports what the datapath observed; policy and proxy components make enforcement decisions.
• Assuming Cluster Mesh means allow-all. The mesh supplies reachability and shared information; policy still controls authorization.
• Checking only BGP session state. Inspect advertisements, accepted routes, forwarding, return path, withdrawal, and reconvergence.
• Changing IPAM casually. Endpoint addressing is foundational; unsupported in-place changes can cause persistent disruption.
• Studying old screenshots. Cilium APIs, Helm values, Gateway support, and exam details change; use stable current documentation.
• Using production for practice. CNI, BGP, route, encryption, and egress experiments can disrupt real traffic.
• Using dumps. Recalled content violates exam integrity and produces brittle knowledge with no troubleshooting skill.

A practical readiness checklist

• Explain every core component and failure boundary without notes.
• Draw encapsulated and native-routed cross-node paths, including policy and optional L7 processing.
• Select an IPAM model from infrastructure requirements and explain why an in-place change is dangerous.
• Predict effective ingress and egress behavior across multiple additive KNP, CNP, and CCNP rules.
• Explain GatewayClass, Gateway, Route, ReferenceGrant, and relevant status conditions.
• Use cilium status, connectivity tests, Hubble CLI, Hubble UI, logs, and scoped diagnostics appropriately.
• Explain eBPF hooks, maps, verifier limits, and why map capacity matters.
• Design Cluster Mesh prerequisites and global-service tests without assuming authorization.
• Validate BGP peer, prefixes, external route installation, withdrawal, and data-plane return path.
• Complete all three labs and preserve failure and cleanup evidence.
• Score consistently across all eight blueprint domains rather than relying on one strong area.
• Recheck official exam details and stable documentation during the final week.

Official references

• Linux Foundation — Cilium Certified Associate (CCA)
• Linux Foundation Certification Candidate Handbook
• Linux Foundation multiple-choice exam instructions
• CNCF public CCA curriculum repository
• Cilium component overview
• Cilium IP address management
• Cilium routing modes
• Cilium policy introduction and enforcement modes
• Cilium service mesh
• Cilium Gateway API support
• Kubernetes Gateway API documentation
• Cilium transparent encryption
• Hubble observability documentation
• Install Cilium with the Cilium CLI
• Cilium Cluster Mesh
• Cilium eBPF datapath documentation
• eBPF documentation
• Cilium BGP Control Plane
• Cilium Egress Gateway

Continue CCA preparation

• Eight-week CCA roadmap
• 50 original CCA practice questions
• 40 CCA flashcards
• Three CCA portfolio projects
• Certified Kubernetes Administrator roadmap
• PrepKloud certification and engineering guides
• PrepKloud editorial policy

Frequently asked questions