10 CCA practice questions with full explanations on every option. Original questions written against the current CNCF curriculum.
Installation and Configuration
Q1. When you run 'cilium connectivity test', what does it verify about the cluster?
Reveal answer and explanations
AOnly DNS resolution
Incorrect. DNS is tested but not the sole focus.
BWhether all pods can reach the Kubernetes API server
Incorrect. Connectivity test is broader than API server access.
CPod-to-pod conn for ingress/egress/L7
Correct. The connectivity test validates pod-to-pod traffic in multiple directions and protocols.
DKubernetes node-to-node connectivity only
Incorrect. Node connectivity is network infrastructure; the test focuses on pod networking.
Cluster Mesh
Q2. In ClusterMesh, a service is annotated with `service.cilium.io/global: "true"`. What does this enable?
Reveal answer and explanations
AThe service is accessible cluster-wide with the same cluster-local IP
Incorrect. ClusterIP addresses are cluster-local; they can't be shared across clusters.
BThe service's endpoints are distributed across all connected clusters for load balancing
Incorrect. Endpoints aren't distributed; the service stays in its origin cluster with all endpoints there.
CThe service is replicated to all connected clusters with the same name and namespace
Incorrect. The service isn't replicated; it remains in its original cluster.
DAdvertised cluster-wide; reached via the local Service (same name+namespace)
Correct. The annotation marks a service as global; each connected cluster defines a Service with the same name and namespace, and Cilium stitches their endpoints together so workloads use their cluster-local Service to reach remote backends.
Service Mesh
Q3. What is the primary architectural advantage of Cilium's sidecarless service mesh approach over traditional sidecar-based service meshes?
Reveal answer and explanations
ALower per-pod overhead: eBPF in kernel, no sidecar
Correct. Cilium uses eBPF-based sidecarless service mesh to avoid the memory and CPU overhead of per-pod sidecar containers.
BEliminates the need for load balancing
Incorrect. Load balancing is still required and performed at the kernel level.
CProvides better application performance through sidecar optimization
Incorrect. Sidecarless approach provides better efficiency, not traditional sidecars.
DAutomatically handles multi-cluster communication
Incorrect. Multi-cluster support is through ClusterMesh, separate from the sidecar choice.
Service Mesh
Q4. In Cilium's Gateway API implementation, what does a ReferenceGrant resource accomplish?
Reveal answer and explanations
AIt authorizes a Gateway to reference a Service across namespaces
Correct. ReferenceGrant is a Gateway API resource that permits a Gateway in namespace A to reference a Service in namespace B, preventing unauthorized cross-namespace access.
BIt creates a temporary tunnel between namespaces for service-to-service traffic
Incorrect. ReferenceGrant doesn't create tunnels; it authorizes API references only.
CIt grants permissions for cross-cluster service mesh communication via ClusterMesh
Incorrect. ClusterMesh uses different CRDs (GlobalService, ClusterMeshService) for cross-cluster authorization.
DIt allows a pod to bypass mTLS when communicating with a gateway
Incorrect. ReferenceGrant doesn't affect mTLS enforcement; it's an authorization mechanism.
Network Observability
Q5. When you enable Hubble metrics export to Prometheus, which of the following metrics are typically available?
Reveal answer and explanations
AOnly flow rate and packet counts
Incorrect. Multiple metric categories are available.
BCilium-agent daemon status metrics only
Incorrect. Hubble exports network flow metrics, not daemon status.
CFlow, HTTP, DNS metrics by protocol
Correct. Hubble exports protocol-agnostic and protocol-specific metrics (HTTP, DNS, gRPC, etc.) to Prometheus.
DPod CPU and memory usage
Incorrect. Resource metrics are not Hubble's responsibility.
Network Policy
Q6. You write a CiliumNetworkPolicy with an egress rule that uses `toServices` and selects the cluster `kube-dns` Service. A teammate asks how the rule is enforced at packet time, given that the Service is a virtual ClusterIP. What is the most accurate description?
Reveal answer and explanations
ACilium expands `toServices` at policy-installation time into the matching backend pod identities, and enforcement happens against those backend identities
Correct. `toServices` is resolved to the current set of backend endpoints, and Cilium enforces the rule against the identities of those backend pods.
BCilium installs a static iptables rule that whitelists the Service ClusterIP itself, bypassing identity resolution
Incorrect. Cilium does not delegate enforcement to iptables for `toServices`; the lookup happens through identity-aware eBPF maps.
CCilium forwards the policy to the kube-apiserver, which mints an admission webhook that rejects pods talking to the Service
Incorrect. Admission webhooks gate API server requests, not pod-level packet enforcement, and Cilium does not install one for policy enforcement.
DCilium creates a temporary CiliumIdentity for the Service ClusterIP and uses that identity for L4 matching at runtime
Incorrect. Cilium identities are assigned to endpoints (pods) based on labels; a Service ClusterIP does not receive its own runtime identity in this flow.
eBPF
Q7. In Cilium, what is the primary role of an eBPF map?
Reveal answer and explanations
AA configuration file shipped with each cilium-agent that lists pinned BPF program paths
Incorrect. Maps are kernel data structures created at program-load time, not text configuration shipped on disk.
BA shared key/value data structure that lets eBPF programs and userspace exchange state across invocations
Correct. eBPF maps hold state (identities, policy lookups, conntrack entries) shared between programs and the agent during packet processing.
CA network-policy definition stored only in etcd and read by Hubble for flow correlation
Incorrect. eBPF maps live in the kernel and are accessed by datapath programs; they are not stored in etcd or Hubble.
DA kernel module that exposes the eBPF JIT compiler to userspace tooling
Incorrect. The JIT compiler is part of the kernel; eBPF maps are typed data containers, not compiler modules.
Cluster Mesh
Q8. A global service in ClusterMesh cluster-1 has 10 endpoints, but traffic from cluster-2 pods shows 70% packet loss. The clusters are directly connected via a dedicated network link. What is the most likely cause?
Reveal answer and explanations
AThe ClusterMesh egress gateway is filtering traffic from cluster-2; check policy
Incorrect. ClusterMesh doesn't use egress gateways for inter-cluster service traffic.
BThe clustermesh-apiserver in cluster-1 is overloaded and dropping endpoint updates
Correct. High packet loss to remote service endpoints typically indicates the clustermesh-apiserver isn't reliably distributing endpoint updates, so cluster-2 holds stale or partial endpoint knowledge and blackholes traffic to backends that no longer exist.
CCross-cluster service traffic is being routed through a misconfigured pod CIDR overlap that causes asymmetric routing
Incorrect. CIDR overlap would be caught during ClusterMesh setup; setup validation prevents this.
DService affinity is set to 'local', causing cluster-2 to fail over to cluster-1's endpoints with high latency
Incorrect. With affinity=local, cluster-2 prefers its own local backends and only routes to cluster-1's remote endpoints when no healthy local backend exists, which is a routing preference, not a 70% partial loss.
Service Mesh
Q9. When using Cilium's Gateway API implementation, what does a 'HTTPRoute' resource specifically define?
Reveal answer and explanations
AHTTP protocol version requirements
Incorrect. HTTP version is part of routing context but not HTTPRoute's primary purpose.
BHTTP path/host matching and traffic split
Correct. HTTPRoute defines how HTTP requests are routed to backend services based on hostname, path, and headers.
CDNS resolution rules for gateways
Incorrect. DNS is separate from routing definitions.
DSSL/TLS certificate configuration
Incorrect. TLS is handled by TLSRoute, not HTTPRoute.
Service Mesh
Q10. A TLSRoute in Cilium's Gateway API specifies: ```yaml
passthrough: true
``` What happens to TLS termination and SNI routing?
Reveal answer and explanations
AThe gateway terminates TLS and reroutes based on the SNI value
Incorrect. Passthrough mode doesn't terminate TLS; it avoids decryption.
BPassthrough mode disables all TLS validation; traffic is routed without encryption
Incorrect. Passthrough mode preserves TLS encryption; it doesn't disable validation.
CTLS not terminated; encrypted traffic proxied with SNI routing
Correct. In passthrough mode, the gateway proxies encrypted TLS traffic directly to backends without terminating, preserving SNI information for backend routing decisions.
DThe gateway requires SNI to be decrypted, but TLS renegotiation happens at the backend
Incorrect. Passthrough doesn't terminate; SNI remains encrypted in the TLS ClientHello.