CCA — the exam

The Cilium Certified Associate (CCA) is the CNCF and Linux Foundation's associate-level badge for Cilium — the eBPF-powered networking, security and observability layer that has replaced iptables as the data plane under a growing share of Kubernetes clusters. It's a knowledge-based, ninety-minute, remote-proctored multiple-choice exam: no terminal, no live cluster, just Cilium's architecture, its CiliumNetworkPolicy custom resource, its Hubble observability stack and its Cluster Mesh multi-cluster story, tested by name rather than by concept. On the Golden Kubestronaut ladder it's one of nine project-specific associates, and it sits directly beside the Kubernetes networking & CNI material this course assumes but does not re-teach — CCA goes far deeper into one specific CNI than any Kubernetes exam does. This page lays out the eight official domains and weights exactly as the CNCF publishes them, works through the substance behind each with a real, identity-based CiliumNetworkPolicy, and separates what the official pages state with confidence from what they don't.

What the CCA is, and who it's for

☺ Like you're 10: It's a multiple-choice test about one tool — the smart network layer under a cluster. Nobody watches you type; they watch what you already know.

CCA is knowledge-based: an online, remote-proctored, multiple-choice sitting. There's no cluster to drive and no kubectl to type — the exam tests whether you can read a CiliumNetworkPolicy and say exactly what it permits, and explain why an eBPF datapath behaves differently from an iptables one, without a terminal in front of you. That makes it the odd one out next to the five core Kubernetes certifications this course assumes and does not re-teach — covered in full over in Kubernetes — which are almost all performance-based, live-cluster exams.

The scope is narrow and named: one project, not a discipline. You're expected to know Cilium's component names, its CRDs, its CLI verbs and its Hubble query syntax by heart. That's a sharper contrast than it sounds — CGOA, this ladder's other associate exam most people take nearby, tests the vendor-neutral GitOps specification, while CCA tests one specific implementation of one specific layer down to its flag names.

It suits platform engineers running Cilium as the cluster CNI who own the blast radius when policy goes wrong; network engineers moving from VLANs and firewalls into Kubernetes, where the same job has new names; SREs who want Hubble to answer "is the network dropping this?" instead of reaching for tcpdump; and security engineers writing micro-segmentation who need the identity model and the three enforcement modes cold. If Kubernetes itself is still new to you, read The Kubernetes Baseline You Need first — CCA assumes you already know what a Service and a NetworkPolicy are.

The eight official domains & their weights

☺ Like you're 10: The test has eight parts and they're not equal — how it's built and how the rules work are worth more than a third of the whole grade combined.

These come straight from the CNCF's published Cilium Certified Associate (CCA) Exam Curriculum — domain names, percentages and competency lists are that document, not a paraphrase. Bars are drawn to scale against the largest domain:

Every competency, domain by domain

Eight domains, twenty-seven competencies, exactly as the CNCF publishes them — the weights below sum to 100%:

Notice the shape before you plan a study schedule. Architecture and Network Policy are 38% together — components, IPAM, datapath models, identities and rule structure — and both are comprehension, not kernel depth. eBPF is only 10%, which surprises people who disappear into kernel internals for a week; its three competencies are answerable in prose, and you never write a BPF program by hand. And Service Mesh at 16% outweighs eBPF, Observability and Cluster Mesh — candidates who study "Cilium the CNI" and skip "Cilium the mesh" give away a sixth of the paper.

Architecture, IPAM & the datapath — the 20%

☺ Like you're 10: This is knowing the factory floor — which robot does which job, and how each pod gets its own mailbox address.

Know the components first; every other Architecture competency hangs off them. cilium-agent runs as a DaemonSet, one per node — it watches the Kubernetes API, computes security identities, and programs the eBPF maps that enforce policy for its own node's pods. cilium-operator runs once per cluster and handles the work that must not be duplicated per node: cluster-pool IPAM allocation and garbage-collecting stale CiliumIdentity and CiliumEndpoint objects. Hubble is embedded directly in the agent, with hubble-relay aggregating flows cluster-wide and hubble-ui rendering a live service map. A per-node Envoy proxy — one per node, not one per pod — handles any policy that needs Layer 7 parsing. The clustermesh-apiserver exposes a cluster's identities and services to its peers when Cluster Mesh is enabled.

