Passing the Cilium Certified Associate (CCA): The Ultimate Deep Dive & Study Guide

These are my personal study notes and architecture guides compiled while preparing for and passing the Cilium Certified Associate (CCA) certification by the Cloud Native Computing Foundation (CNCF) and The Linux Foundation.

As Kubernetes networking evolves past legacy iptables and IPVS bottlenecks, eBPF (Extended Berkeley Packet Filter) has become the revolutionary standard for container networking, security observability, and service meshes. I documented all hands-on labs, manifests, and exam takeaways in my GitHub Cilium Certified Associate Repository to serve as a high-yield, comprehensive exam guide.

1. eBPF Fundamentals & Cilium CNI Architecture (20%)

eBPF allows sandboxed programs to execute directly within the Linux kernel in response to kernel events (tracepoints, kprobes, network sockets, tc filters). This completely bypasses the user-space/kernel-space context switching overhead and eliminates the massive iptables lookup loops that plague large Kubernetes clusters.

eBPF Structure: Programs & Maps

An eBPF application consists of two distinct components:

• Kernel-Space Program (KSP): Triggered inside the kernel at specific hook points (e.g., socket creation, packet arrival). It executes packet inspection, redirection, or filtering with zero latency.
• User-Space Program (USP): Loads the eBPF program, attaches it to hooks, and reads metrics.
• BPF Maps: The bi-directional key-value in-memory data structures used to share state between the kernel-space program and user-space tools.

CNI Plugin Lifecycle on Nodes

When Cilium is deployed on a Kubernetes node:

1. The Cilium agent writes /etc/cni/net.d/05-cilium.conflist instructing Kubelet how to configure Pod networking.
2. It adds the /opt/cni/bin/cilium-cni binary (acting as a wrapper between Kubelet and the local cilium-agent daemon).
3. ADD Command: Kubelet calls cilium-cni on Pod creation to setup veth pairs, assign Pod IPs, and inject eBPF datapath hooks.
4. DEL Command: Triggered on Pod deletion to clean up BPF maps and release IP addresses.

Cilium IPAM Modes Breakdown

2. Layer 3/4 vs Layer 7 Cilium Network Policies (18%)

Standard Kubernetes NetworkPolicy resources can only filter traffic at Layer 3 (IPs/CIDRs) and Layer 4 (TCP/UDP Ports). They cannot inspect HTTP paths, methods, headers, or gRPC services.

Two-Tier Enforcement Architecture

Cilium implements Layer 7 security policies using an intelligent two-tier architecture:

1. Tier 1 (Kernel eBPF): Evaluates L3/L4 rules directly in the kernel datapath with zero context-switch penalty. Non-matching packets are immediately DROPPED.
2. Tier 2 (On-Node Envoy Proxy): If the packet passes L3/L4 filters, it is forwarded transparently to the co-located Envoy proxy running on the node to enforce HTTP/gRPC rules. If denied at L7, Envoy returns an application-level response (e.g. HTTP 403 Forbidden).

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "secure-deathstar-landing"
  namespace: "default"
spec:
  description: "Allow only authenticated landing requests to /v1/request-landing"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
    - fromEndpoints:
        - matchLabels:
            org: empire
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
          rules:
            http:
              - method: "POST"
                path: "/v1/request-landing"

Clusterwide vs Namespaced Policies

• CiliumNetworkPolicy (Namespaced): Restricts endpoints within a single namespace.
• CiliumClusterwideNetworkPolicy (Cluster-Scoped): Applies security guardrails across all namespaces simultaneously (e.g. blocking all traffic originating outside the cluster using fromEntities: [world]).

3. Gateway API, Ingress & GAMMA Service Mesh (16%)

Kubernetes Ingress was designed around HTTP routing annotations and lacked standard support for TCP/UDP, traffic splitting, header mutations, and cross-namespace governance. The Gateway API replaces Ingress with an expressive, role-oriented standard.

The Role-Oriented Architecture Hierarchy

• GatewayClass (Cluster-Scoped, Infrastructure Owner): Defines the controller implementation (controllerName: io.cilium/gateway-controller).
• Gateway (Namespaced, Cluster Operator): Defines entry points, ports, protocols, and TLS certificates (Southbound listeners).
• HTTPRoute / TLSRoute / GRPCRoute (Namespaced, Application Developer): Specifies path routing, traffic splits, header filters, and backend services.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-and-header-manipulation
  namespace: prod
spec:
  parentRefs:
    - name: cilium-gw
  rules:
    # 1. Traffic Splitting (Canary / Blue-Green)
    - matches:
        - path:
            type: PathPrefix
            value: /api/v2
      backendRefs:
        - name: app-v1
          port: 8080
          weight: 80
        - name: app-v2
          port: 8080
          weight: 20
    # 2. Header Modification & URL Path Rewriting
    - matches:
        - path:
            type: PathPrefix
            value: /old-prefix
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /new-prefix
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: X-Cilium-Engine
                value: "eBPF-Envoy"
      backendRefs:
        - name: backend-service
          port: 8080

East-West Service Mesh with GAMMA

The GAMMA (Gateway API for Mesh Management and Administration) initiative enables Layer 7 routing between internal microservices (East-West) without sidecars. Instead of attaching an HTTPRoute to a Gateway, you attach it to a Kubernetes Service:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: internal-echo-split
  namespace: default
