Certifications · CCA · Mock Exam · Set 1

CCA Mock Exam · Set 1

Fifty multiple-choice questions, weighted question-for-question to the eight domains of the official CCA curriculum — ten on Architecture, nine on Network Policy, eight on Service Mesh, five each on Network Observability, Installation and Configuration, Cluster Mesh and eBPF, and three on BGP and External Networking. This is the first of two CCA papers on this course: it sticks close to definitions, component roles, and single-clue scenarios, the way the real associate-level paper leans early, before Set 2 pushes harder into layered "which of these silently breaks" traps. The CCA is a knowledge-based exam — no cluster, no terminal, nothing to break — so this is a question paper you sit cold, in one block, with no notes open. Answer first, then read the explanation directly beneath your choice; it is doing as much teaching as the question itself, and the domain tag on every item tells you exactly which page to reread if you miss it.

How this paper is weighted

☺ Like you're 10: The questions are shared out the same way the real test shares out its marks — the biggest topic gets the most questions, and here the split happens to come out in whole numbers.

The CCA's eight official domain weights — 20, 18, 16, 10, 10, 10, 10, 6 — sum to exactly 100%, and against fifty questions every one of them divides with no rounding at all: 10, 9, 8, 5, 5, 5, 5, 3, which also sum to exactly 50. That tidiness is a coincidence of picking fifty rather than some other paper size, not a property of the exam itself — don't read anything into it beyond "the arithmetic happened to be clean this time." What it does mean is that this paper's proportions track the real blueprint precisely, question for question, so your score by domain is a faithful little mirror of where the real 100% goes.

Sit it like the real thing

☺ Like you're 10: No notes, no open tabs, one sitting, straight through — and never leave a question blank, because a guess has a real chance of being right and a blank one never does.

The CCA is delivered online and remote-proctored, closed-book, with no documentation allowance — unlike the hands-on Kubernetes exams, there is no "browse the docs while you work" concession here, because there is no terminal to work in. Sit this paper the same way: close every other tab, set a single timer, and commit to an answer on every item even when you're genuinely unsure. Nothing published states whether Linux Foundation multiple-choice exams penalize a wrong guess beyond simply not earning the point — treat that as unconfirmed rather than fact — but the practical advice holds regardless: eliminate what you can, then commit. Never leave a question blank.

The paper — 50 questions across three blocks

☺ Like you're 10: Fifty questions, three blocks, every domain mixed into every block — read the question, pick one answer (or two, when it says so), then check yourself before moving to the next.

Each question names its domain in parentheses so you can total your score by domain afterward — the real exam won't label them, so once you've sat this cold, consider a second pass with the labels covered to see how many you can still place from content alone. A few questions are marked (Select TWO); full credit there needs both correct letters.

Block 1 — Q1–17

Q1 (Architecture). Which Cilium component runs as a DaemonSet on every node, watches the Kubernetes API, computes security identities, and programs the eBPF maps for that node's own endpoints?

• A. cilium-operator
• B. cilium-agent
• C. hubble-relay
• D. clustermesh-apiserver

Check the answer

B. cilium-agent is the per-node worker. cilium-operator does the cluster-wide, non-per-node jobs; hubble-relay aggregates flow data cluster-wide; clustermesh-apiserver exposes a cluster to its mesh peers.