Then the two configuration axes the curriculum calls out by name. IPAM mode decides where pod addresses come from: kubernetes mode reuses each Node's PodCIDR, cluster-pool (the default) has the operator carve per-node blocks out of one cluster-wide pool, and eni / azure hand pods real, routable addresses straight from the cloud provider's network. Routing mode decides how packets leave a node: tunnel encapsulates them in VXLAN or Geneve, working anywhere at a small MTU cost, while native routing skips encapsulation entirely and relies on the underlay already knowing how to route your PodCIDRs.

eBPF — the 10% that explains almost everything else

☺ Like you're 10: This is why the floor-tile trick beats the clipboard. One lookup instead of reading down a growing list.

eBPF attaches small, kernel-verified programs to hooks in the network stack — the driver (XDP), traffic control (tc), the socket layer — with no kernel module to load and no reboot required. A verifier proves each program is safe before it runs, a JIT compiler turns it into native machine code, and eBPF maps hold the shared state those programs read and write: endpoints, identities, service backends, policy verdicts. That's the whole role of eBPF in Cilium in one sentence — it is the mechanism that lets policy and load-balancing decisions happen inside the kernel, at line rate, without a userspace hop.

Now the comparison the domain is actually testing: why eBPF beats iptables at scale. iptables enforces policy as a linear chain of rules — a packet is compared against rule 1, then rule 2, then rule 3, until something matches — and Kubernetes grows that chain with every Service and every NetworkPolicy a cluster accumulates. On a cluster with thousands of Services, that chain gets long, and every packet pays for the rules ahead of the one it needs, while every Service change forces the kernel to reload the whole ruleset. eBPF's maps are hash tables: a lookup by identity or destination is closer to constant time regardless of how many other rules or Services exist, and updating one map entry never touches the others. Cilium can go one step further with socket-level load balancing — rewriting a Service's virtual IP to a real pod IP right at the socket, before a packet is even built — which is what kubeProxyReplacement is for, and something a chain-of-rules model has no equivalent of.

That's also the shape of the deep-dive on this course if you want a second pass with more kernel detail: eBPF & the Cilium Datapath.

Network Policy — the identity-based 18%

☺ Like you're 10: The rulebook is written about backpack colours, not exact desks — so it still works after everyone changes seats.

Cilium derives a numeric security identity from a pod's labels. Every pod sharing those labels shares one identity, and it's the identity — never the pod IP — that travels with a flow and is what policy is written against. That's precisely why policy survives autoscaling and rescheduling: a pod's IP can change every few minutes, but its labels, and therefore its identity, stay stable.

Learn the policy rule structure as a fixed skeleton: an endpointSelector names which pods the policy protects, then ingress and egress lists each pair a peer selector with allowed ports. Peers can be fromEndpoints/toEndpoints by label, fromEntities/toEntities for the special built-in sets (world, cluster, host, remote-node, kube-apiserver), toCIDR for raw address ranges, or toFQDNs for egress by hostname. toPorts can carry an L7 rules block for http, dns or kafka, which is what routes that traffic through the per-node Envoy for parsing.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: mission-control-api
  namespace: prod
spec:
  endpointSelector:                   # WHICH pods this policy protects
    matchLabels:
      app: mission-control-api
  ingress:
    - fromEndpoints:                  # WHO may call — by LABELS, never by IP
        - matchLabels:
            app: cadet-dashboard
            io.kubernetes.pod.namespace: prod
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:                     # L7: parsed by the per-node Envoy proxy
              - method: "GET"
                path: "/v1/roster/[0-9]+"
              - method: "POST"
                path: "/v1/launch-status"
    - fromEntities: [ cluster ]       # allow kubelet probes & in-cluster scrapers
      toPorts:
        - ports: [{ port: "9090", protocol: TCP }]
  egress:
    - toEndpoints:                    # DNS FIRST — or toFQDNs can never resolve
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports: [{ port: "53", protocol: ANY }]
          rules:
            dns: [{ matchPattern: "*" }]
    - toFQDNs:                        # egress by hostname, not by IP range
        - matchName: "api.spacex-telemetry.example"
      toPorts:
        - ports: [{ port: "443", protocol: TCP }]

