CertArea
All Linux Foundation / CNCF exams

Free CCA practice test: 30 questions with answers

30 original questions for Cilium Certified Associate (CCA), drawn from every topic area. Answer each one to see whether you got it right and why. No sign-up.

Free questions
30
Full bank
112 questions
Real exam
90 min

CCA exam guide: topics, cost and format

All 30 CCA questions with answers

The same questions as the test above, grouped by exam topic. Open any question to see the answer and explanation.

Architecture (4 questions)

  1. Question 1

    While reviewing the kube-system namespace, an engineer finds one Cilium pod on every worker node. Each pod compiles and loads eBPF programs into the kernel and enforces policy for the endpoints on its own node. Which component is this?

    1. AThe cilium-operator Deployment that handles cluster-wide tasks
    2. BThe Hubble Relay Deployment that aggregates flow data from several nodes
    3. CThe cilium-agent DaemonSet pod running on each node
    4. DThe cilium command-line client installed on an administrator workstation
    Show answer and explanation
    Correct answer: C

    The cilium-agent runs on every node, compiles and loads eBPF programs, and enforces policy for local endpoints. The operator runs cluster-wide tasks from a Deployment, Hubble Relay aggregates flows, and the CLI is only a client on a workstation.

  2. Question 2

    Which statement best describes Cilium's role in a Kubernetes cluster?

    1. AIt is a container runtime that pulls OCI images and starts containers on worker nodes
    2. BIt is an extension of the kube-apiserver that stores cluster state in its own database
    3. CIt replaces the kubelet on each worker node so that pods are scheduled directly against the Linux kernel without a runtime
    4. DIt supplies pod networking through the CNI interface and adds identity-aware policy, load balancing and observability
    Show answer and explanation
    Correct answer: D

    Cilium acts as the CNI plugin and provides identity-aware policy, load balancing and observability using eBPF. It does not replace the kubelet or act as a container runtime, and it does not keep cluster state in its own database because it relies on Kubernetes APIs and CRDs.

  3. Question 3

    A cluster uses cluster-pool IPAM. A new worker node joins, and the team wants to understand how it gets its pod addresses. What happens?

    1. AThe operator assigns the node a pod CIDR from the cluster-wide pool, and the agent hands out addresses from that range to local pods
    2. BEvery pod borrows an address from the node's primary interface, and no per-node ranges are created at all
    3. CEach pod asks a DHCP server outside the cluster for an address when it starts
    4. DThe node uses only the podCIDR that Kubernetes wrote on its Node object, and the cilium-operator takes no part in allocating addresses for it
    Show answer and explanation
    Correct answer: A

    In cluster-pool mode the operator carves per-node ranges out of the cluster pool and the agent assigns pod addresses from them. DHCP is not used, pods do not borrow the host interface address, and Kubernetes-assigned podCIDR values belong to a different IPAM mode.

  4. Question 4

    A team runs Cilium in tunnel mode with a VXLAN overlay. The underlying network can already route pod addresses between nodes, and the team wants to remove the encapsulation overhead. What should they change?

    1. AReplace the Cilium datapath with kube-proxy in iptables mode, which removes any overlay from pod traffic
    2. BEnable Hubble Relay so that flows are exported and the tunnel overlay is no longer used for pod traffic
    3. CRaise the MTU of the tunnel device so that encapsulated packets never need fragmentation, while keeping the overlay enabled
    4. DSwitch to native routing mode and make sure the underlying network knows routes to the pod address ranges on each node
    Show answer and explanation
    Correct answer: D

    Native routing sends pod packets without encapsulation, provided the network can route the pod CIDRs between nodes. Hubble does not change the datapath, raising the MTU keeps the overlay in place, and kube-proxy is not the Cilium datapath.