Q2 (Network Policy). A Cilium security identity is derived from what, and what does that make it (rather than a pod's IP address)?

• A. The pod's IP address, refreshed every reconciliation
• B. The pod's labels — every pod sharing those labels shares one identity, and policy is written and enforced against that identity rather than the IP
• C. The node the pod happens to be scheduled on
• D. The container image digest

Check the answer

B. Because the identity travels with the labels rather than the address, policy keeps meaning the same thing when a pod is rescheduled onto a new IP.

Q3 (Service Mesh). What does "sidecarless" mean in Cilium's service mesh architecture?

• A. No mesh functionality exists unless a sidecar is manually injected into every pod
• B. The datapath already inspects every packet, so L4 mesh functions need no per-pod proxy; a single Envoy proxy runs once per node, invoked only when an L7 rule requires parsing
• C. Mesh traffic bypasses eBPF entirely and is handled by iptables instead
• D. Sidecarless is only available when Cilium runs without Kubernetes

Check the answer

B. L4 mesh concerns ride on the datapath Cilium already runs; only L7 needs a proxy, and that proxy is per node, not per pod.

Q4 (Network Observability). Because cilium-agent already inspects every packet to enforce policy, what can Hubble report on a flow essentially for free?

• A. Only the total byte count, with no other detail
• B. Source and destination identity, port, protocol, the verdict (FORWARDED, DROPPED, AUDIT), and — for a drop — the reason
• C. The full contents of the container's filesystem
• D. Only whether the flow used TCP or UDP, with no verdict information

Check the answer

B. Exporting what the agent already computed for enforcement is nearly free — identities, verdict, and drop reason, not raw payload inspection.

Q5 (Installation and Configuration). After running cilium install --version <x.y.z>, which command verifies that the agents, operator, and Hubble have all come up healthy before you trust the cluster?

• A. cilium sysdump
• B. cilium status --wait
• C. cilium config view
• D. cilium clustermesh status

Check the answer

B. cilium status --wait is the health check; the others dump diagnostics, read configuration, and check Cluster Mesh specifically.

Q6 (Cluster Mesh). What does Cluster Mesh provide once two clusters are connected?

• A. A shared container registry between the two clusters
• B. Pod-to-pod connectivity, shared identities, and merged service endpoints across the clusters — a policy written once means the same thing everywhere, and a Service can fail over to another cluster
• C. Automatic migration of running pods from one cluster to the other
• D. A single shared etcd instance replacing both clusters' control planes

Check the answer

B. Shared identities are what let one policy mean the same thing across cluster boundaries, and merged endpoints are what enable failover.

Q7 (eBPF). What does eBPF let Cilium attach small, verified programs to, without a kernel module or a reboot?

• A. Only user-space library calls
• B. Kernel hooks — the network driver (XDP), traffic control (tc), and the socket layer
• C. Only the container runtime's own API
• D. Only the Kubernetes API server's admission webhooks

Check the answer

B. XDP, tc and the socket layer are the hook points eBPF attaches to — no out-of-tree module, no reboot.

Q8 (BGP and External Networking). By default, how does a pod's traffic normally appear when it leaves the cluster toward an external destination?

• A. It leaves with the pod's own IP address, unmodified
• B. It is masqueraded behind its node's IP address
• C. It is dropped unless an egress gateway is configured
• D. It is routed through the Kubernetes API server first

Check the answer

B. Node-IP masquerading is the default egress behaviour — which is exactly why a stable, allowlistable source address needs an egress gateway on top of it.

Q9 (Architecture). Under Cilium's default cluster-pool IPAM mode, which component allocates the per-node PodCIDR blocks, and which component then hands out individual pod IPs from within that block?

• A. cilium-operator does both allocation and per-pod assignment
• B. cilium-operator allocates the per-node blocks from the cluster pool; the per-node cilium-agent then allocates individual pod IPs from its assigned block
• C. Each pod requests its own IP directly from the cloud provider's IPAM API
• D. kube-controller-manager performs both steps; Cilium is not involved

Check the answer

B. The operator does the cluster-wide carving; the agent does the fine-grained, per-node work — the same division of labour as everywhere else in the architecture.

Q10 (Network Policy). In a CiliumNetworkPolicy, what does the top-level endpointSelector field determine?

• A. Which external destinations the policy allows egress to
• B. Which pods the policy protects — the endpoints this policy's ingress and egress rules apply to
• C. Which Kubernetes namespace the policy itself is stored in
• D. Which Hubble flows get recorded for the selected pods

Check the answer

B. endpointSelector answers "which pods," not "which destinations" — the ingress and egress blocks answer that instead.

Q11 (Service Mesh). How does Cilium implement north-south Ingress routing, and how does that differ from its Gateway API support?

• A. Cilium supports Gateway API only; it has no Ingress controller at all
• B. Cilium offers an Ingress controller (ingressClassName: cilium) and, separately, a Gateway API implementation via a GatewayClass named cilium, with the relevant CRDs installed first
• C. Ingress and Gateway API are two names for exactly the same object type in Cilium
• D. Gateway API requires a sidecar in every pod; Ingress does not

Check the answer

B. Both exist side by side as separate implementations of separate APIs — one older and annotation-driven, one newer and role-oriented.

Q12 (Network Observability). Is Layer 7 flow visibility in Hubble on by default for a freshly installed Cilium cluster?

• A. Yes, every flow is parsed at L7 automatically with no configuration
• B. No — a flow is only parsed above L4 when a policy attaches L7 rules to it, which is what steers that traffic through the per-node Envoy proxy
• C. Yes, but only for traffic on port 443
• D. No, L7 visibility is permanently unavailable in Cilium regardless of configuration

Check the answer

B. L7 parsing is opt-in via policy, not a default — which is exactly why the permissive "match everything" rule pattern exists for gaining visibility without narrowing access.

Q13 (Installation and Configuration). A team runs cilium config set enable-l7-proxy true directly against a cluster whose Cilium install is managed by an Argo CD Application tracking a Helm values file in Git. What is the risk?

• A. There is no risk; cilium config set and the Helm values file are automatically kept in sync
• B. The command edits the live cilium-config ConfigMap directly, which will drift from the Git-tracked Helm values and likely get reverted on the next sync — the change should go into the values file instead
• C. cilium config set cannot be run against a GitOps-managed cluster under any circumstances
• D. The command permanently disables GitOps management for the cluster

Check the answer

B. A live CLI edit is exactly the kind of drift a reconciler exists to correct — on a GitOps-managed cluster, the source of truth is the values file, not the running ConfigMap.

Q14 (Cluster Mesh). Which set of requirements must hold across every cluster you plan to join with Cluster Mesh?

• A. Identical Kubernetes versions on every cluster, and nothing else
• B. A globally unique cluster name, a globally unique cluster ID, and strictly non-overlapping PodCIDRs across the meshed clusters
• C. All clusters must share a single control plane
• D. All clusters must use the kubernetes IPAM mode specifically

Check the answer

B. Name, ID and non-overlapping PodCIDRs are the three hard prerequisites — none of them concern Kubernetes version, control-plane sharing, or a specific IPAM mode.

Q15 (eBPF). What do eBPF maps hold in Cilium's architecture?

• A. Nothing — eBPF programs are entirely stateless by design
• B. The shared state eBPF programs need at line rate: endpoints, identities, service backends, and policy verdicts
• C. Only container image layers
• D. A complete copy of the Kubernetes API server's object store

Check the answer

B. Maps are how eBPF programs share state with each other and with cilium-agent without round-tripping through user space on every packet.

Q16 (BGP and External Networking). A partner's firewall will only allow traffic from one specific, allowlisted source IP, but pods calling that partner are normally masqueraded behind whichever node they land on. What Cilium feature solves this?

• A. Cluster Mesh
• B. An egress gateway — routing selected pods' external traffic through designated nodes so it always leaves from a known, stable address
• C. Hubble
• D. A CiliumClusterwideNetworkPolicy with no other configuration

Check the answer

B. An egress gateway is purpose-built for exactly this: a stable, allowlistable source address for traffic leaving toward one external destination.

Q17 (Architecture, Select TWO). Which TWO of the following are responsibilities of cilium-operator, as distinct from cilium-agent?

• A. Allocating per-node PodCIDR blocks under cluster-pool IPAM
• B. Garbage-collecting stale CiliumIdentity and CiliumEndpoint objects
• C. Programming the eBPF maps for a node's own endpoints
• D. Embedding the Hubble server that exports flow data for its node
• E. Enforcing the CiliumNetworkPolicy that selects a given endpoint

Check the answer

A and B. Both are cluster-wide, non-per-node jobs the operator alone does. C, D and E all happen inside cilium-agent, on the node where the endpoint actually lives.

Block 2 — Q18–34

Q18 (Architecture). A cluster runs in a cloud VPC where the underlying network fabric already knows how to route every node's assigned PodCIDR without any extra encapsulation. Which Cilium routing mode is the natural fit, and what do you avoid by choosing it?

• A. tunnel mode, because it always has the lowest MTU overhead
• B. native mode — packets are routed directly using the existing underlay, avoiding the encapsulation (and MTU cost) that VXLAN or Geneve tunnel mode adds
• C. eni mode, which is unrelated to routing and only affects IPAM
• D. There is no choice; Cilium always encapsulates by design

Check the answer

B. Native mode is the payoff for an underlay that already routes your PodCIDRs — tunnel mode exists for the case where it doesn't.

Q19 (Network Policy). A CiliumNetworkPolicy needs to allow ingress from kubelet health probes and other in-cluster scrapers, without listing every possible source by label. Which selector is built for exactly this?

• A. toFQDNs
• B. fromEntities, using one of Cilium's special sets such as cluster, world, host, remote-node, or kube-apiserver
• C. toCIDR
• D. endpointSelector

Check the answer

B. Entity selectors exist precisely for these broad, structural sources that don't map cleanly to a single label set.

Q20 (Service Mesh). What does the curriculum mean when it describes Gateway API as "role-oriented," compared with a plain Ingress object?

• A. Gateway API has no concept of roles; that term does not apply to networking APIs
• B. GatewayClass, Gateway, and HTTPRoute are split between infrastructure provider, cluster operator, and application developer respectively, each with its own RBAC boundary — where a single Ingress object mixes those concerns together
• C. It means only cluster administrators are permitted to create any Gateway API object
• D. It means Gateway API requires a separate Kubernetes cluster per role

Check the answer

B. Splitting one object into three, each owned by a different role, is exactly the improvement Gateway API is tested on.

Q21 (Network Observability). What does hubble-relay do that a single node's embedded Hubble server cannot do alone?

• A. It replaces cilium-agent as the component that enforces policy
• B. It aggregates node-local flow data into one cluster-wide API, which the hubble CLI and Hubble UI both query
• C. It performs IPAM allocation across the cluster
• D. It is only used during cluster installation and has no runtime role

Check the answer

B. Aggregation across nodes is relay's entire job — every per-node Hubble server only sees its own node's flows until relay stitches them together.

Q22 (Installation and Configuration). What does cilium connectivity test actually check?

• A. Only whether the Cilium container images can be pulled from the registry
• B. Pod-to-pod, pod-to-service, DNS, egress, and policy connectivity — a broad functional check that the datapath and policy engine are working end to end
• C. Only the cluster's DNS resolver, nothing else
• D. Whether the Kubernetes API server itself is reachable, and nothing about the CNI

Check the answer

B. It's a broad smoke test of the whole datapath, not a single narrow check — that breadth is why it's the standard first thing to run after install.

Q23 (Cluster Mesh, Select TWO). To make a Service's endpoints span every meshed cluster, a team annotates it service.cilium.io/global: "true". Which TWO statements correctly describe how it must be configured?

• A. The same annotation must be applied to a Service of the identical name and namespace in every participating cluster for its endpoints to merge
• B. Adding service.cilium.io/affinity: "local" makes the Service prefer local backends first, and fail over to another cluster's backends only if none are ready locally
• C. The annotation alone is sufficient on just one cluster; the others do not need the Service defined at all
• D. This annotation replaces the need for non-overlapping PodCIDRs across the mesh
• E. Global services require the kubernetes IPAM mode specifically and fail under cluster-pool

Check the answer

A and B. The Service has to exist, identically named and namespaced, in every cluster whose endpoints should merge — the annotation doesn't conjure it elsewhere. Affinity then controls the preference order once the merge happens. Non-overlapping PodCIDRs (D) and IPAM mode (E) are separate, unrelated requirements.

Q24 (eBPF). What role do the eBPF verifier and JIT compiler play when an eBPF program is loaded?

• A. The verifier optimizes the program for speed; the JIT checks it for safety
• B. The verifier proves the program is safe to run (no unbounded loops, no out-of-bounds memory access) before it is ever attached; the JIT then compiles it to native machine code for the host CPU
• C. Neither is used in Cilium; eBPF programs run as interpreted bytecode with no verification
• D. The verifier and JIT are Kubernetes API server components, unrelated to eBPF programs

Check the answer

B. Safety first, then speed — the verifier gates what's allowed to load at all, and the JIT is what makes the safe result fast.

Q25 (BGP and External Networking). How does Cilium's BGP control plane help an on-prem cluster receive real, routable LoadBalancer addresses without an overlay network?

• A. It replaces the need for a Kubernetes Service object entirely
• B. It peers with physical routers and advertises PodCIDRs and LoadBalancer VIPs, giving the cluster real routed addresses the way MetalLB traditionally would — folded into the CNI
• C. It only works when the cluster is running in a public cloud VPC
• D. It disables eBPF-based routing and falls back to iptables

Check the answer

B. Advertising routes to real routers is exactly the on-prem problem BGP support solves — no overlay needed once upstream routers know the way in.

Q26 (Architecture). Why does kubeProxyReplacement exist as a Cilium configuration option?

• A. Because eBPF cannot coexist with kube-proxy under any configuration
• B. Because eBPF's hash-map lookups and socket-level load balancing can shortcut the traditional kube-proxy datapath entirely, handling Service routing without iptables or IPVS rules
• C. Because Kubernetes deprecated kube-proxy and removed it from all supported versions
• D. Because it is required before Hubble can be installed

Check the answer

B. The option exists because eBPF can do the job faster and closer to the socket layer — not because kube-proxy is unsupported or a Hubble prerequisite.

Q27 (Network Policy). A CiliumNetworkPolicy's egress rule uses toFQDNs to allow traffic to api.stripe.com by hostname. What must also be present in that same policy's egress rules for the toFQDNs rule to ever actually resolve and work?

• A. Nothing else is required; toFQDNs resolves independently of any other rule
• B. A separate egress rule allowing DNS traffic to the cluster's DNS service — without it, the pod can never resolve the hostname in the first place, so the toFQDNs rule can never match anything
• C. An identical fromFQDNs rule on ingress
• D. A CiliumClusterwideNetworkPolicy specifically; toFQDNs cannot be used in a namespaced CiliumNetworkPolicy

Check the answer

B. DNS-first is the recurring trap across this whole domain: a hostname rule is useless if the lookup itself is silently blocked by the same policy that selected the pod.

Q28 (Service Mesh). How does Cilium encrypt node-to-node traffic in transit, and is this an application-level change?

• A. Applications must implement TLS themselves; Cilium has no transparent option
• B. Cilium can encrypt transparently with WireGuard (simpler, faster) or IPsec (older, more configurable, FIPS-relevant) — it is a configuration change, not an application change
• C. Only mTLS issued by cert-manager can provide node-to-node encryption in Cilium
• D. Encryption is only available for ingress traffic, never for east-west pod-to-pod traffic

Check the answer

B. Transparent, config-driven encryption is the point — no application code changes to get either WireGuard or IPsec running node to node.

Q29 (Network Observability). A team wants Hubble to start reporting HTTP methods, paths, and status codes for a pod's egress, without narrowing what that pod is actually allowed to reach. What is the recommended way to do this?

• A. It cannot be done — enabling L7 visibility always narrows what is permitted
• B. Write a permissive, catch-all L7 rule — such as http: [{}] matching every method and path — so Envoy still parses the traffic but nothing extra gets denied, beyond whatever the rest of the policy already restricts
• C. Add a pod annotation for visibility; this is still the current, supported mechanism in all Cilium releases
• D. Disable policy enforcement mode entirely for that namespace

Check the answer

B. A "match everything" L7 rule steers traffic through Envoy for visibility without acting as a narrower allow list. (Annotation-based visibility was removed in a past Cilium release, so C is outdated.)

Q30 (Installation and Configuration). At install time, which two configuration axes most directly shape how Cilium's datapath behaves for a given cluster?

• A. The container runtime in use, and the Kubernetes distribution's vendor
• B. IPAM mode (how pod IPs are allocated — cluster-pool, kubernetes, eni, azure) and routing mode (how packets move node to node — tunnel or native)
• C. The Helm chart's release name, and the namespace it is installed into
• D. The version of kubectl the operator happens to have installed locally

Check the answer

B. These two axes are independent and combine — the exam likes scenarios that mix them, like eni IPAM with native routing.

Q31 (Cluster Mesh). What is the role of the clustermesh-apiserver component?

• A. It replaces cilium-agent on every node once Cluster Mesh is enabled
• B. It exposes a cluster to its meshed peers, which is what lets identities and service endpoints be shared across cluster boundaries
• C. It is only used for Hubble UI rendering, unrelated to Cluster Mesh
• D. It performs IPAM allocation in place of cilium-operator

Check the answer

B. It's the component each cluster runs specifically so other clusters in the mesh have something to connect to.

Q32 (eBPF, Select TWO). Which TWO of the following are genuine advantages of an eBPF-based datapath over an iptables-based one, as Cilium implements it?

• A. eBPF gives effectively constant-time hash-map lookups rather than walking a linear rule chain that grows with every Service
• B. eBPF can shortcut the kernel networking stack entirely with socket-level load balancing, which is what kubeProxyReplacement relies on
• C. eBPF programs run without any safety verification, which is what makes them faster
• D. eBPF requires loading a custom out-of-tree kernel module before it can attach any program
• E. eBPF eliminates the need for a CNI plugin altogether

Check the answer

A and B. Both are real, curriculum-grounded advantages. C is false — eBPF programs are verified, not unverified; D is false — no out-of-tree module or reboot is needed; E is false — Cilium itself is the CNI plugin, eBPF is how it implements the datapath.

Q33 (Architecture). When someone says "Cilium is a CNI," what does that mean it is responsible for, beyond basic IP assignment?

• A. Nothing beyond assigning pod IP addresses; all other networking is handled elsewhere
• B. Implementing Kubernetes pod networking end to end — connectivity, optionally replacing kube-proxy for Service routing, identity-based policy enforcement, and network observability via Hubble, all from the same eBPF datapath
• C. Only image pulling and container startup, unrelated to networking
• D. Only DNS resolution inside the cluster, with connectivity handled by a separate plugin

Check the answer

B. The eight domains of this exam are really eight facets of that one sentence — connectivity, Service routing, policy, and observability, all riding the same datapath.

Q34 (Network Policy). How does Cilium treat a plain Kubernetes NetworkPolicy object, compared with its own CiliumNetworkPolicy CRD?

• A. Cilium ignores standard NetworkPolicy objects entirely; only CiliumNetworkPolicy has any effect
• B. Cilium enforces plain Kubernetes NetworkPolicy faithfully, and CiliumNetworkPolicy adds what standard NetworkPolicy cannot express — L7 rules, toFQDNs, entity selectors, explicit deny rules, and cluster-scoped policy
• C. CiliumNetworkPolicy can only be used once every NetworkPolicy in the namespace has been deleted
• D. The two are mutually exclusive; a cluster must pick exactly one to use anywhere

Check the answer

B. Cilium is a strict superset here — the standard object still works, and the CRD is where the extra expressiveness lives.

Block 3 — Q35–50

Q35 (Architecture). In Cilium's architecture, what is the difference in role between a routing mode (tunnel vs. native) and an IPAM mode (such as cluster-pool or eni)?

• A. They are two names for the same setting; choosing one automatically sets the other
• B. IPAM mode decides how pod IP addresses get allocated; routing mode decides how packets carrying those addresses actually move between nodes — the two are independent configuration axes that combine
• C. Routing mode only matters for Cluster Mesh; single-cluster installs can ignore it
• D. IPAM mode is decided by kube-proxy, not by Cilium

Check the answer

B. Keeping "who gets which address" separate from "how do packets with that address travel" is exactly what lets the two axes combine freely.

Q36 (Network Policy). Under Cilium's default policy enforcement mode, what happens to a pod's ingress the moment the very first CiliumNetworkPolicy selects it?

• A. Nothing changes; default mode never enforces anything regardless of how many policies select a pod
• B. That direction (ingress here) becomes default-deny — only traffic explicitly permitted by a selecting policy is now allowed; egress, if untouched by any policy, remains unaffected
• C. Both ingress and egress immediately become default-deny together, regardless of which direction the policy actually selects
• D. The pod is deleted and rescheduled with a fresh identity

Check the answer

B. Directions are independent — selecting one flips only that one to default-deny, which is the exact mechanism behind the DNS-egress trap elsewhere in this paper.

Q37 (Service Mesh). Compared to a per-pod sidecar proxy, what is the trade-off of Cilium's per-node Envoy proxy handling L7 mesh functions?

• A. There is no trade-off; per-node Envoy is strictly better in every respect
• B. A per-node proxy avoids per-pod injection overhead and startup-ordering bugs, but its blast radius if it misbehaves or is compromised is the whole node rather than a single pod
• C. Per-node Envoy cannot parse HTTP at all, only raw TCP
• D. Per-node Envoy requires every pod on that node to run the exact same application

Check the answer

B. Sidecarless is a real trade, not a free upgrade — you give up per-pod isolation of the proxy itself in exchange for a lighter footprint.

Q38 (Network Observability). During an incident where a service appears unable to reach a dependency, which single command most directly shows you every packet Cilium is actively dropping, live?

• A. cilium status --wait
• B. hubble observe --verdict DROPPED -f
• C. cilium sysdump
• D. cilium clustermesh status

Check the answer

B. A live, filtered stream of drops — with the identities and the denying rule — is the fastest path from "it's broken" to "here's why."

Q39 (Installation and Configuration). What is cilium sysdump for?

• A. It permanently deletes all Cilium configuration from the cluster
• B. It collects a single archive containing the diagnostic information support would typically ask for — logs, configuration, and cluster state relevant to Cilium
• C. It performs a live, in-place upgrade of Cilium to the newest release
• D. It runs the full connectivity test suite and nothing else

Check the answer

B. One archive, everything a support engineer would otherwise ask you to go collect by hand.

Q40 (Cluster Mesh). Put these three cilium clustermesh subcommands in the order you would typically run them when joining two clusters into a mesh for the first time: (i) connect, (ii) enable, (iii) status.

• A. status, connect, enable
• B. enable, connect, status
• C. connect, status, enable
• D. They can only be run in a single combined command; there is no separate enable/connect/status sequence

Check the answer

B. Enable Cluster Mesh on each cluster first, connect them to each other, then verify the result — a natural setup-then-verify order.

Q41 (eBPF). Why does an iptables-based Service datapath degrade as a cluster grows, in a way an eBPF-based one does not?

• A. iptables walks a linear rule chain per packet, and that chain grows with every additional Service, making lookups progressively slower; eBPF's hash-map-backed lookups stay close to constant time regardless of how many Services exist
• B. iptables and eBPF have identical performance characteristics at any scale; the difference is purely aesthetic
• C. iptables cannot express Service routing at all, at any cluster size
• D. eBPF is slower than iptables at small scale but was never intended to be fast

Check the answer

A. Chain length versus hash lookup is the whole story — it's a scaling argument, not a claim that iptables can't route Services at all.

Q42 (Architecture). Where does the core Hubble server that produces flow data actually run?

• A. As a separate Deployment with no relationship to cilium-agent
• B. Embedded within cilium-agent on each node, with hubble-relay separately aggregating that per-node data cluster-wide
• C. Only inside the Kubernetes API server
• D. Only inside hubble-ui, with no per-node component at all

Check the answer

B. Hubble rides inside the agent that's already inspecting every packet — relay is the separate piece that stitches per-node views into one.

Q43 (Network Policy, Select TWO). A platform team wants one default-deny baseline that applies across every namespace in the cluster, not scoped to any single team's namespace. Which TWO statements correctly describe how to achieve this with Cilium?

• A. Use CiliumClusterwideNetworkPolicy, which is cluster-scoped rather than namespaced, for exactly this kind of platform-wide baseline
• B. An explicit egressDeny or ingressDeny rule in that cluster-scoped policy takes precedence over allow rules defined by individual teams' own namespaced CiliumNetworkPolicy objects
• C. A namespaced CiliumNetworkPolicy in the kube-system namespace automatically applies cluster-wide to every other namespace
• D. Cluster-wide policy can only be expressed through a standard Kubernetes NetworkPolicy, never through a Cilium-specific CRD
• E. Deny rules are always overridden by any single team's allow rule, regardless of scope

Check the answer

A and B. The cluster-scoped CRD is the right tool, and deny beats allow everywhere in the cluster once it's written — not the other way around, and not something a namespace name alone (C) grants.

Q44 (Service Mesh). A platform team wants canary traffic-shifting, mutual TLS between services, and rich HTTP-level routing rules, without injecting a proxy container into every application pod. Which characteristic of Cilium's mesh most directly makes that combination possible?

• A. Cilium mesh functionality requires a sidecar in every pod, the same as any other mesh
• B. Its sidecarless design — the eBPF datapath already sees every packet for L4 concerns, and a single per-node Envoy handles the L7 and routing rules that need protocol awareness
• C. Cilium mesh only supports TCP and cannot perform any HTTP-aware routing
• D. mTLS is only available through a completely separate, unrelated product

Check the answer

B. Everything the team wants is available precisely because the L4 work is already done by the datapath, leaving Envoy free for the L7 and TLS work.

Q45 (Architecture). A team running Kubernetes on a cloud provider wants every pod to receive a real, routable address directly from the cloud's own VPC — not an address from an internal, cluster-only range. Which IPAM modes were named as examples that provide this?

• A. cluster-pool mode, which is designed specifically to hand out real cloud VPC addresses
• B. eni mode or azure mode — cloud-native IPAM integrations that hand pods real VPC addresses, unlike cluster-pool or kubernetes mode which allocate from internal per-node blocks
• C. kubernetes mode, because it always uses the cloud provider's own IPAM API
• D. There is no such mode; every Cilium IPAM mode allocates from an internal range only

Check the answer

B. eni and azure are the two named cloud-native integrations; cluster-pool and kubernetes mode both allocate from internal, cluster-scoped ranges instead.

Q46 (Network Policy). Two teams manage separate CiliumNetworkPolicy objects for their own namespaces, each with allow rules, and a security team also applies a cluster-scoped egressDeny rule targeting one specific external destination. What happens for pods matched by that deny rule?

• A. The deny rule is ignored because it originates from a different, cluster-scoped policy rather than the pods' own namespaced policy
• B. Deny rules take precedence over allow rules anywhere in the cluster — the cluster-scoped egressDeny blocks that destination regardless of what either team's own namespaced allow rules say
• C. Whichever policy was applied most recently wins, regardless of allow or deny
• D. The two teams' allow rules combine to override the single deny rule, because they are more specific

Check the answer

B. Deny wins, full stop — that's what makes a cluster-scoped deny useful as a platform-wide guardrail teams can't accidentally override with their own allow rules.

Q47 (Service Mesh). Summed up, what is the single architectural fact that makes Cilium's mesh sidecarless in the first place?

• A. Cilium simply chose not to support sidecars as a matter of preference, with no technical reason behind it
• B. The eBPF datapath already inspects every packet at the kernel level to enforce identity-based policy, so L4 mesh functions come for free without an additional per-pod proxy; only L7 needs Envoy, and that runs once per node
• C. Kubernetes forbids sidecar containers when Cilium is the CNI
• D. Sidecarless only applies to Ingress traffic, never to service-to-service traffic

Check the answer

B. Every sidecarless benefit in this paper traces back to this one sentence — the datapath was already there, so L4 mesh functions are nearly free.

Q48 (Architecture). A cluster shows cilium-operator crash-looping, while every cilium-agent pod remains healthy and existing pods keep networking fine. Which capability is most likely to degrade first?

• A. Pod-to-pod connectivity for existing pods, which stops working immediately
• B. Allocation of new PodCIDR blocks under cluster-pool IPAM and garbage collection of stale identity objects — cluster-wide, non-per-node functions that the operator alone performs
• C. Policy enforcement for all existing pods, which is disabled the instant the operator goes down
• D. Hubble flow visibility, since hubble-relay cannot function without the operator

Check the answer

B. Existing, already-programmed endpoints keep working because that's an agent job — it's the operator's cluster-wide bookkeeping that stalls first.

Q49 (Network Policy). A CiliumNetworkPolicy selects a pod, permits egress only to the cluster's DNS service on port 53 and to api.stripe.com via toFQDNs on port 443, and permits ingress from pods labeled app: checkout in the same namespace on port 8080. What happens to any other traffic that pod attempts, in Cilium's default enforcement mode?

• A. All other traffic in both directions is denied, because selecting the pod for either direction makes that direction default-deny — only what is explicitly permitted gets through
• B. Only the traffic explicitly denied by name is blocked; everything else is allowed by default regardless of what the policy lists
• C. Only ingress is affected; egress remains fully open regardless of the rules written
• D. The policy has no effect until a second, separate policy is also applied

Check the answer

A. This is the whole default-mode mechanism working correctly, in both directions at once — nothing exotic, just the rule applied consistently.

Q50 (Service Mesh). A reviewer argues Cilium "isn't really a service mesh" because it has no sidecar proxy running in any application pod. Is this a fair objection?

• A. Yes — without a sidecar in every pod, no mesh functionality of any kind is possible
• B. No — Cilium provides mesh capabilities (traffic control, encryption, L7 routing, mTLS) through its eBPF datapath plus a per-node Envoy instead of per-pod sidecars; sidecarless is an architectural choice, not the absence of mesh functionality
• C. Yes, but only because Cilium mesh features require Istio to be installed alongside it
• D. No, but only because Cilium disables Kubernetes networking entirely and replaces it outright

Check the answer

B. The last question of this paper is the same idea as the third, from the other direction: sidecarless is a design decision about where the proxy runs, not a gap in what the mesh can do.

Score yourself

☺ Like you're 10: Count your correct answers out of fifty, turn it into a percentage against the real 75% pass mark, then look at which domain cost you the most points — that second part is the part that actually helps.

The Linux Foundation's Multiple Choice Exam FAQ states that a score of 75% or above is required to pass any LF multiple-choice exam, and the CCA is one. Treat 75% here as a target to clear comfortably, not a calibrated prediction of the real sitting — this paper's wording is ours, not the CNCF's, and it isn't tuned to match the real exam's difficulty.

Whatever you scored, sort your misses into two piles before you move on, because on a paper like this one they mean different things. A question you got wrong because you genuinely didn't know the component or the rule is a real content gap — reread the linked domain page and redo that exact question cold in a couple of days. A question you got wrong despite roughly knowing the material — you second-guessed yourself, or confused two similarly worded options under time pressure — is a confidence problem, not a knowledge gap, and the fix is more timed reps, not rereading content you already have. Either way, don't retake this exact paper minutes later; go read first, then come back.

Where each domain is taught

☺ Like you're 10: Every question above traces back to one of a handful of pages. Go back to the page, not to the wider internet.

Nothing in this paper examines anything that isn't covered somewhere on this course. Where a domain is genuinely Cilium-specific, the pages live right here on Golden Astronaut; the sibling Platform Engineering CCA overview covers the same eight domains from the other side of the trio, and its Networking & Connectivity and Multi-cluster lessons go deeper into the two domains — BGP and Cluster Mesh — that lean most on general platform-engineering ground rather than Cilium alone.

Beyond the domain pages, the wider revision kit still applies: flashcards for the component names and terms, the self-check quiz for mixed recall, the glossary for anything a question assumed you already knew, and the CCA study plan for how to sequence all of this against your remaining prep time.

Check your answers

1. Architecture 20%; Network Policy 18%; Service Mesh 16%; Network Observability 10%; Installation and Configuration 10%; Cluster Mesh 10%; eBPF 10%; BGP and External Networking 6%.
2. Selecting the pod for egress turns that direction default-deny, and the database rule alone doesn't cover DNS — so the pod can no longer resolve any hostname at all, including ones needed by toFQDNs rules or by the application itself. The fix is an explicit DNS egress rule alongside every other egress rule.
3. From the pod's labels. Pods sharing the relevant labels share one numeric identity, so policy keeps meaning the same thing when pods are rescheduled onto new IPs — the datapath never has to chase IP churn.
4. A globally unique cluster name, a globally unique cluster ID, and strictly non-overlapping PodCIDRs across the meshed clusters.
5. A per-node Envoy proxy avoids per-pod injection overhead and startup-ordering bugs, but its blast radius if compromised or misbehaving is the whole node rather than a single pod — a real trade, not a free upgrade.
6. Officially published: the 90-minute duration and the 75% pass mark (from the Linux Foundation's Multiple Choice Exam FAQ). Not published: the real question count — any third-party figure for it is unverified. Confirm both, and everything else, on the official Linux Foundation CCA page and the CNCF certification page before you register.

That's the full sitting. Reread whichever domain cost you the most, give it a day to settle, then move on to Set 2 — the scenario-heavy paper that assumes this baseline is already solid.