That one manifest is identity-based twice over — the endpointSelector picks the protected pods by label, and every fromEndpoints/toEndpoints peer is also a label selector, never an IP. It also demonstrates the domain's last competency: Cilium enforces a plain Kubernetes NetworkPolicy faithfully, then adds what that spec cannot express — L7 rules, toFQDNs hostname egress, entity selectors, explicit ingressDeny/egressDeny, and a cluster-scoped CiliumClusterwideNetworkPolicy for platform-wide baselines that no single team can override.

The three policy enforcement modes complete the domain: default (an endpoint allows everything until some policy selects it, at which point that direction becomes default-deny), always (default-deny everywhere from the start) and never (not enforced at all).

Service Mesh — Ingress, Gateway API & sidecarless — the 16%

☺ Like you're 10: Getting traffic from outside in, and moving it around safely once it's inside, without giving every pod its own personal traffic guard.

Cilium's mesh is sidecarless: because the datapath already inspects every packet to enforce policy, L4 mesh functions need no per-pod proxy at all, and the per-node Envoy only runs — once per node — when an L7 rule needs it to. Against a sidecar-based mesh like Istio, that means no injection webhook, no per-pod memory and CPU tax, and no startup-ordering races between an app container and its sidecar — traded against a thinner L7 feature set and a proxy whose blast radius is the node rather than a single pod. Know both sides of that trade; the curriculum names the comparison directly, and ICA, this course's Istio cert, is the place to go deep on the sidecar side.

North-south, Cilium ships an Ingress controller (ingressClassName: cilium) and a Gateway API implementation (a GatewayClass named cilium). The curriculum specifically wants the benefits of Gateway API over Ingress: it's role-oriented — GatewayClass, Gateway and HTTPRoute split cleanly between the infrastructure provider, the cluster operator and the application developer, each with its own RBAC; it's expressive by specification, with header, method and weighted routing built into the API instead of bolted on as vendor annotations; it's portable across implementations; and it's extensible without annotation sprawl. Service mesh use cases worth knowing: east-west traffic encryption, per-hop observability, canary and blue/green traffic splitting at L7, and multi-cluster routing once Cluster Mesh is in the picture.

For traffic in transit, Cilium encrypts node-to-node transparently — a configuration change, not an application change — with either WireGuard (simple, fast, a good default) or IPsec (older, more configuration knobs, sometimes required for FIPS compliance).

Network Observability — Hubble — the 10%

☺ Like you're 10: The hallway monitor was already watching everyone go by, so showing you the guest list afterwards costs almost nothing extra.

Because the agent already inspects every packet to enforce policy, exporting what happened and why is nearly free: source and destination identity, port, protocol, verdict (FORWARDED, DROPPED, AUDIT) and a drop reason when applicable. hubble-relay aggregates every node's local flows into one cluster-wide API, the hubble CLI queries it directly, and hubble-ui renders a live service map you can click through during an incident. See Hubble for the full tool guide, and Service Mesh Architecture for how it fits the wider mesh picture.

L7 visibility is not on by default. A flow is only parsed above Layer 4 when a policy attaches an L7 rules block to it, which is exactly what routes that traffic through the per-node Envoy. To gain visibility without narrowing what's allowed, write rules that match everything — http: [{}], dns: [{ matchPattern: "*" }] — so traffic keeps flowing while Hubble starts reporting methods, paths and status codes on top of it.

# The single most useful command in an incident: every dropped flow, live
hubble observe --verdict DROPPED -f
# prod/cadet-dashboard-7d9f:52344 -> prod/mission-control-api-6b4c:8080 \
#   Policy denied DROPPED (TCP Flags: SYN)          <-- identities, not just IPs

hubble observe --pod prod/cadet-dashboard --last 50                 # scope it down
hubble observe --type l7 --protocol http --http-status 403          # L7 verdicts
hubble observe --to-fqdn "api.spacex-telemetry.example"             # did toFQDNs resolve?
hubble status                                                       # is relay seeing every node?

Installation, Cluster Mesh & reaching the outside world — the remaining 26%

☺ Like you're 10: The last three sections cover setting the whole thing up, joining two clusters together, and letting traffic leave the building safely.

Installation and Configuration — 10%

