Prepare for the Cilium Certified Associate (CCA) Exam

Cilium Certified Associate (CCA) Overview

1. eBPF Fundamentals

Understanding the “Why” before the “How.”

• What is eBPF: Extended Berkeley Packet Filter — a revolutionary technology that allows running sandboxed programs in the Linux kernel without changing kernel source code.
• Why eBPF Matters: Enables high-performance networking, security, and observability without the overhead of traditional approaches (iptables, kernel modules).
• eBPF vs iptables: eBPF operates at lower levels with better performance, while iptables uses sequential rule matching that doesn’t scale well.

2. Cilium Architecture (20%)

The backbone of cloud-native networking.

• What is Cilium: An open-source, eBPF-based networking, security, and observability solution for Kubernetes and other container orchestration platforms.
• Core Components: Cilium Agent, Cilium Operator, Cilium CNI Plugin, and Hubble.
• CNCF Project: Cilium is a CNCF graduated project, widely adopted in production environments.

Example of Cilium Data Flow:

3. Network Policy (18%)

Securing workloads with identity-based policies.

• CiliumNetworkPolicy: Extended network policies with L3/L4/L7 filtering capabilities.
• Identity-based Security: Cilium assigns identities to endpoints based on labels, not IP addresses.
• Policy Enforcement Modes: Default, Always, and Never modes for controlling policy behavior.
• K8s NetworkPolicy vs CiliumNetworkPolicy: Understanding compatibility and extended features.

4. Service Mesh (16%)

Modern traffic management without sidecars.

• Sidecarless Architecture: Cilium provides service mesh capabilities using eBPF without sidecar proxies.
• Gateway API: The next-generation Kubernetes Ingress API with more expressive routing.
• Ingress Controller: Cilium can act as an Ingress controller for external traffic.
• mTLS Encryption: Transparent encryption of traffic between services.

5. Network Observability (10%)

Visibility into network flows with Hubble.

• Hubble: Cilium’s observability layer built on top of eBPF.
• Flow Visibility: L3/L4/L7 network flow logs and metrics.
• Hubble CLI & UI: Command-line and graphical interfaces for observing traffic.
• Integration: Export to Prometheus, Grafana, and other monitoring systems.

6. Installation & Configuration (10%)

Getting Cilium up and running.

• Cilium CLI: The primary tool for installing and managing Cilium.
• Installation Methods: Cilium CLI, Helm, or manual manifests.
• Connectivity Tests: Built-in tests to validate Cilium installation.
• Configuration Options: Datapath modes, IPAM, encryption, and more.

7. Cluster Mesh (10%)

Multi-cluster connectivity.

• What is Cluster Mesh: Connects multiple Kubernetes clusters into a unified network.
• Service Discovery: Services can be discovered and accessed across clusters.
• Global Load Balancing: Distribute traffic across clusters for high availability.
• Requirements: Unique Pod CIDRs, cluster IDs, and shared CA.

8. BGP & External Networking (6%)

Connecting to the outside world.

• BGP Integration: Cilium can peer with external routers using BGP.
• LB IPAM: Automatic IP address management for LoadBalancer services.
• Egress Gateway: Control and monitor egress traffic from the cluster.
• External Workloads: Connect non-Kubernetes workloads to the Cilium network.

Sections That Need to Be Understood

1. eBPF vs iptables — Why eBPF Matters

Domain: eBPF (10%)

Understanding why Cilium chose eBPF over traditional approaches is fundamental.

iptables Limitations:

eBPF Advantages:

Comparison Table:

eBPF Hook Points:

References:

• eBPF.io
• Cilium eBPF Documentation

2. Cilium Architecture & Components

Domain: Architecture (20%)

Understanding each component’s role is essential.

Architecture Overview:

Component Details:

Cilium Agent Responsibilities:

# What Cilium Agent does on each node (understand this for exam)
- Compiles and loads eBPF programs into kernel
- Manages endpoint (pod) identities
- Enforces network policies
- Handles service load balancing (kube-proxy replacement)
- Provides Hubble flow data
- Manages encryption (IPsec/WireGuard)

Cilium Operator Responsibilities:

# What Cilium Operator does cluster-wide (understand this for exam)
- Manages CiliumNode resources
- Handles IPAM (IP allocation)
- Garbage collects stale resources
- Manages Cluster Mesh
- Synchronizes Kubernetes services

References:

• Cilium Architecture
• Cilium Agent Reference

3. Datapath Models

Domain: Architecture (20%)

Cilium supports multiple datapath modes for different environments.

Encapsulation Mode (VXLAN/Geneve):

• Pros: Works anywhere (any network)
• Cons: MTU overhead (~50 bytes), slight latency

Native Routing (Direct Routing):

• Pros: Better performance, no MTU overhead
• Cons: Requires network support (BGP, cloud VPC)

