CCA — Cilium Certified Associate

The Cilium Certified Associate (CCA) is the CNCF and Linux Foundation’s associate credential for the layer almost nobody on a platform team fully owns: the data plane. It asks how Cilium uses eBPF to move packets, how label-derived identities replace IP addresses as the unit of security, how Hubble makes east-west traffic visible, and how Cluster Mesh joins clusters. Here: what it is, whether it is worth your money, the eight official domains and weights from the CNCF curriculum, the substance behind each, and a study plan built from lessons already on this site.

What the CCA is — and who it is for

☺ Like you’re 10: It’s an online multiple-choice test about one tool — the smart network a Kubernetes cluster runs on. No cluster, no typing commands.

The CCA is knowledge-based: multiple-choice questions in an online, remote-proctored session, with no terminal and no live cluster. That shapes how you study — you need to read a CiliumNetworkPolicy and say exactly what it permits, and explain why an eBPF datapath behaves differently from an iptables one, without a cluster in front of you. That is the associate pattern across the board: KCNA, KCSA, CGOA, CNPA and CCA are all knowledge-based multiple-choice papers, while CKA, CKAD, CKS and the CNPE are performance-based sittings on a live cluster. Do not walk into the CCA braced for a terminal.

Project-specific, not vendor-neutral

Most CNCF exams test a concept: CGOA tests a specification, KCNA tests Kubernetes broadly. The CCA tests Cilium by name — its CRDs, its CLI verbs, its component names. That makes it unusually concrete and unusually learnable, and it makes the badge exactly as portable as the project, which — Cilium being a CNCF-graduated project and the datapath underneath several managed Kubernetes offerings, GKE’s Dataplane V2 among them — is portable enough.

Who should sit it

• 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 jobs have new names.
• SREs who want Hubble to answer “is the network dropping this?” instead of tcpdump.
• Security engineers writing micro-segmentation who need the identity model and enforcement modes cold.
• CNPE candidates shoring up the networking half of Domain 1 and the segmentation half of Domain 5.

Why a platform engineer would take it — and when to skip it

☺ Like you’re 10: Learning the corridors makes you the person who can explain outages nobody else can. But if you don’t run these corridors, the badge is mostly decoration.

Networking is where platform incidents go to become mysteries. A pod cannot reach a database — is it DNS, a policy, a Service, an EndpointSlice, MTU, or the application? People who understand the data plane resolve that in minutes; everyone else escalates. Studying for the CCA forces that whole chain into your head at once — the chain in Triage: Networking — which is leverage whether or not you ever display the badge.

The overlap with the CNPE

The CNPE never names Cilium, but its Architecture domain covers cluster networking and multi-tenancy and its Security domain covers segmentation and mTLS — and Cilium is a canonical answer to both. Everything here transfers to Networking & Connectivity, Security & Policy and Multi-cluster, and onward to CNPA. It also makes the Kubernetes track feel small: CKA asks you to fix a Service, CKS asks you to write a default-deny policy.

When to skip it

Skip it if you don’t run Cilium and have no plan to — read the networking lesson for the concepts and spend the money elsewhere. Skip it if you need one badge for a job filter; CKA is what recruiters screen on. Skip it if you already operate Cilium in anger — it will teach you vocabulary, not skill. And if Kubernetes itself is still new, do KCNA or the substrate lesson first: CCA assumes you know what a Service and a NetworkPolicy are. The certifications overview shows where it really sits.

The eight official domains & their weights

☺ Like you’re 10: The test has eight parts and they are not equal. How the thing is built, and how the rules work, are nearly four-tenths of it between them.

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

Reading the shape of this blueprint

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 fortnight; the three competencies are answerable in prose and you never write a BPF program. And Service Mesh at 16% is bigger than eBPF, Hubble or Cluster Mesh: candidates who study “Cilium the CNI” and skip “Cilium the mesh” give away a sixth of the paper.

What you actually need to know

☺ Like you’re 10: Here’s the substance — how the kernel does the work, how the doors decide, how you watch the corridors, and how two clusters get joined.

eBPF, the components, and the datapath

