Cilium Certified Associate common mistakes
Cilium Certified Associate · Understand the traps and how to avoid them.
Assuming Cilium always runs in kube-proxy replacement mode and that ClusterIP services are handled by eBPF, without checking whether kubeProxyReplacement is set to true, false, or disabled in the running configuration.
Candidates study the default Helm chart values or lab clusters where kubeProxyReplacement=true is common, then generalize. In reality the mode depends on how the cluster was installed (Helm flag, kube-proxy present or removed, strict vs partial), and questions often describe a cluster where kube-proxy still programs iptables/IPVS rules.
What to do instead
Before answering any service-routing question, identify the kube-proxy replacement mode: check the Helm value kubeProxyReplacement, the cilium-config ConfigMap, or 'cilium-dbg status' output which reports 'KubeProxyReplacement: True/False [eth0]'. Map behavior explicitly: in true/strict mode Cilium programs service translation in eBPF and kube-proxy can be removed; in false mode kube-proxy handles ClusterIP and Cilium only does policy and load balancing of external traffic.
Confusing the roles of the Cilium agent and the Cilium operator, for example expecting the operator to be on every node or expecting the agent to allocate cluster-wide PodCIDRs.
Both are Cilium components and both appear in DaemonSet/Deployment listings, so candidates default to 'the agent does everything'. The exam tests the split: the agent runs per node and programs eBPF, endpoints, and policy; the operator handles cluster-scoped tasks such as CRD management, IPAM pool allocation, and garbage collection of CiliumNetworkPolicy-derived state.
What to do instead
Memorize the split by scope: per-node datapath and endpoint state = cilium-agent DaemonSet; cluster-scoped singletons (CRDs, IPAM pool slicing, node/identity garbage collection, kvstore) = cilium-operator Deployment. When a question mentions 'cluster-wide IPAM allocation' or 'CRD registration', the answer is operator, not agent.
Treating the Cilium identity as the Pod IP or as the Kubernetes ServiceAccount, and therefore mis-predicting which policy applies after a label change.
Cilium's security model is label-based: identities are numeric IDs derived from a security-relevant label set, and endpoints share an identity when labels match. Candidates who think in terms of IPs or namespaces alone get confused when a Pod's labels change and the identity (and thus policy) changes without the IP changing.
What to do instead
State the rule explicitly: identity = hash of security-relevant labels; endpoints with identical labels share one identity; policy selects on labels, not IPs. Use 'cilium-dbg endpoint list' and 'cilium-dbg identity list' to see the numeric identity and its label set, and remember that changing a label can create a new identity and re-evaluate policy immediately.
Installing Cilium with Helm but forgetting to disable or remove the existing CNI (for example kindnet, flannel, or calico) or leaving kube-proxy running when strict kube-proxy replacement was requested, then diagnosing 'pods have no networking' as a Cilium bug.
Cilium requires the cluster to have no other CNI managing pod networking, and kube-proxy replacement modes have specific requirements (kube-proxy must be removed for full replacement, and the API server must be reachable). Candidates skip the prerequisite checklist and then misattribute symptoms.
What to do instead
Follow an ordered install checklist: create the cluster without a default CNI (kind: disableDefaultCNI: true; kubeadm: --pod-network-cidr and no CNI addon), install the Cilium Helm chart with the intended values, verify 'cilium status --wait' reports OK, and confirm the agent pods are Ready on every node. For kube-proxy replacement, delete the kube-proxy DaemonSet and set kubeProxyReplacement=true (or strict) before testing services.
Assuming the Helm chart's default values are the exam's defaults, particularly for IPAM mode, routing mode, and Hubble enablement, and answering questions as if those defaults are universal.
Cilium's defaults have changed across versions and depend on the installation method (Helm vs cilium CLI vs cloud marketplace). Candidates memorize one lab's values.yaml and apply it everywhere, missing that IPAM mode (cluster-pool vs kubernetes vs eni/azure) and routing mode (tunnel vs native) are explicit choices.
What to do instead
For every configuration question, ask 'which value controls this and what are the valid options?' rather than 'what is the default?'. Know the knobs: ipam.mode (cluster-pool, kubernetes, eni, azure, multi-pool), routingMode (tunnel, native), tunnelProtocol (vxlan, geneve), bpf.masquerade, hubble.enabled and hubble.relay.enabled. If a question depends on a version-specific default, reason from the stated values rather than assumed ones.
Believing that switching to native routing requires no underlying network support, and expecting Pod IPs to be routable across nodes without configuring the network or BGP.
Tunnel mode (VXLAN/Geneve) encapsulates pod traffic so the underlay only needs node-to-node reachability. Native routing removes encapsulation, so the underlay must route PodCIDRs, which usually means BGP (Cilium BGP Control Plane), cloud route tables, or a routed L2/L3 fabric. Candidates who conflate the two predict connectivity that cannot exist.
What to do instead
Map the modes to their requirements: tunnel mode needs only node IP reachability and handles PodCIDR routing via encapsulation; native routing needs the underlay to know PodCIDRs (BGP peering, cloud routes, or static routes) and often auto-direct-node-routes. When a question describes 'pods on different nodes cannot reach each other after switching routingMode to native', the fix is underlay routing or BGP, not a Cilium policy change.
Assuming Cilium IPAM allocates from the cluster's --pod-network-cidr by default, or that changing the IPAM mode requires no per-node CIDR planning.
In cluster-pool mode the operator slices a cluster CIDR into per-node PodCIDRs (clusterPoolIPv4PodCIDRList) and the agent allocates from its slice; in kubernetes mode Cilium reads the node's PodCIDR assigned by the control plane. Candidates who do not know which mode is active misdiagnose 'pod stuck in ContainerCreating with no IP' or 'IP conflicts between nodes'.
What to do instead
Identify the IPAM mode first, then reason: cluster-pool = operator-managed per-node CIDR slices from a configured cluster pool (check cilium-config cluster-pool-ipv4-cidr and 'cilium-dbg ipam list'); kubernetes = PodCIDR from the Node object; eni/azure = cloud IPAM. For 'no IP available', check pool exhaustion, per-node CIDR size, and whether the operator is running.
Reading a CiliumNetworkPolicy as if it were additive-only like Kubernetes NetworkPolicy, and forgetting that Cilium policies are default-deny for selected endpoints and that egress must be explicitly allowed.
Kubernetes NetworkPolicy is additive across policies but each policy still establishes isolation for its selected pods. CiliumNetworkPolicy behaves similarly per endpoint: once any policy selects an endpoint, traffic not explicitly allowed is denied, including DNS and egress to the API server. Candidates test only ingress and then see DNS failures.
What to do instead
Apply the rule: selecting an endpoint with any policy makes it default-deny in the covered direction; every needed flow must be allowed. Always include egress DNS rules (to kube-dns on port 53) and any egress to external services when writing egress policies. Verify with 'cilium-dbg policy get', 'cilium-dbg endpoint get ', and Hubble flows showing the verdict and the policy that dropped the packet.
Assuming Hubble is enabled by default and that installing the Hubble CLI alone provides flow visibility, then failing questions about how to observe dropped flows.
Hubble is a Cilium component that must be enabled (hubble.enabled=true) with the relay and UI as separate optional pieces; the CLI connects to the relay or agent gRPC endpoint. Candidates who only install the CLI see no flows and conclude observability is broken.
What to do instead
Know the observability stack: Hubble server (in the agent) must be enabled; Hubble Relay aggregates across nodes (hubble.relay.enabled=true); the CLI (hubble observe) or UI consumes it. Enable Hubble in the Helm values, port-forward or expose the relay, then use 'hubble observe --verdict DROPPED' to find policy drops and 'hubble observe --type l7' for HTTP-level flows when L7 policy is in use.
Confusing Cilium's L7 policy capabilities with a full service mesh and expecting mTLS, retries, or traffic splitting without enabling the relevant features (Envoy, mutual authentication, or Gateway API/Ingress).
Cilium can enforce L7 HTTP/gRPC/Kafka policy via Envoy and can act as a sidecar-less service mesh, but those capabilities require explicit configuration: L7 policy rules, authentication.mutualSpiffe or mutual TLS settings, and the Gateway API or Ingress controller. Candidates assume L4 policy automatically gives L7 visibility or mTLS.
What to do instead
Separate the layers: L3/L4 policy is eBPF-native; L7 policy requires Envoy and a rule with http/gRPC/kafka sections plus a matching L4 allow; mTLS and identity-based auth require the authentication feature (mutual authentication) to be enabled. For north-south traffic, Ingress or Gateway API must be enabled separately. Match the question's described capability to the feature flag that provides it.