Datapath Mode Comparison:

Configuration:

# Helm values for encapsulation
tunnel: vxlan  # or geneve

# Helm values for native routing
tunnel: disabled
autoDirectNodeRoutes: true  # For same L2 network
# OR use BGP for cross-subnet routing

kube-proxy Replacement:

Cilium can fully replace kube-proxy for better performance:

# Helm values
kubeProxyReplacement: true

# Benefits:
# - eBPF-based service load balancing
# - DSR (Direct Server Return) support
# - Maglev consistent hashing
# - Socket-level load balancing (bypass netfilter)

References:

• Cilium Datapath
• kube-proxy Replacement

4. IPAM Modes

Domain: Architecture (20%)

Cilium supports multiple IP Address Management modes.

Cluster Pool Mode (Default):

# Helm values
ipam:
  mode: cluster-pool
  operator:
    clusterPoolIPv4PodCIDRList:
      - 10.0.0.0/8
    clusterPoolIPv4MaskSize: 24  # /24 per node

AWS ENI Mode:

# Helm values for AWS EKS
ipam:
  mode: eni
eni:
  enabled: true
  awsReleaseExcessIPs: true
  subnetTagsFilter:
    "kubernetes.io/role/cni": "1"

Kubernetes Mode:

# Helm values (uses node.spec.podCIDR)
ipam:
  mode: kubernetes

References:

• Cilium IPAM

5. CiliumNetworkPolicy vs Kubernetes NetworkPolicy

Domain: Network Policy (18%)

Cilium supports both standard Kubernetes NetworkPolicy and its extended CiliumNetworkPolicy.

Kubernetes NetworkPolicy (Standard):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

CiliumNetworkPolicy (Extended):

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-l7
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:                        # L7 rules!
              - method: GET
                path: "/api/v1/.*"
              - method: POST
                path: "/api/v1/users"

Feature Comparison:

Credit: Isovalent

CiliumNetworkPolicy Unique Features:

L7 HTTP Rules:

spec:
  ingress:
    - toPorts:
        - ports:
            - port: "80"
          rules:
            http:
              - method: GET
                path: "/public/.*"
                headers:
                  - "X-Api-Key: secret"

DNS-based Egress (FQDN):

spec:
  egress:
    - toFQDNs:
        - matchName: "api.github.com"
        - matchPattern: "*.amazonaws.com"
      toPorts:
        - ports:
            - port: "443"

toServices (Service-based):

spec:
  egress:
    - toServices:
        - k8sService:
            serviceName: redis
            namespace: database

References:

• CiliumNetworkPolicy
• Policy Examples

6. Identity-based Security Model

Domain: Network Policy (18%)

Cilium’s security model is fundamentally different from IP-based approaches.

Traditional IP-based Security:

Problems:

• Pod IPs are ephemeral (change on restart)
• Rules must be updated constantly
• Doesn’t scale with dynamic workloads

Cilium Identity-based Security:

Benefits:

• Identity based on labels, not IPs
• Survives pod restarts/reschedules
• Scales automatically

How Cilium Identity Works:

With this picture should be enough explained xD

View Identities:

# List all identities
cilium identity list

# Example output:
# ID      LABELS
# 1       reserved:host
# 2       reserved:world
# 3       reserved:unmanaged
# 4       reserved:health
# 12345   k8s:app=frontend
# 67890   k8s:app=backend

References:

• Identity-based Security

7. Policy Enforcement Modes

Domain: Network Policy (18%)

Cilium supports different enforcement modes for policies.

Enforcement Modes:

Default Mode (Recommended):

# Helm values
policyEnforcementMode: default

# Behavior:
# - Endpoints WITHOUT policies: Allow all traffic
# - Endpoints WITH policies: Only allowed traffic passes

Always Mode (Zero Trust):

# Helm values
policyEnforcementMode: always

# Behavior:
# - ALL endpoints: Deny by default
# - Must explicitly allow all traffic
# - Most secure, but requires complete policy coverage

Never Mode (Monitoring):

# Helm values
policyEnforcementMode: never

# Behavior:
# - Policies are loaded but not enforced
# - Useful for auditing/testing policies
# - Hubble still shows policy verdicts

Per-Endpoint Annotation Override:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  annotations:
    # Force policy enforcement for this pod
    policy.cilium.io/policy-enforcement: "always"

Check Current Mode:

# Check policy enforcement mode
# No idea why it only appear in: https://docs.cilium.io/en/latest/cmdref/cilium_config/#see-also
# Not other version like 1.15 -> 1.18
cilium config view | grep PolicyEnforcement

# Check endpoint policy status
cilium endpoint list

References:

• Policy Enforcement

8. Gateway API vs Ingress

Domain: Service Mesh (16%)