eBPF attaches small, verified programs to kernel hooks — the driver (XDP), traffic control (tc), the socket layer — with no kernel module and no reboot. A verifier proves each program safe, a JIT compiles it to native code, and eBPF maps hold the shared state: endpoints, identities, service backends, policy verdicts. Against iptables, which walks a linear chain per packet and grows that chain with every Service, eBPF gives effectively constant-time hash lookups and incremental updates — and can shortcut the stack entirely with socket-level load balancing. That is why kubeProxyReplacement exists.

Know the components. cilium-agent (DaemonSet, every node) watches the API, computes identities and policy, and programs the eBPF maps for its node’s endpoints. cilium-operator (once per cluster) does the non-per-node work: cluster-pool IPAM allocation and garbage-collecting stale CiliumIdentity and CiliumEndpoint objects. Hubble is embedded in the agent, with hubble-relay aggregating flows cluster-wide and hubble-ui drawing the service map; a per-node Envoy handles L7 rules — per node, not per pod; the clustermesh-apiserver exposes a cluster to its peers. Then the two config axes: IPAM mode (kubernetes uses each Node’s PodCIDR; cluster-pool, the default, has the operator carve per-node blocks from a cluster pool; eni and azure hand pods real VPC addresses) and routing mode (tunnel, encapsulating in VXLAN or Geneve at an MTU cost, versus native, where the underlay already routes your PodCIDRs).

Identity-based policy and the rule structure

Cilium derives a numeric security identity from a pod’s labels. Every pod sharing those labels shares one identity, and the identity — not the pod IP — travels with the flow and is what policy is written against, which is why policy survives autoscaling. Learn the rule structure as a fixed skeleton: an endpointSelector (which pods are protected), then ingress/egress entries, each pairing a peer selector — fromEndpoints/toEndpoints by label, fromEntities/toEntities for the special sets (world, cluster, host, remote-node, kube-apiserver), toCIDR, or toFQDNs by hostname — with toPorts, optionally carrying L7 rules for http, dns or kafka.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payments-api
  namespace: prod
spec:
  endpointSelector:                 # WHICH pods this policy protects
    matchLabels:
      app: payments
  ingress:
    - fromEndpoints:                # WHO may call — by LABELS, never by IP
        - matchLabels:
            app: checkout
            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/balance/[0-9]+"
              - method: "POST"
                path: "/v1/charge"
    - 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.stripe.com"
      toPorts:
        - ports: [{ port: "443", protocol: TCP }]

Cilium enforces plain Kubernetes NetworkPolicy faithfully and adds what it cannot express: L7 rules, toFQDNs hostname egress, entity selectors, explicit ingressDeny/egressDeny, and a cluster-scoped CiliumClusterwideNetworkPolicy for platform baselines. The three policy enforcement modes complete the domain: default (an endpoint allows everything until a policy selects it, at which point that direction becomes default-deny), always (default-deny everywhere from the start) and never (not enforced).

Service mesh: Ingress, Gateway API, encryption, sidecarless

Cilium’s mesh is sidecarless: the datapath already sees every packet, so L4 mesh functions need no per-pod proxy, and Envoy runs once per node, only when an L7 rule requires parsing. Against a sidecar architecture that means no injection webhook, no per-pod CPU and memory tax and no startup-ordering bugs — at the cost of a thinner L7 feature set and a proxy whose blast radius is the node rather than the pod.

North-south, Cilium offers an Ingress controller (ingressClassName: cilium) and a Gateway API implementation (a GatewayClass named cilium, CRDs installed first). The curriculum wants the benefits of Gateway API over Ingress: it is role-oriented — GatewayClass, Gateway and HTTPRoute split between infrastructure provider, cluster operator and application developer, each with its own RBAC; expressive by specification, with header, method and weighted routing in the API instead of vendor annotations; portable across implementations; and extensible without annotation sprawl. For traffic in transit, Cilium encrypts node-to-node transparently with WireGuard (simple, fast) or IPsec (older, more knobs, FIPS-relevant) — a configuration change, not an application change.