Network Policy (4 questions)

  1. Question 5

    A namespace contains a frontend deployment and a backend deployment. An engineer applies a policy that selects only the backend pods and allows ingress from the frontend pods. A separate monitoring pod in the same namespace is not selected by any policy. Under default enforcement, what happens to ingress traffic sent to the monitoring pod?

    1. AIt drops all ingress until an explicit allow policy is written for its labels, because every endpoint is deny-by-default
    2. BIt keeps accepting traffic from any source, because enforcement applies only to endpoints that a policy selects
    3. CThe new backend policy also covers it, because policies apply to the whole namespace unless they are scoped further
    4. DIt is placed into a quarantine identity that blocks every connection, including traffic from the node itself
    Show answer and explanation
    Correct answer: B

    In default enforcement mode a policy restricts only the endpoints its selector matches, so the unselected monitoring pod stays open to any source. Policies do not cover a whole namespace automatically, and there is no quarantine identity in this behaviour.

  2. Question 6

    Which statement correctly describes the default policy enforcement mode in Cilium?

    1. AEvery endpoint drops all traffic until a policy explicitly allows it, regardless of whether any policy selects that particular endpoint
    2. BPolicies are parsed but ignored, so every connection between pods is accepted even after a policy has been applied
    3. CEndpoints stay open to traffic until a policy selects them, and then only traffic explicitly allowed in that direction is accepted
    4. DOnly egress is restricted, because ingress to a pod is always allowed by the kernel datapath
    Show answer and explanation
    Correct answer: C

    In default mode an endpoint becomes restricted only after a policy selects it, and then only explicitly allowed traffic in that direction passes. Policies are not ignored, and ingress is not always allowed, which is why the other options are wrong.

  3. Question 7

    A team wants pods labeled app=monitor to send only HTTP GET requests to the path /healthz on port 8080 of the backend pods, and nothing else. Which part of a CiliumNetworkPolicy ingress rule carries that method and path restriction?

    1. AA fromCIDR entry containing the IP address range of the monitoring pods
    2. BA toPorts entry for port 8080 that includes an http rule listing the allowed method and path
    3. CA toFQDNs entry that lists the DNS name of the monitoring service
    4. DAn endpointSelector that matches the namespace in which the monitoring pods run, rather than the backend pods that receive traffic
    Show answer and explanation
    Correct answer: B

    Layer 7 HTTP rules such as method and path are written under toPorts with an http section. fromCIDR matches IP ranges, the endpointSelector picks the pods that the policy protects, and toFQDNs applies to egress destinations by DNS name.

  4. Question 8

    A workload in one namespace must call api.example.com over HTTPS. The provider's IP addresses change regularly, and the team wants the policy to keep working without manual edits. Which resource fits best?

    1. AA standard Kubernetes NetworkPolicy with an ipBlock listing the addresses the domain resolved to during the last change window
    2. BA standard Kubernetes NetworkPolicy with a namespaceSelector that points at the external provider's domain name
    3. CA CiliumNetworkPolicy egress rule that uses toFQDNs to match the domain name
    4. DA Service of type ExternalName combined with an Ingress resource that accepts the outbound request from the provider
    Show answer and explanation
    Correct answer: C

    toFQDNs lets Cilium match egress destinations by DNS name, so the rule keeps working as addresses change. A standard NetworkPolicy cannot match DNS names, an ipBlock goes stale, a namespaceSelector cannot target an external domain, and an Ingress handles inbound traffic only.