Cilium supports both traditional Ingress and the newer Gateway API. Yeah, I don’t think Cilium will ask for Gateway API, but it did. So you have to understand Gateway API also!

Ingress (Legacy):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: cilium
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

Gateway API (Modern):

# Gateway - defines the listener
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: cilium
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
---
# HTTPRoute - defines routing rules
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
    - name: my-gateway
  hostnames:
    - "app.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web-service
          port: 80

Gateway API Advantages:

Traffic Splitting with Gateway API:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - backendRefs:
        - name: app-v1
          port: 80
          weight: 90          # 90% to v1
        - name: app-v2
          port: 80
          weight: 10          # 10% to v2

Header-based Routing:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: header-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - headers:
            - name: x-canary
              value: "true"
      backendRefs:
        - name: app-canary
          port: 80
    - backendRefs:
        - name: app-stable
          port: 80

References:

• Cilium Gateway API
• Gateway API Specification

9. Cilium Service Mesh

Domain: Service Mesh (16%)

Cilium provides service mesh capabilities without sidecar proxies.

Sidecar vs Sidecarless Architecture:

Traditional Sidecar Service Mesh Cons: Resource overhead, latency, operational complexity

Cilium Sidecarless Service Mesh Pros: Lower resource usage, better performance

Enabling Cilium Service Mesh:

# Helm values
ingressController:
  enabled: true
  loadbalancerMode: shared  # or dedicated
gatewayAPI:
  enabled: true
envoy:
  enabled: true

mTLS with Cilium:

# Helm values for transparent encryption
encryption:
  enabled: true
  type: wireguard  # or ipsec

# WireGuard is recommended for performance
# Automatically encrypts pod-to-pod traffic

Check Encryption Status:

# Verify encryption is enabled
cilium status --verbose | grep Encryption

# Check encrypted connections
cilium encrypt status

References:

• Cilium Service Mesh
• Encryption

10. Hubble Observability

Domain: Network Observability (10%)

Hubble provides deep network visibility powered by eBPF.

Hubble Architecture:

Enable Hubble:

# Helm values
hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true
  metrics:
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - icmp
      - http

Hubble CLI Commands:

# Observe all flows
hubble observe

# Filter by namespace
hubble observe --namespace production

# Filter by pod
hubble observe --pod production/frontend

# Filter by verdict (FORWARDED, DROPPED, AUDIT)
hubble observe --verdict DROPPED

# Filter by protocol
hubble observe --protocol TCP

# Filter by L7 type
hubble observe --type l7

# Filter by HTTP status
hubble observe --http-status 500

# Follow real-time flows
hubble observe -f

# Output as JSON
hubble observe -o json

# Show DNS queries
hubble observe --protocol DNS

Hubble Flow Fields:

{
  "time": "2025-12-21T10:30:00.000Z",
  "verdict": "FORWARDED",
  "ethernet": { "source": "...", "destination": "..." },
  "IP": { "source": "10.0.1.5", "destination": "10.0.2.10" },
  "l4": { "TCP": { "source_port": 45678, "destination_port": 8080 } },
  "source": {
    "identity": 12345,
    "namespace": "production",
    "labels": ["k8s:app=frontend"],
    "pod_name": "frontend-abc123"
  },
  "destination": {
    "identity": 67890,
    "namespace": "production",
    "labels": ["k8s:app=backend"],
    "pod_name": "backend-xyz789"
  },
  "Type": "L3_L4",
  "l7": {
    "type": "HTTP",
    "http": { "method": "GET", "url": "/api/users", "code": 200 }
  },
  "traffic_direction": "INGRESS"
}

L7 Visibility:

# Enable L7 visibility with annotation
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  annotations:
    policy.cilium.io/proxy-visibility: "<Ingress/80/TCP/HTTP>"

Or via CiliumNetworkPolicy:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-visibility
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - toPorts:
        - ports:
            - port: "80"
          rules:
            http: {}           # Empty rules enable visibility without filtering

References:

• Hubble Documentation
• Hubble CLI Reference

11. Cluster Mesh

Domain: Cluster Mesh (10%)

Connect multiple Kubernetes clusters into a unified network.

Cluster Mesh Architecture:

Requirements:

Enable Cluster Mesh:

# Enable cluster mesh on each cluster
cilium clustermesh enable --service-type LoadBalancer

# Connect clusters
cilium clustermesh connect --destination-context cluster2

# Check status
cilium clustermesh status

Helm Configuration:

# Cluster 1
cluster:
  name: cluster1
  id: 1
clustermesh:
  useAPIServer: true
  apiserver:
    service:
      type: LoadBalancer

# Cluster 2
cluster:
  name: cluster2
  id: 2
clustermesh:
  useAPIServer: true
  apiserver:
    service:
      type: LoadBalancer

Global Services:

# Service accessible from all clusters
apiVersion: v1
kind: Service
metadata:
  name: global-api
  annotations:
    service.cilium.io/global: "true"      # Enable global service
    service.cilium.io/shared: "true"      # Share this service
spec:
  selector:
    app: api
  ports:
    - port: 80

Service Affinity:

apiVersion: v1
kind: Service
metadata:
  name: global-api
  annotations:
    service.cilium.io/global: "true"
    service.cilium.io/affinity: "local"   # Prefer local cluster
    # Options: local, remote, none

References:

• Cluster Mesh

12. Cilium CLI Commands Cheat Sheet

Domain: Installation and Configuration (10%)

Essential cilium CLI commands for the exam.

Installation & Status:

# Install Cilium
cilium install

# Install with specific version
cilium install --version 1.15.0

# Install with custom Helm values
cilium install --helm-values values.yaml

# Check Cilium status
cilium status

# Detailed status
cilium status --verbose

# Wait for Cilium to be ready
cilium status --wait

Connectivity Tests:

# Run connectivity tests
cilium connectivity test

# Run specific test
cilium connectivity test --test pod-to-pod

# Run tests with Hubble enabled
cilium connectivity test --hubble=true

# Cleanup test resources
cilium connectivity test --cleanup

Configuration:

# View current config
cilium config view

# Get specific config value
cilium config get tunnel

# Set config value (requires agent restart)
cilium config set debug true

Endpoints & Identity:

# List endpoints
cilium endpoint list

# Get endpoint details
cilium endpoint get <endpoint-id>

# List identities
cilium identity list

# Get identity details
cilium identity get <identity-id>

Network Policy:

# List policies
cilium policy get

# Import policy
cilium policy import policy.yaml

# Delete policy
cilium policy delete <policy-name>

# Trace policy decision
cilium policy trace --src-identity <id> --dst-identity <id> --dport 80

Hubble:

# Enable Hubble
cilium hubble enable

# Enable Hubble UI
cilium hubble enable --ui

# Port-forward Hubble UI
cilium hubble ui

# Port-forward Hubble Relay
cilium hubble port-forward &
hubble observe

BPF & Debugging:

# List BPF maps
cilium bpf endpoint list

# Show BPF policy maps
cilium bpf policy get <endpoint-id>

# Show NAT table
cilium bpf nat list

# Show connection tracking
cilium bpf ct list global

# Debug datapath
cilium monitor

# Verbose monitoring
cilium monitor -v

# Monitor dropped packets only
cilium monitor --type drop

Encryption:

# Check encryption status
cilium encrypt status

# View encryption keys (IPsec)
cilium encrypt key list

Cluster Mesh:

# Enable cluster mesh
cilium clustermesh enable

# Connect to another cluster
cilium clustermesh connect --destination-context <context>

# Check cluster mesh status
cilium clustermesh status

# Disconnect cluster
cilium clustermesh disconnect <cluster-name>

Upgrade:

# Upgrade Cilium
cilium upgrade

# Upgrade with specific version
cilium upgrade --version 1.15.0

# Upgrade with custom values
cilium upgrade --helm-values values.yaml

Troubleshooting:

# Generate support bundle
cilium sysdump

# Check agent logs
kubectl logs -n kube-system -l k8s-app=cilium

# Check operator logs
kubectl logs -n kube-system -l name=cilium-operator

# Verify BPF filesystem
cilium bpf fs show

Not related to exam but I want to put here anyway

While copying content, I found this xD

[embed]

TLDR:

• Cilium can not replace the ingress nginx yet, and we should not migrate from ingress nginx to Cilium.
• It could be replaced with a specific scenario only, not widely.

Key Resources

• Cilium Official Documentation
• CCA Exam Curriculum
• Cilium GitHub
• eBPF.io
• Isovalent Labs (Free Tutorials)
• My resource xD

My Secret Weapon: Mock Exam

**https://www.udemy.com/course/complete-cilium-certified-associate-cca-exam-prep**

Exam Notes

• It is fucking hard.
• Questions are tricky, really, really! You need to read it really carefully.
• Since English is not my native language, I failed to understand 1 question xD
• Be careful with uncommon questions related to the topic: BIG TCP.
• Some questions related to Egress Gateway: you can not have both the interface and egress IP together. And I failed to understand how the egress gateway works for the first time!
• CLI commands. I thought it was easy, but it is not.
• I failed the first time with a score of 73/100 (pass score is 75), because I don’t think it is that hard, and I lack preparation, only 1 day, like 5–6 hours for the exam??? I would say WTF, why don’t I spend more time???
• Why is it hard? The retake I scored 80/100, and the questions are not the same as the last exam xDDDD

Conclusion

I don’t think the article should be long like this long, over 1000 lines. But in fact, it is needed!

Good luck with the exam, never underestimate it like me, who need 2nd try to pass xD