Hubble and Layer 7 visibility

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 drop reason. hubble-relay aggregates node-local flows into one cluster-wide API, the hubble CLI queries it, the UI renders a live service map, and Hubble metrics feed Prometheus and Grafana. L7 visibility is not on by default — a flow is only parsed above L4 when a policy attaches L7 rules to it, which is what steers it through the Envoy proxy. To gain visibility without narrowing what is allowed, write rules that match everything — http: [{}], dns: [{ matchPattern: "*" }] — so traffic still passes while Hubble starts reporting methods, paths and status codes. (Older Cilium releases had a pod annotation for this; annotation-based visibility was removed in Cilium 1.15, so the policy form is the current answer.)

# The most useful command in an incident: every dropped flow, live
hubble observe --verdict DROPPED -f
# prod/checkout-7d9f:52344 (ID:4211) -> prod/payments-6b4c:8080 (ID:7788) \
#   Policy denied DROPPED (TCP Flags: SYN)     <-- identities, not just IPs

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

And the visibility policy itself — permissive L7 rules whose only job is to make Envoy parse the traffic. Note the catch the exam likes: this policy selects the pod, so that direction becomes default-deny and the policy must list everything the pod is allowed to reach, DNS included.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: checkout-l7-visibility
  namespace: prod
spec:
  endpointSelector:
    matchLabels:
      app: checkout
  egress:
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports: [{ port: "53", protocol: ANY }]
          rules:
            dns: [{ matchPattern: "*" }]     # every lookup, visible
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: prod
      toPorts:
        - ports: [{ port: "8080", protocol: TCP }]
          rules:
            http: [{}]                       # match ALL HTTP: parse, don't narrow

The CLI, Cluster Mesh and the way out of the cluster

Two 10% domains and one 6% domain live here. The exam is multiple-choice, so recognise the verbs rather than drilling flags.

# Install / upgrade / prove it works — always pin a version
cilium install --version <x.y.z>
cilium status --wait              # agents, operator, Hubble: 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
cilium clustermesh enable  --context eu-west --service-type LoadBalancer
cilium clustermesh connect --context eu-west --destination-context us-east
cilium clustermesh status  --context eu-west --wait

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

apiVersion: v1
kind: Service
metadata:
  name: payments
  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: payments }
  ports: [{ port: 8080, targetPort: 8080 }]

For BGP and external networking, the two competencies are egress requirements and how to reach the world outside. Pods leaving the cluster are normally masqueraded behind their node’s IP — fine until a partner firewall wants a stable, allowlistable source, which is what an egress gateway is for: route selected pods’ external traffic through designated nodes so it always leaves from a known address. Inbound, Cilium’s BGP control plane peers with physical routers and advertises PodCIDRs and LoadBalancer VIPs, so on-prem clusters get real routed addresses without an overlay — MetalLB’s job, folded into the CNI.

How to prepare using this site

☺ Like you’re 10: Nearly every part of this test already has a page here. Read them in weight order and you’ve read the syllabus.

Study in weight order — Architecture and Network Policy first, because they are 38% and because everything else assumes them.

Domain-by-domain study map

A two-week pace

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 page separates them.

What we can state with confidence

The moving parts — and what the official page said when this was written

The figures that move are duration, question count, pass mark, price, retake policy, eligibility window and certification validity. Everything in the table below is taken from the Linux Foundation’s own CCA product page — attributed, not remembered — and where that page publishes nothing, this one says so rather than inventing a number.

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

Where it sits in the ladder — and what to do next

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

CCA sits on the associate rung beside KCNA, KCSA, CGOA and CNPA. None of them gate anything, and CCA is the most specialised of the set — it goes deeper into one project than any other associate exam goes into anything. The certifications overview lays out the whole shelf.

Go deep — the CNPE, or the security track

The platform sequel is the CNPE, where this material reappears as the networking content of Domain 1 and the segmentation and mTLS content of Domain 5. Start with the lab track, then the practice task bank, then a timed mock exam, with Know It Cold open while you drill. If policy is what hooked you, CKS is the hands-on version of the same instinct.

Go wide, or go build

To broaden, CKA remains the badge that opens doors. To build, use the curriculum as a to-do list: put your Cilium install under GitOps as a reviewed values file, publish a default-deny CiliumClusterwideNetworkPolicy baseline every team inherits, wire Hubble metrics into Grafana so drops are visible before they are tickets, and give one team a self-service path to request egress to a hostname instead of filing a firewall ticket. That last one is where a CNI stops being plumbing and becomes a platform capability.