Service Mesh (4 questions)

  1. Question 9

    A team asks why Cilium's service mesh does not inject a proxy container into every application pod, which is what they are used to from sidecar-based meshes. Which explanation is correct?

    1. ACilium runs its L7 proxy per node, so application pods do not need a sidecar container injected into them
    2. BCilium adds one proxy per namespace through a mutating webhook, and that proxy is shared by every pod in the namespace
    3. CCilium moves all L7 processing into the kube-apiserver, so neither a node-level proxy nor a sidecar is needed on the worker nodes
    4. DCilium enforces L7 rules only with iptables chains in the kernel, so no proxy process is ever started on the node
    Show answer and explanation
    Correct answer: A

    Cilium Service Mesh uses an Envoy proxy on each node instead of a sidecar in every pod. The other options describe kernel-only L7 enforcement, per-namespace proxies, or L7 handling in the API server, none of which matches how Cilium handles L7 traffic.

  2. Question 10

    An operator wants traffic between pods on different nodes to be encrypted in transit, transparently, without changing application code or deploying certificates into the pods. Which Cilium capability fits?

    1. AA kube-proxy setting that enables HTTPS on NodePort services only
    2. BPer-pod TLS certificates issued by a sidecar that terminates and re-originates traffic in every application pod
    3. CTransparent node-to-node encryption using WireGuard or IPsec
    4. DAn Ingress annotation that forces TLS on every pod-to-pod connection in the namespace
    Show answer and explanation
    Correct answer: C

    Cilium's transparent encryption protects traffic between nodes with WireGuard or IPsec, so applications need no changes. Sidecar certificates require per-pod injection, kube-proxy settings only affect NodePort access, and Ingress annotations do not secure pod-to-pod traffic.

  3. Question 11

    A platform team wants infrastructure owners to manage listeners and addresses, while application teams manage only the HTTP routes to their own services. Which Kubernetes API model that Cilium implements matches this split?

    1. AGateway API, with Gateway resources owned by infrastructure teams and HTTPRoute resources owned by application teams
    2. BService type LoadBalancer, where each application team requests its own external IP and handles TLS in its own pods
    3. CKubernetes NetworkPolicy, where each application team writes ipBlock rules for its own pods and namespaces by hand, with no separate owner for listeners
    4. DEndpointSlice, where the platform team lists the backend addresses for every Service in the cluster by hand
    Show answer and explanation
    Correct answer: A

    Gateway API separates Gateway resources, which infrastructure teams own, from HTTPRoute resources, which application teams own, and Cilium implements this model. NetworkPolicy, EndpointSlice and LoadBalancer Services do not provide the same ownership split for listeners and routes.

  4. Question 12

    A team has an existing Kubernetes Ingress manifest and asks which Cilium component performs the HTTP-level handling for requests that arrive through that Ingress. Which is correct?

    1. AThe Envoy proxy that Cilium manages, which is configured from Ingress and Gateway API resources
    2. BHubble Relay, which reads the Ingress rules and routes HTTP traffic to the matching backend services
    3. CThe kube-proxy iptables chains on each node, which parse the HTTP path and host header before choosing a backend pod
    4. DThe cilium-operator, which receives each HTTP request and forwards it to the backend pod itself
    Show answer and explanation
    Correct answer: A

    Cilium's ingress handling runs through Envoy, which Cilium configures from Kubernetes resources. The operator does not carry HTTP traffic, Hubble Relay only aggregates flow data, and iptables rules cannot parse HTTP paths.

Network Observability (4 questions)

  1. Question 13

    Intermittent connection failures occur between a web pod and an API pod. An engineer needs to know whether packets were dropped by a network policy or lost elsewhere, and wants per-flow detail. Which data source gives this most directly?

    1. Akubectl describe on the API pod, which lists every network policy that has ever matched a packet from the web pod
    2. BThe kube-apiserver audit log, which records every packet exchanged between the web pod and the API pod
    3. CNode exporter CPU counters, which break down each TCP connection by the policy that accepted or dropped it
    4. DHubble flow records, which show each flow's source, destination and verdict such as forwarded or dropped
    Show answer and explanation
    Correct answer: D

    Hubble records flows along with their verdicts, which show whether a policy dropped or forwarded them. Audit logs record API requests rather than packets, kubectl describe does not report per-packet verdicts, and node exporter counters are system metrics.

  2. Question 14

    Which Hubble component aggregates flow data from the Hubble servers running on many nodes, so that one endpoint can query the whole cluster?

    1. AHubble Relay, which collects flow data from the Hubble servers on many nodes and exposes one cluster-wide endpoint
    2. BThe Hubble UI, a browser frontend that displays flows as a service map for the administrator who opens it
    3. CThe embedded Hubble server inside each cilium-agent, which keeps recent flows only for the endpoints on its own node
    4. DThe cilium-operator, which keeps flow records in its own database so they can be queried later
    Show answer and explanation
    Correct answer: A

    Hubble Relay gathers flows from the per-node Hubble servers and presents one cluster-wide endpoint for the UI and CLI. The embedded server only covers its own node, the UI reads from Relay rather than aggregating itself, and the operator does not store flows.

  3. Question 15

    An engineer needs to see only dropped flows for pods in the shop namespace, watched live from a terminal. Which tool and approach fit?

    1. AHubble CLI observe with filters for the DROPPED verdict and the shop namespace, which prints matching flows as they arrive
    2. Bkubectl get events in the shop namespace, which lists every dropped packet with its source and destination addresses
    3. CThe Hubble UI, which cannot be filtered by verdict or namespace and only shows flows from the most recent deployment in the cluster
    4. DA Prometheus query on node network byte counters, which lists each dropped flow with its source address
    Show answer and explanation
    Correct answer: A

    The Hubble CLI observe command can filter flows by verdict and namespace and streams the matches. Kubernetes events do not record per-packet drops, the Hubble UI supports filtering, and node byte counters are not flow records.

  4. Question 16

    What does Layer 7 visibility in Hubble add to a flow record for traffic that is redirected through the proxy?

    1. ARaw packet payloads for every TCP connection, including traffic that is encrypted end to end
    2. BApplication-level details such as HTTP method, path and response status for that traffic
    3. CThe CPU and memory use of the process that opened each connection, sampled once per second
    4. DThe Kubernetes labels and annotations of the pod that owns the process inside each container, copied from the Pod object
    Show answer and explanation
    Correct answer: B

    Layer 7 visibility shows application details such as HTTP method, path and status for traffic handled by the proxy. Hubble does not read encrypted payloads end to end, and it does not add per-process CPU samples or copy labels as L7 data.