The exam is multiple-choice, so recognise the verbs rather than drilling every flag. cilium install stands the whole thing up, cilium status --wait confirms agents, operator and Hubble came up healthy, and cilium connectivity test runs a full pod-to-pod, pod-to-service, DNS, egress and policy check in one shot. Configuration reads and writes go through the same CLI, and a cilium sysdump bundles everything support will ask for into one archive.

# Install / upgrade / prove it works — always pin a version
cilium install --version 1.18.0
cilium status --wait               # agents, operator, Hubble: all OK?
cilium connectivity test           # pod-to-pod, pod-to-service, DNS, egress, policy

# Query and MODIFY configuration (edits the cilium-config ConfigMap and restarts
# agents — on a GitOps-managed cluster, change the Helm values file instead)
cilium config view
cilium config set enable-l7-proxy true
cilium sysdump                     # one archive with everything support will ask for

Cluster Mesh — 10%

Cluster Mesh gives pod-to-pod connectivity, shared identities and merged service endpoints across clusters — a policy written once means the same thing everywhere it's meshed, and a Service can fail over to another cluster without a separate global load balancer in front of it. Its hard requirements are exam favourites: a globally unique cluster name and cluster ID for every participating cluster, and strictly non-overlapping PodCIDRs between them. Making a Service global is one annotation, applied to a Service of the same name and namespace in each meshed cluster:

cilium clustermesh enable  --context orbit-west --service-type LoadBalancer
cilium clustermesh connect --context orbit-west --destination-context orbit-east
cilium clustermesh status  --context orbit-west --wait

apiVersion: v1
kind: Service
metadata:
  name: mission-control-api
  namespace: prod
  annotations:
    service.cilium.io/global: "true"      # merge endpoints from ALL meshed clusters
    service.cilium.io/affinity: "local"   # prefer local backends; fail over if none ready
spec:
  type: ClusterIP
  selector: { app: mission-control-api }
  ports: [{ port: 8080, targetPort: 8080 }]

BGP and External Networking — 6%

Two competencies live here: egress requirements, and connecting a Cilium-managed cluster to the world outside it. Pods leaving the cluster are normally masqueraded behind their node's IP — fine until a partner's firewall wants a stable, allowlistable source address, which is exactly what an egress gateway solves: route selected pods' external traffic through designated nodes so it always leaves from one known address. Inbound, Cilium's BGP control plane peers with real routers and advertises PodCIDRs and LoadBalancer VIPs directly, so on-prem clusters get properly routed addresses without an overlay network — the same job MetalLB does, folded straight into the CNI.

Exam logistics — and how to verify them

☺ Like you're 10: It's an online test you take from home with someone watching through your webcam. Prices and timings change, so always check the official page before you pay.

Some facts about the CCA are structural and safe to state; others are exactly the sort the Linux Foundation revises without announcement. This table separates them deliberately, and this is an independent, unofficial study resource — not affiliated with the CNCF or The Linux Foundation.

↗ Official CCA page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository ◆ Cilium documentation ◆ ebpf.io — the eBPF primer

Where it sits — and what to study next

☺ Like you're 10: This is a small, specialised badge. From here you either go deeper into one thing, or wider across the other badges.

CCA sits on the associate rung beside CGOA, CAPA and CBA — none of them gate each other, and CCA is the most specialised of the set, going deeper into one project than any other associate exam on this ladder goes into anything. The certifications overview lays out the whole shelf, and the CCA study plan turns everything above into a day-by-day pace, backed by a practice question bank and two timed papers, Mock Exam · Set 1 and Set 2.

If you want the fuller comparison against Platform Engineering's own CNPE exam — where this same material reappears as part of the Architecture and Security domains rather than as a standalone credential — Platform Engineering's CCA page is the deeper cross-reference; it maps every domain here to a lesson on that site. And for the Kubernetes fundamentals CCA assumes without teaching, the sibling Kubernetes course covers the CNI contract in full in Networking & the CNI and its own Cilium tool page, written from inside a running cluster rather than as an exam curriculum. To build rather than just study, put a Cilium install under GitOps as a reviewed values file, publish a default-deny CiliumClusterwideNetworkPolicy baseline every team inherits, and wire Hubble metrics into a dashboard so drops are visible before they're tickets — the mesh-namespace drill on this course is a guided first pass at exactly that.