spec:
  parentRefs:
    - group: ""
      kind: Service
      name: echo-service
  rules:
    - matches:
        - path:
            type: Exact
            value: /v2
      backendRefs:
        - name: echo-v2
          port: 80

4. Network Observability with Hubble (18%)

Hubble is Cilium's built-in observability engine. By tapping directly into eBPF hooks in the Linux kernel, Hubble provides real-time visibility into network flows, DNS resolutions, HTTP transactions, and packet drop reasons without modifying application code.

Essential Hubble CLI Commands

# Enable Hubble with Web UI in the cluster
cilium hubble enable --ui

# Open port-forward to local Hubble Relay
cilium hubble port-forward &

# Observe real-time traffic from a specific pod
hubble observe --from-pod default/frontend

# Filter dropped packets to diagnose Network Policy denials
hubble observe --verdict DROPPED --namespace default

# Observe Layer 7 HTTP flows with status codes
hubble observe --protocol http --http-status 500

# Inspect raw IP addresses without pod name translation
hubble observe --ip-translation=false --protocol tcp

5. Cilium Cluster Mesh & Multi-Cluster (12%)

Cilium Cluster Mesh connects multiple independent Kubernetes clusters into a unified service mesh. It synchronizes cluster state through an etcd key-value store, allowing Pods across different clusters to communicate directly over native IP routing or overlay tunnels without intermediate ingress gateways.

Global Services & Traffic Affinity

To turn a standard Kubernetes Service into a multi-cluster service, simply add the service.cilium.io/global: "true" annotation:

• Cross-Cluster Failover: If a local deployment fails, traffic automatically fails over to identical backend pods in meshed clusters.
• Service Affinity (service.cilium.io/affinity: local): Ensures requests prefer healthy local endpoints first to minimize latency and inter-region data transfer costs, only routing to remote clusters if local pods are down.
• Unsharing (service.cilium.io/shared: "false"): Allows a cluster to access global services in the mesh without exposing its own local pods to remote clusters.

apiVersion: v1
kind: Service
metadata:
  name: payment-backend
  annotations:
    service.cilium.io/global: "true"
    service.cilium.io/affinity: "local"
spec:
  type: ClusterIP
  ports:
    - port: 8080
  selector:
    app: payment-backend

6. BGP Control Plane & Egress Gateways (10%)

Native BGP Control Plane

In modern leaf-spine enterprise data centers, Kubernetes nodes peer directly with Top-of-Rack (ToR) physical switches via BGP to advertise Pod CIDRs and LoadBalancer IPs. This eliminates overlay encapsulation (Geneve/VXLAN) and enables wire-speed routing.

Cilium's BGP v2 control plane is managed using three declarative CRDs:

1. CiliumBGPClusterConfig: Selects target nodes and configures local Autonomous System Numbers (ASN).
2. CiliumBGPPeerConfig: Configures remote neighbor peering IP addresses and timers.
3. CiliumBGPAdvertisement: Defines which CIDRs (Pod CIDRs or Service LoadBalancer IPs) are announced via BGP.

Egress Gateway (Predictable Outbound NAT)

Enterprise firewalls outside Kubernetes require static, predictable source IP addresses to allow traffic into legacy databases or partner APIs. Cilium's Egress Gateway intercepts outbound traffic from matching pods and routes it through designated gateway nodes performing Source NAT (SNAT) with dedicated IPs:

apiVersion: cilium.io/v2
kind: CiliumEgressGatewayPolicy
metadata:
  name: egress-to-oracle-db
spec:
  destinationCIDRs:
    - "192.168.10.0/24"
  selectors:
    - podSelector:
        matchLabels:
          app: payment-processor
  egressGateway:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/egress-gateway: "true"
    interface: eth1

7. Runtime Security & Enforcement with Tetragon (6%)

Tetragon is Cilium's eBPF-based security observability and runtime enforcement engine. Unlike traditional security tools that analyze audit logs in user-space after an attack occurred, Tetragon hooks directly into kernel system calls and kprobes to detect and block threats in real time.

In-Kernel Enforcement with TracingPolicy

Tetragon operates via TracingPolicy CRDs. When an attacker attempts a container breakout (e.g. running nsenter to escape user namespaces or writing unauthorized static pods into /etc/kubernetes/manifests), Tetragon detects the event and can enforce in-kernel actions:

• Sigkill: Instantly kills the malicious process in the kernel.
• Override: Overrides the system call return code with -1 (Operation Not Permitted), aborting file writes or network connections.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-manifest-tampering
spec:
  kprobes:
    - call: "security_file_permission"
      syscall: false
      args:
        - index: 0
          type: "file"
        - index: 1
          type: "int"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/etc/kubernetes/manifests"
          matchActions:
            - action: Override
              argError: -1

The CCA certification is a fantastic benchmark for modern cloud-native architects looking to master eBPF networking, security enforcement, and high-performance routing in Kubernetes.

You can find all practical lab scripts, YAML manifests, and exam quizzes in my open-source repository: github.com/muecahit94/cilium-certified-associate.

Best of luck with your Cilium certification journey!