Installation and Configuration (4 questions)

  1. Question 17

    A new cluster has just been set up with the Cilium CLI, and the engineer wants a quick summary of whether the Cilium components are healthy before deploying workloads. Which command should be run?

    1. Acilium uninstall, which removes the Cilium components from the cluster so that a clean install can start
    2. Bkubectl logs on the kube-proxy pod, which shows the datapath state that Cilium is currently using
    3. Ckubectl delete pod for each cilium-agent, which forces a restart so that the health summary is recalculated
    4. Dcilium status, which reports the health of the Cilium agents, the operator and related components
    Show answer and explanation
    Correct answer: D

    cilium status is the CLI check that summarises whether the Cilium components are running and healthy. uninstall removes Cilium, kube-proxy logs do not describe Cilium's state, and deleting agent pods is disruptive and does not report health.

  2. Question 18

    What is the main purpose of the cilium connectivity test command?

    1. AIt rotates the encryption keys that are used for transparent node-to-node traffic on a running cluster
    2. BIt removes stale security identities that remain after the pods which used them have been deleted from the cluster and its namespaces
    3. CIt measures raw throughput between nodes with a bandwidth benchmark and reports the results as a single number
    4. DIt deploys test workloads and checks pod-to-pod, pod-to-service and external connectivity under the installed configuration
    Show answer and explanation
    Correct answer: D

    The connectivity test creates test workloads and verifies the main traffic paths for the installed configuration. It is not a throughput benchmark, an identity cleanup tool, or a key rotation command.

  3. Question 19

    A team installs Cilium with kube-proxy replacement enabled. They want to confirm that Service traffic is handled by Cilium's datapath rather than kube-proxy. Which action gives the most reliable answer?

    1. ADelete the kube-proxy DaemonSet and assume Service routing is handled by Cilium, since the Helm chart was applied
    2. BRestart the CoreDNS deployment, which rewires Service virtual addresses so that they are handled by Cilium
    3. CRead the Cilium status output, which reports whether kube-proxy replacement is active
    4. DRun kubectl get pods to see which pods are attached to the Cilium datapath and which are not
    Show answer and explanation
    Correct answer: C

    The Cilium status output reports whether kube-proxy replacement is active, so it is the reliable check. Assuming the state from a Helm install is not verification, restarting CoreDNS does not change Service routing, and kubectl get pods does not show datapath attachment.

  4. Question 20

    A team wants to install Cilium with the cilium CLI onto a cluster and then turn on Hubble. Which order of steps is most sensible?

    1. AEnable Hubble first, since Hubble runs as the CNI plugin that the cilium installation depends on later
    2. BDelete kube-proxy and run the connectivity test before installing Cilium, so that the test can detect the old datapath
    3. CInstall Cilium, confirm the agents are healthy with the status command, and then enable Hubble
    4. DInstall Cilium and enable Hubble in one step without checking status, then remove the test namespace the install created
    Show answer and explanation
    Correct answer: C

    Install Cilium first, check that its components are healthy, and then enable Hubble on top of a working datapath. Hubble is not the CNI plugin, and a connectivity test cannot be meaningfully run before the installation it validates.

