CCA Mock Exam · Set 2
Forty-five multiple-choice questions, sat in one 90-minute closed-book block, weighted to the eight official CCA domains in the same proportion the CNCF weights them — 9 questions on Architecture (20%), 8 on Network Policy (18%), 7 on Service Mesh (16%), 5 each on Network Observability (10%) and Cluster Mesh (10%), 4 each on Installation and Configuration (10%) and eBPF (10%), and 3 on BGP and External Networking (6%) — the exact split from the CCA blueprint page. Every question below has a full explanation folded underneath it, so you can grade honestly instead of guessing whether your reasoning was right for the right reason. This is Set 2 of two, a completely separate and unseen paper from Set 1 — built for after that first sitting stops surprising you, not as a repeat of it. If you haven't worked through the blueprint, the study plan, and the untimed practice bank yet, start there — this paper measures whether that prep survives a clock, not whether you've read about eBPF maps and identity-based policy.
Remember the hallway with a backpack-colour rule at every door instead of a clipboard? You've now studied that hallway one topic at a time — the floor tiles, the rulebook, the mesh of doors, the guest-list camera, the setup crew, the two-building bridge, the fast-lookup trick, the road out of the building. This is the pop quiz that asks about all eight, mixed together, in the order a real quiz would ask them, with a clock running and no flipping back to reread a chapter mid-question. It's a brand new set of questions from the one you already sat — same eight topics, same clock, nothing memorized from last time will help you guess your way through this one.
Where Set 2 sits in your CCA prep
☺ Like you're 10: First you learn each topic separately, then you drill loose questions, then you sit one timed quiz — and once that one stops surprising you, you sit a second, unseen one to prove the fix actually stuck.
The natural sequence on this course is: read the CCA blueprint for the eight domains and their real weights, follow the study plan's day-by-day build, work the untimed practice bank until nothing there surprises you, sit Set 1 as your first honest measurement of all eight domains at once under a clock, fix precisely the domain that swallowed most of your misses, and only then sit this paper — Set 2 — as confirmation the fix held on material you haven't already seen the answer to. This paper assigns questions to each domain in the exact proportion the CNCF assigns them, the same as Set 1, so a weak score in one domain here is unusually actionable: it tells you precisely which section of the blueprint to reread, not just that you "did badly" in some vague sense.
| Stage | What you do | What it tells you |
|---|---|---|
| 1 · Build the vocabulary | Read the blueprint and follow the study plan's manifest-from-memory drills. | Whether you know the material at all — untimed, open-book. |
| 2 · Drill loose questions | The practice bank, untimed, reading every explanation even for questions you got right. | Whether you can recognize the right answer among convincing distractors. |
| 3 · Sit Set 1 | Set 1. One 90-minute block, no pausing, all 45 questions. | Your pacing under a clock, and exactly which domain is still soft. |
| 4 · Fix gaps, then sit Set 2 | Re-drill only the domain you missed, then sit this page — a fresh, unseen paper — a day or two later. | Whether the gap is actually closed, not just familiar from having seen the exact question once. |
The CNCF doesn't publish CCA's real question count — the blueprint's logistics table already says so plainly, and this paper takes that seriously rather than inventing a precision the CNCF itself doesn't claim. 45 was chosen because it splits cleanly into three 15-question, 30-minute blocks across a realistic 90-minute sitting, and because 45 divides by the real domain weights into whole numbers of questions — 9 / 8 / 7 / 5 / 5 / 4 / 4 / 3 — without much rounding. Treat that shape as this course's own study scaffolding, not a leaked format.
Sit it like the real thing
☺ Like you're 10: No notes, no open tabs, one sitting, go — and if you're not sure, answer anyway, because a blank answer earns the same zero as a wrong one.
CCA is online, remote-proctored, and closed-book — no notes, no browser tab, no this course, no colleague, no AI assistant, once the clock starts. Sit this practice paper under the same restriction. Close every other tab, and treat the 45 questions below exactly as you would a locked-down sitting: read the stem once, commit to an answer, and only then open the explanation underneath it — peeking first turns a diagnostic into a comprehension exercise and tells you nothing about whether you'd have gotten there cold.
Linux Foundation multiple-choice exams don't publish a separate penalty for a wrong guess beyond simply not earning the point, so the correct strategy is unambiguous: never leave a question blank. Eliminate what you can, then commit to your best remaining option.
The 90-minute duration and the 75% pass mark reflect the Linux Foundation's own CCA page and its general Multiple Choice Exam FAQ at the time of writing, per the blueprint's logistics table — but the exact question count is not published for CCA at all, and this paper's 45-question, 3-block shape is this course's own construction, not a leaked format. This is an independent, unofficial study resource, not affiliated with the CNCF or the Linux Foundation. Confirm current duration, pricing, and pass mark on the official Linux Foundation CCA page before you register.
Your 90-minute budget
☺ Like you're 10: Forty-five questions, ninety minutes — three even blocks of thirty minutes each, so you can check your pace roughly every half hour.
Forty-five questions in 90 minutes averages exactly two minutes each, and the paper is split into three 15-question, 30-minute blocks so you have a clean checkpoint to compare against, rather than discovering with ten minutes left that you're only on question 20. Every block mixes all eight domains, the same way a real exam does — you won't see all 9 Architecture questions bunched together at the start.
If a question runs past about two minutes without you being confident, eliminate what you can, commit to your best remaining guess, and move on — there's no folded worked solution to peek at mid-paper the way a hands-on lab bank might tempt you with, since each explanation sits directly underneath its own question.
The paper — 45 questions in exam order
☺ Like you're 10: Forty-five questions, three blocks of fifteen, every topic mixed into every block — read the stem, pick one answer (or two, when it says so), then check yourself before moving on.
Read each stem once, pick your answer, and only then open the explanation underneath it. Each question is tagged with its domain in parentheses so you can total your score by domain afterward — on the real exam you won't get that label, so once you've sat this paper, consider a second pass with the tags covered to see how many you can still place on content alone. Three questions below are marked (Select TWO), matching the real exam's multiple-response format — full credit requires both correct letters.
Block 1 — Q1–15 (minutes 0–30)
Q1 (🦉 Architecture). Which statement correctly describes cilium-agent and how it runs across a cluster?
- A. It runs once per cluster and only handles IPAM
- B. It runs as a DaemonSet, one per node, watching the Kubernetes API, computing security identities, and programming the eBPF maps that enforce policy for that node's pods
- C. It runs only inside
hubble-relayand has no eBPF responsibilities - D. It's a CLI tool invoked manually before every deploy
Check the answer
B. One cilium-agent per node is the whole architecture's foundation — it watches the API server, derives identities, and programs that node's own eBPF maps.
Q2 (🐢 Network Policy). A pod is rescheduled onto a brand-new node and gets a brand-new IP address. What does Cilium policy actually key on, and why does that matter here?
- A. The pod's IP address, recalculated fresh on every restart
- B. The pod's labels — every pod sharing those labels shares one security identity, and it's the identity, not the IP, that travels with a flow and is what policy is written against
- C. The node's hostname the pod happens to land on
- D. A random UUID generated at pod creation and never reused
Check the answer
B. Labels stay stable when IPs churn, which is exactly why identity-based policy survives autoscaling and rescheduling without a single rule needing to change.
Q3 (🐦 Service Mesh). Cilium's mesh is described as sidecarless. What does that actually mean for L4 mesh functions?
- A. Cilium requires a sidecar proxy injected into every pod for both L4 and L7 traffic
- B. Because the datapath already inspects every packet to enforce policy, L4 mesh functions need no per-pod proxy at all — the per-node Envoy only runs, once per node, when an L7 rule needs it
- C. Cilium has no mesh capability at all without installing a sidecar mesh alongside it
- D. Sidecarless means Hubble runs without an agent
Check the answer
B. The datapath doing double duty for policy and L4 mesh functions is the whole reason no per-pod proxy is needed for that layer.
Q4 (🐘 Network Observability). Because the agent already inspects every packet to enforce policy, exporting a Hubble flow record is nearly free. What does that record typically carry?
- A. Only the total byte count of the connection
- B. Source and destination identity, port, protocol, a verdict such as FORWARDED, DROPPED or AUDIT, and a drop reason when applicable
- C. The pod's full container image digest
- D. Nothing beyond a timestamp
Check the answer
B. Hubble is riding on data the agent already computed for policy enforcement — identity, port, protocol, verdict, and a drop reason — not collecting anything new.
Q5 (🦉 Architecture, Select TWO). Which TWO IPAM modes hand pods real, routable addresses straight from the cloud provider's own network, rather than carving them out of a cluster-internal pool?
- A.
kubernetes - B.
cluster-pool - C.
eni - D.
azure - E.
tunnel
Check the answer
C and D. eni and azure assign real, cloud-routable addresses. kubernetes mode reuses each node's PodCIDR, and cluster-pool — the default — has the operator carve per-node blocks out of one cluster-wide pool; neither hands out cloud-native addresses. tunnel is a routing mode, not an IPAM mode.
Q6 (🐿️ Cluster Mesh). What does Cluster Mesh actually give you across two or more clusters?
- A. Only shared dashboards — no networking changes at all
- B. Pod-to-pod connectivity, shared identities, and merged service endpoints across clusters — a policy written once means the same thing everywhere it's meshed, and a Service can fail over without a separate global load balancer in front of it
- C. A single shared control plane replacing each cluster's own API server
- D. Automatic conversion of every Service into type LoadBalancer
Check the answer
B. Cluster Mesh's whole value is connectivity, identity, and service-endpoint merging across clusters — not a shared control plane, and not an automatic Service-type change.
Q7 (🐢 Network Policy). What does the endpointSelector field in a CiliumNetworkPolicy do?
- A. Names which pods the policy protects
- B. Names the artifact repository used for policy backups
- C. Sets a retry count for failed policy evaluations
- D. Declares which node the policy's own agent runs on
Check the answer
A. endpointSelector is the "protected pods" half of a policy — everything under ingress/egress is then a rule about what those selected pods may talk to.
Q8 (🔬 eBPF). Which kernel hooks does eBPF attach small, verified programs to, without loading a kernel module or requiring a reboot?
- A. Only the filesystem layer
- B. The driver (XDP), traffic control (tc), and the socket layer
- C. The BIOS boot sequence
- D. The container runtime's image cache
Check the answer
B. XDP, tc, and the socket layer are the three hook points the curriculum names — all reachable with no kernel module and no reboot, which is a large part of eBPF's appeal.
Q9 (🐦 Service Mesh). Cilium's sidecarless mesh is often contrasted with a sidecar-based mesh. Which statement correctly names the tradeoff?
- A. Sidecarless has strictly more L7 features with no downsides at all
- B. Sidecarless avoids an injection webhook, a per-pod memory and CPU tax, and app/sidecar startup-ordering races — traded against a thinner L7 feature set and a proxy whose blast radius is the node rather than a single pod
- C. Sidecar-based meshes require no proxy at all
- D. There is no meaningful difference between the two approaches
Check the answer
B. Know both sides of this trade — the curriculum names the comparison directly, and it cuts both ways rather than being a strict win for either architecture.
Q10 (🦫 Installation and Configuration). Which command stands Cilium up on a cluster, and which one confirms every component came up healthy before you rely on it?
- A.
cilium installstands it up;cilium status --waitconfirms agents, operator and Hubble are healthy - B.
cilium sysdumpstands it up;cilium installconfirms health - C.
cilium config setstands it up;cilium connectivity testconfirms health - D. There is no dedicated install command — Cilium is installed only via raw
kubectl apply
Check the answer
A. cilium install and cilium status --wait are the two verbs to recognize for "stand it up" and "prove it's healthy."
Q11 (🦉 Architecture). Which piece of work belongs to cilium-operator specifically because it must not be duplicated per node?
- A. Programming per-pod eBPF policy maps
- B. Cluster-pool IPAM allocation and garbage-collecting stale
CiliumIdentityandCiliumEndpointobjects - C. Running the per-node Envoy proxy
- D. Rendering the Hubble UI's live service map
Check the answer
B. IPAM allocation and identity/endpoint garbage collection are cluster-wide bookkeeping — running them once, in the operator, is exactly what avoids per-node duplication.
Q12 (🐢 Network Policy, Select TWO). Which TWO of the following are genuine, named entity selectors usable in a CiliumNetworkPolicy's fromEntities/toEntities?
- A.
remote-node - B.
kube-apiserver - C.
cluster-pool - D.
sysdump - E.
retryStrategy
Check the answer
A and B. remote-node and kube-apiserver are two of Cilium's built-in entities, alongside world, cluster and host. cluster-pool is an IPAM mode, sysdump is a diagnostics command, and retryStrategy belongs to an entirely different project's CRD.
Q13 (🌐 BGP and External Networking). A partner's firewall wants a stable, allowlistable source address for pod egress, but pods normally leave masqueraded behind their node's IP. Which Cilium feature solves that?
- A.
hubble-relay - B. An egress gateway, routing selected pods' external traffic through designated nodes so it always leaves from one known address
- C.
clustermesh-apiserver - D. The per-node Envoy proxy
Check the answer
B. An egress gateway is the purpose-built answer to "give me one stable source IP" — none of the other three components touch outbound source addressing.
Q14 (🐿️ Cluster Mesh). Which of these is not one of Cluster Mesh's hard requirements?
- A. A globally unique cluster name for every participating cluster
- B. A globally unique cluster ID for every participating cluster
- C. Strictly non-overlapping PodCIDRs between meshed clusters
- D. Every meshed cluster must run in the same cloud region
Check the answer
D. Unique name, unique ID, and non-overlapping PodCIDRs are the three real requirements; matching cloud regions is never one of them.
Q15 (🐘 Network Observability). How do hubble-relay, the hubble CLI, and hubble-ui divide responsibility?
- A.
hubble-relayaggregates every node's local flows into one cluster-wide API; the CLI queries that API directly;hubble-uirenders a live, clickable service map - B.
hubble-uiaggregates the flows;hubble-relayonly serves the web page - C. The CLI and
hubble-relayare the same binary with different flags - D.
hubble-uiruns entirely insidecilium-operator
Check the answer
A. Relay aggregates, the CLI queries, and the UI visualizes — three distinct jobs built on the same aggregated flow stream.
Block 2 — Q16–30 (minutes 30–60)
Q16 (🐦 Service Mesh, Select TWO). Which TWO of the following are named benefits of Gateway API over Ingress, per the CCA curriculum?
- A. It's role-oriented, splitting
GatewayClass/Gateway/HTTPRouteacross the infrastructure provider, cluster operator and application developer, each with their own RBAC - B. It requires a sidecar in every pod
- C. It's expressive by specification — header, method and weighted routing built into the API rather than bolted on as vendor annotations
- D. It eliminates the need for a Service object entirely
- E. It only works when traffic is encrypted with IPsec
Check the answer
A and C. Role-oriented separation and specification-level expressiveness are two of the curriculum's named benefits, alongside portability and extensibility. B, D and E describe nothing Gateway API actually claims.
Q17 (🦉 Architecture). Hubble is described as "embedded directly in the agent." What does that mean for how it's deployed?
- A. It ships as a completely separate DaemonSet from
cilium-agent - B. It runs inside
cilium-agentitself, withhubble-relayaggregating flows cluster-wide andhubble-uirendering the live map on top of that - C. It requires its own dedicated eBPF maps unrelated to policy enforcement
- D. It only works once Cluster Mesh is enabled
Check the answer
B. Hubble rides inside the same agent process that already enforces policy — relay and UI are the layers built on top of that embedded stream.
Q18 (🐢 Network Policy). What does attaching an L7 rules block — http, dns, or kafka — to a toPorts entry actually trigger?
- A. It routes that traffic through the per-node Envoy proxy for parsing
- B. It disables policy enforcement for that port entirely
- C. It forces the traffic to skip the eBPF datapath completely
- D. It automatically enables Cluster Mesh for that Service
Check the answer
A. An L7 rules block is what routes a flow through Envoy for parsing — that's also why L7 visibility in Hubble isn't free until a policy asks for it.
Q19 (🦫 Installation and Configuration). What does cilium connectivity test actually check in one run?
- A. Only DNS resolution
- B. A full pod-to-pod, pod-to-service, DNS, egress and policy check
- C. Only whether a Helm values file is syntactically valid
- D. Only Hubble's own health, nothing about pod networking
Check the answer
B. It's a single command covering the whole connectivity surface — pod-to-pod, pod-to-service, DNS, egress, and policy — not a narrow one-purpose check.
Q20 (🐦 Service Mesh). What does Cilium ship for north-south traffic, and how is each one named on a cluster?
- A. An Ingress controller reached via
ingressClassName: cilium, and a Gateway API implementation reached via aGatewayClassnamedcilium - B. Only a Gateway API implementation — Cilium has no Ingress controller at all
- C. A dedicated load-balancer product sold separately from Cilium
- D. Both are configured only through the
hubbleCLI
Check the answer
A. Cilium ships both an Ingress controller and a Gateway API implementation, each addressable by its own class name.
Q21 (🦉 Architecture). What role does the per-node Envoy proxy play, and how is it deployed relative to pods?
- A. One instance per pod, injected as a sidecar
- B. One instance per node — not per pod — handling any policy that needs Layer 7 parsing
- C. One instance per cluster, shared by every node
- D. It only runs once Cluster Mesh is enabled
Check the answer
B. One Envoy per node, invoked only for L7 rules, is the load-bearing detail behind Cilium's whole sidecarless design.
Q22 (🐿️ Cluster Mesh). Which annotation, applied to a Service of the same name and namespace in each meshed cluster, merges endpoints from every meshed cluster into that Service?
- A.
service.cilium.io/affinity: "local" - B.
service.cilium.io/global: "true" - C.
cilium.io/enforce: "always" - D.
argocd.argoproj.io/sync-wave
Check the answer
B. service.cilium.io/global: "true" is what actually merges endpoints across meshed clusters into that one Service.
Q23 (🐢 Network Policy). In Cilium's default enforcement mode, what happens to an endpoint that no policy has yet selected?
- A. It allows everything, in both directions, until some policy selects it
- B. It denies everything until explicitly allowed
- C. It is never enforced regardless of any policy written later
- D. It is deleted automatically by
cilium-operator
Check the answer
A. Under default mode, an unselected endpoint allows everything — selecting it is precisely what flips that direction to default-deny.
Q24 (🐦 Service Mesh). In Gateway API's role-oriented model, which actor typically owns the GatewayClass resource?
- A. The application developer
- B. The infrastructure provider
- C. The cluster operator
- D. Hubble
Check the answer
B. GatewayClass sits with the infrastructure provider, Gateway with the cluster operator, and HTTPRoute with the application developer — each layer with its own RBAC boundary.
Q25 (🐘 Network Observability). L7 visibility in Hubble is not on by default. What has to happen for a flow to be parsed above Layer 4?
- A. Nothing — Hubble parses L7 for every flow automatically
- B. A policy must attach an L7
rulesblock to that traffic, which is exactly what routes it through the per-node Envoy for parsing - C.
hubble-relaymust be restarted manually - D. The cluster must be running in native routing mode
Check the answer
B. No L7 rule, no L7 parsing, no L7 visibility — the three are the same fact stated three ways.
Q26 (🦉 Architecture). What does clustermesh-apiserver do?
- A. Runs the Hubble UI
- B. Exposes a cluster's identities and services to its peers once Cluster Mesh is enabled
- C. Replaces
cilium-agenton every node - D. Handles IPAM allocation instead of
cilium-operator
Check the answer
B. It's the component whose entire job is exposing one cluster's state to its meshed peers — nothing about it replaces the agent or the operator.
Q27 (🐢 Network Policy). A pod already selected by policy under default enforcement mode gets one new egress rule added, allowing traffic to its database. What's the practical consequence people keep getting bitten by?
- A. Nothing changes for any other egress destination
- B. Egress becomes default-deny for everything else too — including DNS — since selecting the pod is what flips that direction to default-deny
- C. Ingress is denied instead of egress
- D. The rule is silently ignored because only one rule was added
Check the answer
B. This is the classic exam trap and the classic outage — one narrow allow rule quietly closes off every other egress destination for that pod, DNS included.
Q28 (🦫 Installation and Configuration). Reading and writing Cilium's live configuration through cilium config view / cilium config set edits which underlying object, and what's the caveat on a GitOps-managed cluster?
- A. It edits the
cilium-configConfigMap and restarts agents; on a GitOps-managed cluster, change the Helm values file instead so the change survives reconciliation - B. It edits a Kubernetes Secret and requires no restart
- C. It has no effect until the next full
cilium install - D. It only affects the local CLI session, never the cluster
Check the answer
A. A direct config set is real but transient on a GitOps-managed cluster — the next reconciliation reverts it unless the Helm values file is updated instead.
Q29 (🔬 eBPF). What do the verifier and the JIT compiler each do to an eBPF program before it runs in the kernel?
- A. The verifier proves the program is safe; the JIT compiler turns it into native machine code
- B. The verifier compiles it to native code; the JIT compiler proves it's safe
- C. Both do the same thing, run twice for redundancy
- D. Neither runs unless XDP is explicitly enabled
Check the answer
A. Safety proof, then compilation to native code — in that order, and both run for every eBPF program regardless of which hook it attaches to.
Q30 (🌐 BGP and External Networking). How does Cilium's BGP control plane get on-prem clusters properly routed addresses without an overlay network?
- A. By tunnelling every packet through VXLAN regardless of configuration
- B. By peering with real routers and advertising PodCIDRs and LoadBalancer VIPs directly — the same job MetalLB does, folded straight into the CNI
- C. By requiring every pod to have a public IP address
- D. It can't — BGP is only usable in cloud environments
Check the answer
B. BGP peering with real routers is precisely what lets an on-prem cluster get proper routed addresses without wrapping every packet in an overlay.
Block 3 — Q31–45 (minutes 60–90)
Q31 (🦉 Architecture). Under cluster-pool IPAM mode — the default — where do a node's pod addresses actually come from?
- A. Each node's own statically configured PodCIDR, set by hand
- B. The operator carves per-node blocks out of one cluster-wide pool
- C. Directly from the cloud provider's ENI allocation
- D. A random address chosen fresh per pod at creation
Check the answer
B. Cluster-pool mode is defined by exactly this: cilium-operator allocates per-node blocks out of one cluster-wide pool, rather than reusing a Node's own PodCIDR or reaching out to a cloud IPAM.
Q32 (🔬 eBPF). Why does an eBPF datapath outscale an iptables one as a cluster grows?
- A. iptables checks a packet against a linear chain of rules that grows with every Service and policy, while eBPF does a hash-map lookup keyed on identity or backend that stays roughly constant-time regardless of scale
- B. eBPF also uses a linear chain, just written in a faster language
- C. iptables uses hash maps and eBPF uses linear chains
- D. There's no performance difference; the appeal is purely operational
Check the answer
A. Linear-chain-versus-hash-map is the whole story: one gets slower with every rule and Service added, the other doesn't.
Q33 (🐢 Network Policy). A cluster has one team's broad egressDeny policy and another team's narrower allow rule targeting the same traffic. Which one wins?
- A. Allow rules always win over deny rules, cluster-wide
- B. Deny rules take precedence over every allow rule anywhere in the cluster — a broad
egressDenyoverrides other teams' allows rather than setting a floor beneath them - C. Whichever rule was created first wins, regardless of allow or deny
- D. Allow and deny rules cannot coexist in the same cluster
Check the answer
B. Deny always wins over allow, cluster-wide — which is exactly why a platform-wide CiliumClusterwideNetworkPolicy baseline is such a powerful (and dangerous) lever.
Q34 (🐦 Service Mesh). Which of these is named as a service mesh use case in the CCA curriculum?
- A. East-west traffic encryption, per-hop observability, canary/blue-green traffic splitting at L7, and multi-cluster routing once Cluster Mesh is in the picture
- B. Compiling eBPF programs at build time
- C. Replacing
cilium-operatorwith a mesh-only controller - D. Encrypting only north-south ingress traffic, never east-west
Check the answer
A. These four — east-west encryption, per-hop observability, L7 traffic splitting, and multi-cluster routing — are the named use cases, not a build-time or controller-replacement concern.
Q35 (🐿️ Cluster Mesh). What does the service.cilium.io/affinity: "local" annotation do on a global Service?
- A. Forces all traffic to a remote cluster only
- B. Prefers local backends, and only fails over to another meshed cluster if none are ready locally
- C. Disables Cluster Mesh entirely for that Service
- D. Sets the Service's IPAM mode to
eni
Check the answer
B. affinity: "local" is the "prefer nearby, fail over if needed" behavior, layered on top of global: "true"'s endpoint merging.
Q36 (🦉 Architecture). What's the difference between tunnel and native routing modes?
- A.
tunnelencapsulates packets in VXLAN or Geneve, working anywhere at a small MTU cost;nativeskips encapsulation entirely and relies on the underlay already knowing how to route your PodCIDRs - B.
tunnelis only for Cluster Mesh;nativeis only for single-cluster setups - C. Both modes are identical; the name is purely cosmetic
- D.
nativemode requires eBPF to be disabled
Check the answer
A. Tunnel trades a small MTU cost for working everywhere; native trades that portability for skipping encapsulation, provided the underlay already routes your PodCIDRs.
Q37 (🐘 Network Observability). Which command shows every dropped flow live — arguably the single most useful command during a networking incident?
- A.
cilium sysdump - B.
hubble observe --verdict DROPPED -f - C.
cilium connectivity test - D.
hubble status
Check the answer
B. A live, filtered drop stream turns "the platform is broken" into a named policy and a named rule in seconds.
Q38 (🐢 Network Policy). Which statement correctly describes how Cilium relates to a plain Kubernetes NetworkPolicy?
- A. Cilium ignores standard Kubernetes
NetworkPolicyobjects entirely - B. Cilium enforces a plain Kubernetes
NetworkPolicyfaithfully, then adds what that spec can't express — L7 rules,toFQDNshostname egress, entity selectors, explicit deny rules, and cluster-scoped policy - C. Kubernetes
NetworkPolicyobjects must be converted toCiliumNetworkPolicyby hand before they take effect - D. Cilium only supports
NetworkPolicyobjects when running intunnelmode
Check the answer
B. Cilium is a strict superset here — the standard spec keeps working, and CiliumNetworkPolicy layers on everything it can't express.
Q39 (🦫 Installation and Configuration). What does cilium sysdump produce?
- A. A live traffic replay for load testing
- B. One archive bundling everything support will ask for — the standard first step when escalating a Cilium issue
- C. A Helm values file pre-filled with the current configuration
- D. A new
CiliumNetworkPolicyscaffold
Check the answer
B. One command, one archive, everything support needs — recognize the verb rather than memorizing its flags.
Q40 (🐦 Service Mesh). Which two options does Cilium offer for transparent node-to-node traffic encryption, and how do they differ?
- A. WireGuard (simple, fast, a good default) and IPsec (older, more configuration knobs, sometimes required for FIPS compliance)
- B. TLS and mTLS, both requiring a sidecar
- C. Only IPsec is supported; WireGuard belongs to a different mesh entirely
- D. Only WireGuard is supported; there is no alternative
Check the answer
A. Both are configuration changes, not application changes — WireGuard as the simple default, IPsec when compliance requirements demand it.
Q41 (🦉 Architecture). Which two sentences carry most of the CCA architecture domain, according to how the curriculum's substance actually breaks down?
- A. eBPF replaces per-packet rule-chain traversal with kernel hash-map lookups, and Cilium enforces policy on label-derived identities, not IP addresses
- B. Cilium requires a service mesh to function at all, and BGP is mandatory for every install
- C. Hubble replaces
cilium-agent, andcilium-operatorreplaces the Kubernetes API server - D. IPAM is optional, and routing mode has no effect on performance
Check the answer
A. Nearly every domain on the blueprint is a consequence of one of these two sentences — worth having memorized word for word, not just recognized.
Q42 (🐿️ Cluster Mesh). Which commands enable Cluster Mesh on one cluster's context, connect it to a peer, and then confirm the mesh is healthy?
- A.
cilium install,cilium status,cilium sysdump - B.
cilium clustermesh enable,cilium clustermesh connect,cilium clustermesh status - C.
hubble observe,hubble status,hubble ui - D.
cilium config view,cilium config set,cilium connectivity test
Check the answer
B. Enable, connect, status — the three clustermesh subcommands map directly onto set up, join, and verify.
Q43 (🔬 eBPF). What does Cilium's socket-level load balancing do, and which feature enables it?
- A. It rewrites a Service's virtual IP to a real pod IP right at the socket, before a packet is even built — enabled by
kubeProxyReplacement, something a chain-of-rules model has no equivalent of - B. It only works after a packet has already left the node
- C. It requires
kube-proxyto be running alongside Cilium - D. It's a Cluster Mesh-only feature with no relevance to a single cluster
Check the answer
A. Rewriting at the socket, before a packet even exists, is the step a linear rule chain simply has no equivalent of.
Q44 (🐘 Network Observability). To gain L7 visibility without narrowing what traffic is allowed, what's the recommended technique?
- A. Disable enforcement entirely with enforcement mode
never - B. Write L7 rules that match everything —
http: [{}],dns: [{ matchPattern: "*" }]— so traffic keeps flowing while Hubble starts reporting methods, paths and status codes on top of it - C. Delete the policy and rely on Kubernetes
NetworkPolicyinstead - D. Enable IPsec, which automatically turns on L7 visibility
Check the answer
B. A wildcard-matching L7 rule buys visibility without changing what's actually allowed to flow — the standard move before tightening anything.
Q45 (🌐 BGP and External Networking). How do an egress gateway and the BGP control plane divide the "external networking" job between them?
- A. Both solve the exact same problem in different words
- B. An egress gateway gives outbound pod traffic a stable, allowlistable source address; the BGP control plane advertises routes for PodCIDRs and LoadBalancer VIPs to real routers so inbound traffic is properly routed — one is about traffic leaving, the other about traffic and routes arriving
- C. The egress gateway handles inbound traffic; BGP handles outbound traffic
- D. Neither is relevant unless Cluster Mesh is enabled
Check the answer
B. Outbound identity versus inbound routing is the clean split — the domain's two competencies, egress requirements and external connectivity, map directly onto these two mechanisms.
Score yourself
☺ Like you're 10: Count your correct answers out of 45, compare against the 75% target, then look at which topic cost you the most points — that second part is the useful part.
The Linux Foundation's general Multiple Choice Exam FAQ requires "a score of 75% or above" on LF multiple-choice exams, and CCA is one — so treat 34 of 45 (75.6%) as a reasonable target to clear comfortably, not as a guaranteed pass/fail line on the real exam, which uses its own question bank and its own count. Verify current pass-mark guidance on the official Linux Foundation CCA page before you rely on any number here.
| Domain | Questions in this paper | Your score | If under two-thirds, go here |
|---|---|---|---|
| 🦉 Architecture (20%) | Q1, 5, 11, 17, 21, 26, 31, 36, 41 | /9 | The Architecture section of the blueprint |
| 🐢 Network Policy (18%) | Q2, 7, 12, 18, 23, 27, 33, 38 | /8 | The Network Policy section of the blueprint |
| 🐦 Service Mesh (16%) | Q3, 9, 16, 20, 24, 34, 40 | /7 | The Service Mesh section of the blueprint |
| 🐘 Network Observability (10%) | Q4, 15, 25, 37, 44 | /5 | The Network Observability section of the blueprint |
| 🦫 Installation and Configuration (10%) | Q10, 19, 28, 39 | /4 | The Installation and Configuration section of the blueprint |
| 🐿️ Cluster Mesh (10%) | Q6, 14, 22, 35, 42 | /5 | The Cluster Mesh section of the blueprint |
| 🔬 eBPF (10%) | Q8, 29, 32, 43 | /4 | The eBPF section of the blueprint |
| 🌐 BGP and External Networking (6%) | Q13, 30, 45 | /3 | The BGP section of the blueprint |
| Total | 45 questions | /45 | ~75% (34/45) as a rough target |
A 34/45 built from eight solid domains and a 34/45 built from seven near-perfect domains plus a near-zero on one are very different results — the second is one unlucky question draw away from failing the real exam, even though both score the same total here. Always do the per-domain arithmetic, not just the headline number.
Beyond the domain breakdown, sort your misses into two piles, because they mean different things. A question you got wrong because you genuinely didn't know the component or the field is a real content gap — reread the linked blueprint section and redo the exact question cold in a couple of days. A question you got wrong despite roughly knowing the material — you second-guessed yourself, confused two similarly-named things like service.cilium.io/global and service.cilium.io/affinity, or ran out of time and guessed under pressure — is a speed or confidence problem, not a knowledge gap, and the fix is more untimed reps in the practice bank, not rereading content you already have.
Remy: Thirty-eight out of forty-five! Identities, IPAM modes, Gateway API roles — done, done, done, next!
Timmy: Which domain hid the other seven misses, Remy? Thirty-eight sounds great until one domain swallowed most of them.
Remy: ...Cluster Mesh, mostly. I keep mixing up which annotation merges endpoints across clusters and which one just prefers the local ones.
Pip: Global merges the crowd. Local affinity picks who answers first, and only reaches abroad if nobody local can. Say that sentence out loud until it's automatic, not just recognizable in a multiple-choice list.
Gizmo: Easy fix — just mark every Service global, with affinity local, everywhere, always. No annotations to remember, no wrong answers possible! 😈
Timmy: Gizmo, that's "share everything with everyone and hope" wearing an annotation. A Service goes global because two clusters genuinely need it — not because copy-paste was faster than reading the field names.
Professor Owl: It's still an architecture question underneath, Remy — cilium-operator carves the pools per cluster, clustermesh-apiserver exposes them to peers. Reread that one diagram slowly before you call CCA done.
1. Why does this paper assign questions to each domain in the same proportion as the real CCA weights, rather than spreading them evenly across eight piles? 2. What's the safe assumption about guessing penalties on a Linux Foundation multiple-choice exam, and what strategy follows from it? 3. Why is the 45-question, 3-block shape of this paper this course's own construction rather than an official CCA format? 4. You score 34/45 overall but 1/5 on one specific domain — why is that more actionable than a flat 75% average would suggest? 5. Name the two piles a wrong answer can fall into during review, and why they call for different fixes. 6. Because Set 2 is unseen relative to Set 1, what does a strong score here prove that a repeat sitting of Set 1 wouldn't?
Check your answers
- Because that's how the CNCF actually weights the real CCA blueprint — 20% Architecture, 18% Network Policy, 16% Service Mesh, 10% each for Observability, Installation and Configuration, Cluster Mesh, and eBPF, and 6% BGP — so practicing, and scoring, in that same proportion is the closest a study paper can get to the real thing.
- Linux Foundation multiple-choice exams don't publish an extra penalty for a wrong guess beyond simply not earning the point, so the safe strategy is to never leave a question blank — eliminate what you can, then commit to your best remaining guess.
- Because the CNCF doesn't publish CCA's real question count at all — this paper's 45 questions across three 30-minute blocks were chosen because they split cleanly into whole numbers of questions per domain and fit a realistic 90-minute sitting, not because that's a leaked or official format.
- Because a flat 75% hides where the gap actually is. A domain score of 1/5 is a concentrated, specific content gap fixable by rereading one section, while an evenly-spread 75% wouldn't tell you where to focus at all — the per-domain breakdown converts an average into a diagnosis.
- A genuine content gap — you didn't know the fact at all — calls for rereading the linked blueprint section and redoing the exact question cold later. A speed or confidence problem — you roughly knew it but second-guessed yourself or ran out of time — calls for more untimed practice-bank drilling, not rereading content you already have.
- It proves the knowledge generalizes to phrasing and scenarios you haven't already seen the answer to — a strong score on a repeat of Set 1 could just mean you remember the specific questions, not that you'd recognize the same fact asked a different way on the real exam.
That's the full sitting. Reset the timer, close every tab except this one, and let the 45 questions above show you exactly which of the eight domains is still soft — then go fix precisely that, and nothing else, against the blueprint's Cluster Mesh section or wherever your own weak domain turned out to be, before you call CCA prep done. There's no Set 3 waiting to catch it for you.