CCA Study Plan

The CCA blueprint lays out what the eight domains cover. This page decides when you study each one, and for how long — and it refuses to split fourteen days into eight equal slivers. Architecture (20%) and Network Policy (18%) are 38% of the paper between them and open the plan on days 1–5. eBPF, the domain almost everyone quietly over-prepares because it sounds like the "real" engineering, is worth exactly 10% — the same as three other domains — and gets capped at a single day here on purpose. What follows is a day-by-day schedule, an hours budget derived straight from the published weights, a hands-on lab day even though the real exam never opens a terminal, and a readiness gate you check honestly before sitting a timed mock.

Spend the fourteen days where the marks are

☺ Like you're 10: Don't give every topic the same number of days. Give the big ones more days and the small ones fewer — that's the entire idea.

The CNCF publishes eight weighted domains for the CCA, and this plan does nothing cleverer than turning that percentage straight into a day count and an hours budget. Read the full domain table and competency list on the CCA blueprint first if you haven't already — this page assumes you already know roughly what each domain covers and spends its words purely on pacing it.

hours for a domain = total domain-study hours × that domain's weight.

This plan spends 20 hours of domain study across twelve days — under two hours a day, which is realistic for a 90-minute knowledge exam that doesn't need eleven-week devotion. Applying that formula to the eight published weights:

Before day one — pick your pace

☺ Like you're 10: Fourteen days is a guess that fits most people. If Kubernetes and networking already feel familiar, you can move faster. If they don't yet, give yourself more runway.

"Fourteen days" assumes you're already comfortable reading a Kubernetes manifest and know roughly what a Service and a plain NetworkPolicy do — CCA doesn't re-teach Kubernetes itself, and every scenario question on the exam is phrased in terms of Pods, Deployments and Services it assumes you already recognize. If any of that is still new, this course's own Kubernetes Baseline You Need or the sibling Kubernetes course is worth a detour before day one here.

The 14-day schedule

☺ Like you're 10: Here's the whole two weeks on one strip — which days belong to which topic, sized by how much of the test they're actually worth.

The bar below is the table that follows it, drawn to scale. Block width is day count, not domain count — Architecture and Network Policy together take up more than a third of the strip; eBPF gets one thin sliver, same width as three other domains.

Days 1–5 — Architecture and Network Policy, the 38%

☺ Like you're 10: Almost forty cents of every dollar this exam is worth lives in just two ideas: how the pieces fit together, and how the doors decide who gets in.

On days 1–3, read the Architecture section of the CCA blueprint twice and draw the components from memory before checking your sketch: cilium-agent runs on every node and programs that node's eBPF maps; cilium-operator runs once per cluster and does the non-per-node work — cluster-pool IPAM allocation, garbage-collecting stale CiliumIdentity and CiliumEndpoint objects. Then write out the two config axes as two short lists: IPAM mode (kubernetes, cluster-pool — the default, eni, azure) and routing mode (tunnel, encapsulating in VXLAN/Geneve, versus native, where the underlay already routes your PodCIDRs).

On days 4–5, move to Network Policy. The one sentence worth having automatic: Cilium enforces on a label-derived security identity, not an IP address, which is exactly why policy survives a pod being rescheduled onto a new IP. Write this policy from memory, then diff your version against the reference below field by field:

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 }]
  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 }]

Days 6–8 — Service Mesh and Network Observability

☺ Like you're 10: Day 6–7 is how traffic gets routed in and encrypted between hops. Day 8 is how you watch it happen and prove what dropped.

Service Mesh (16%) is bigger than eBPF, Hubble or Cluster Mesh individually — candidates who study "Cilium the CNI" and skip "Cilium the mesh" quietly give away a sixth of the paper. Cilium's mesh is sidecarless: the datapath already inspects every packet, so an Envoy proxy runs once per node, only when an L7 rule needs it, instead of once per pod. Know the curriculum's own framing of Gateway API over Ingress: role-oriented (GatewayClass/Gateway/HTTPRoute split across separate RBAC), spec-native routing instead of vendor annotations, portable across implementations. For traffic in transit, Cilium encrypts node-to-node with WireGuard or IPsec — a config change, not an app change.

Day 8 is Hubble. Because the agent already inspects every packet to enforce policy, exporting the verdict is nearly free — but L7 visibility is not on by default. A flow is only parsed above L4 when a policy attaches L7 rules to it. To get visibility without narrowing what's allowed, write rules that match everything:

# The single most useful command in an incident, and a CCA favorite
hubble observe --verdict DROPPED -f
# prod/checkout-7d9f:52344 -> prod/payments-6b4c:8080  \
#   Policy denied DROPPED (TCP Flags: SYN)   <-- identity, not just an IP

hubble observe --type l7 --protocol http --http-status 403   # L7 verdicts
hubble status                                                 # is relay seeing every node?

Days 9–11 — Installation, Cluster Mesh, and the eBPF trap

☺ Like you're 10: Three ordinary-sized days for three ordinary-sized topics — including the one everybody assumes is the whole exam.

Day 9, Installation and Configuration: this exam is multiple-choice, so recognize the verbs rather than drilling flags.

cilium install --version <x.y.z>    # always pin a version
cilium status --wait                # agents, operator, Hubble: OK?
cilium connectivity test            # pod-to-pod, pod-to-service, DNS, egress
cilium config view                  # query the running cilium-config
cilium sysdump                      # one archive with everything support needs

Day 10, Cluster Mesh: three hard prerequisites are exam favorites — a globally unique cluster name, a globally unique cluster ID, and strictly non-overlapping PodCIDRs across every meshed cluster. Making a Service global across the mesh is one annotation:

apiVersion: v1
kind: Service
metadata:
  name: payments
  namespace: prod
  annotations:
    service.cilium.io/global: "true"      # merge endpoints from ALL meshed clusters
spec:
  selector: { app: payments }
  ports: [{ port: 8080, targetPort: 8080 }]

Day 11 is eBPF — and it gets exactly the same 2.0-hour, one-day budget as the three domains above it, not a fortnight. The three competencies are answerable in prose; you never write a BPF program for this exam. Explain, in one paragraph you could say out loud, why an eBPF datapath scales where iptables doesn't: iptables walks a linear rule chain per packet, and that chain grows with every Service; eBPF programs, verified safe and JIT-compiled to native code, do effectively constant-time hash-map lookups instead, with shared state — endpoints, identities, service backends — held in eBPF maps. That paragraph, plus knowing what kubeProxyReplacement means, is the whole domain.

Days 12–14 — the hands-on lab, BGP, and the readiness gate

☺ Like you're 10: The last three days: one small remaining topic, one afternoon making it all real on an actual cluster, then an honest check before you book.

Day 12, BGP and External Networking, the smallest domain at 6%: 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. 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.

Day 13 is the hands-on lab. CCA itself never opens a terminal — but one afternoon on a real cluster makes half the paper self-evident in a way reading alone doesn't:

kind create cluster --name cca-study
cilium install --version 1.16.0
cilium status --wait
cilium connectivity test

# apply the Day 4-5 CiliumNetworkPolicy, then watch the denied path live
kubectl apply -f payments-api.yaml
hubble observe --verdict DROPPED -f

# delete the DNS egress rule and watch everything else quietly break —
# the exact trap the exam keeps setting
kubectl delete -f payments-api.yaml

Day 14 is the gate. Don't open Mock Exam · Set 1 until every box below is honestly true, not "true if I squint":

• ① The 38% — Architecture and Network Policy
• I can name every Architecture component and both config axes without looking
• I can write a CiliumNetworkPolicy from a blank page and explain the default-deny trap
• ② The remaining six domains
• I can explain sidecarless mesh and two Gateway-API-over-Ingress benefits
• I can explain why L7 visibility isn't on by default, and how to turn it on without narrowing traffic
• I can name the three Cluster Mesh prerequisites and what the global-Service annotation does
• I can explain, in one paragraph, why eBPF outperforms iptables — and I capped it at one day
• ③ The whole exam
• I ran Cilium on a real cluster during Day 13, not just read about it

Five or more checked, spanning all three categories, is a reasonable green light. Fewer than that, don't force the calendar — return to the specific day range above, not a general re-read of everything. Once clear, work the CCA practice questions, then sit Mock Exam · Set 1 under real conditions — 90 minutes, no notes — and mark it against the published 75% pass mark. If it's close but not comfortable, hold your booking, spend one more evening on whichever domain the mock exposed, and sit Mock Exam · Set 2 before committing a date. One score near the line is noise; two consistent scores above it is signal.