Cluster Mesh (4 questions)

  1. Question 21

    Two clusters are being connected with Cilium Cluster Mesh. Both were built from the same template, so their pod CIDR ranges overlap. An engineer wants pods in one cluster to reach pods in the other by pod IP. What is the problem?

    1. AOverlapping pod ranges make routes ambiguous, so the address ranges must be made distinct before the clusters can route to each other by pod IP
    2. BOverlap is acceptable, because Cilium translates each pod address using the cluster name before the packet leaves the node
    3. COverlap only matters for Service addresses, so pod-to-pod traffic across the clusters works without any change
    4. DCluster Mesh renumbers every pod automatically at connection time, which resolves the template overlap without any manual change to either cluster
    Show answer and explanation
    Correct answer: A

    Pod addresses that exist in two clusters cannot be routed unambiguously, so the pod CIDRs must be unique. Cluster Mesh does not translate or renumber pods, and overlap affects pod addresses as well as Services.

  2. Question 22

    Which requirement must every cluster meet before it joins a Cilium Cluster Mesh?

    1. AEach cluster must use the same pod CIDR range as the others so that routes match
    2. BEach cluster must have a unique name and cluster ID within the mesh
    3. CEach cluster must disable kube-proxy replacement so that Services are handled by iptables
    4. DEach cluster must run the Hubble UI so that cross-cluster flows can be displayed
    Show answer and explanation
    Correct answer: B

    Cluster Mesh identifies each member by a unique name and cluster ID, which is why both must be distinct. Pod CIDRs must not overlap rather than match, the Hubble UI is not a membership requirement, and kube-proxy replacement does not need to be disabled.

  3. Question 23

    A team wants one Service name to be reachable from clients in two clusters, with healthy backend pods from both clusters behind it. Which approach matches Cilium's Cluster Mesh behaviour?

    1. ACreate an ExternalName Service in each cluster that points at a hostname on the other cluster's ingress
    2. BMark the Service as global with a Cilium service annotation so that backends from the connected clusters are included in it
    3. CCreate two separate DNS A records by hand, one per cluster, and rotate them manually at each change
    4. DAdd a NetworkPolicy that allows the other cluster's pod CIDR to reach the Service's selected pods on every port the Service exposes
    Show answer and explanation
    Correct answer: B

    A global Service annotation tells Cluster Mesh to merge endpoints from connected clusters under one Service name. ExternalName Services and hand-managed DNS records do not merge backends, and a NetworkPolicy only permits traffic without creating a shared Service.

  4. Question 24

    A team wants a Service named payments in cluster A to be served by backends from both clusters A and B. Which setup is required?

    1. AThe Service must exist in both clusters with the same name and namespace, and be marked global in each of them
    2. BThe Service must be created only in cluster B, which then exports its endpoints to cluster A through the mesh automatically
    3. CThe Service must be exposed as a LoadBalancer in each cluster, and the team must hand-copy the external IPs into the other cluster
    4. DThe clusters must share one kube-apiserver, so that a single Service object is visible to the agents in both clusters
    Show answer and explanation
    Correct answer: A

    A global Service is defined in each participating cluster under the same name and namespace and marked as global there, so Cluster Mesh can merge the backends. Creating it in only one cluster, hand-copying external IPs or sharing a single API server are not how the feature works.

eBPF (3 questions)

  1. Question 25

    What does eBPF let Cilium do inside the Linux kernel?

    1. ACompile application code into WebAssembly modules that run inside each pod when it starts
    2. BRun sandboxed programs at kernel hook points to implement the datapath, policy enforcement and flow observability
    3. CStore cluster state in a distributed key-value database that every node can read from
    4. DReplace the Linux process scheduler with a user-space daemon that decides which pods run on each node and when they start
    Show answer and explanation
    Correct answer: B

    eBPF programs are verified and run inside the kernel at hook points, which Cilium uses for its datapath, policy and observability. The other options describe WebAssembly, a state store and a scheduler, none of which is what eBPF provides.

  2. Question 26

    A cluster has grown to thousands of firewall rules spread across long iptables chains, and each new connection now takes noticeably longer to classify. A team wants a datapath where a lookup does not need to walk a long sequence of rules. What does Cilium's eBPF datapath use for this?

    1. AA single long iptables chain that is reordered after each change so that frequent flows are matched first
    2. BA sidecar proxy in every pod that caches the policy decision for each destination address
    3. CA user-space daemon on each node that forwards every packet to a policy engine before it is delivered
    4. DeBPF maps, which are keyed lookup tables that the datapath queries directly for each packet
    Show answer and explanation
    Correct answer: D

    eBPF maps are keyed lookup tables, so the datapath finds the relevant entry directly instead of evaluating rules one by one. The other options keep a linear rule chain, add per-pod proxies, or send each packet through user space, which is not how the Cilium datapath works.

  3. Question 27

    Which two statements describe benefits of Cilium's eBPF datapath compared with an iptables-based datapath? (Choose two.)

    1. ARules are always evaluated in one fixed linear order, which makes behaviour simpler to predict under load
    2. BPrograms can be loaded and updated at runtime without rebuilding the Linux kernel
    3. CFlow observability can be collected in the kernel without injecting a sidecar into every application pod
    4. DNo minimum Linux kernel version is needed, because eBPF runs in the user-space network stack
    Show answer and explanation
    Correct answer: B, C

    eBPF programs are loaded into the running kernel, and observability can be gathered there without sidecars. Linear rule evaluation is the iptables behaviour that eBPF avoids, and eBPF needs a sufficiently recent kernel and runs inside the kernel rather than in user space.

BGP and External Networking (3 questions)

  1. Question 28

    A payments service runs as pods across several nodes. An external partner allowlists a single source IP address, and the team needs outbound traffic from those pods to leave with that fixed address. Which Cilium feature fits best?

    1. AA NodePort Service that forwards outbound requests from the partner network back into the payments pods
    2. BThe egress gateway feature, which sends selected pods' outbound traffic through a designated gateway node with a fixed source IP
    3. CAn Ingress resource that rewrites the source address of outgoing packets to a fixed value set in its annotations for every pod in the namespace
    4. DA NetworkPolicy with an ipBlock rule, which changes the source address of packets that match the rule
    Show answer and explanation
    Correct answer: B

    Cilium's egress gateway selects pods and routes their outbound traffic through a designated gateway node, which gives them a fixed source address. NodePort and Ingress handle inbound traffic, and NetworkPolicy filters traffic without rewriting source addresses.

  2. Question 29

    A cluster runs in native routing mode. Pods on nodes in one rack cannot reach pods on nodes in another rack, while node addresses work. What is most likely missing?

    1. AA NetworkPolicy that allows the other rack's pod CIDR to reach the backend pods on every port, which makes the switches install the routes automatically
    2. BRoutes for each node's pod range on the physical network, for example static routes or routes advertised with BGP
    3. CA kube-proxy mode change to ipvs, so that the switches learn pod addresses from the Service objects
    4. DHubble Relay on the racks, so that flow data tells the switches where each pod is currently running
    Show answer and explanation
    Correct answer: B

    In native routing the physical network must know how to reach each node's pod range, which is usually provided by static routes or by BGP advertisement. NetworkPolicy filters traffic without creating routes, kube-proxy mode does not affect switch routing, and Hubble only observes flows.

  3. Question 30

    Which two statements about egress traffic from pods are correct? (Choose two.)

    1. AThe kube-apiserver rewrites the source address of every egress packet before it leaves the node
    2. BTraffic from a pod to a destination outside the cluster is typically masqueraded to the node's address by default
    3. CHubble Relay applies egress masquerading, so the external network sees the address of the Relay pod instead
    4. DTraffic between pods inside the cluster keeps each pod's own source address, so no masquerading applies
    Show answer and explanation
    Correct answer: B, D

    Traffic leaving the cluster is usually masqueraded to a node address, while pod-to-pod traffic keeps the pod source address. The kube-apiserver and Hubble Relay do not rewrite packets, which is why those options are wrong.