Certifications · CCA · Practice Questions

CCA Practice Questions

This page is the CCA question bank — twenty-four single-best-answer questions, split across all eight official domains in roughly the same proportion the CNCF's blueprint weights them, each with every option worked through in the answer key rather than a bare correct letter. It sits between two other pages on this ladder rung: read CCA — the exam first if you haven't, since the questions below assume you already know what a security identity, an enforcement mode, a sidecarless mesh and Cluster Mesh's PodCIDR rules actually are. Once this bank stops surprising you, move on to the timed, full-length CCA Mock Exam · Set 1 and Set 2. Every question here is original content written against the published CCA competencies — none of it is drawn from, or claims to reproduce, the real proctored exam.

How this bank works

☺ Like you're 10: Cover the four answers with your hand, guess first, then look — and if a question fools you twice, that's the one to actually go study.

Every question below has a stem (the scenario or the exact thing being asked), four options, and exactly one key. The other three are not padding — each is built from a real misconception someone genuinely holds: a fact from the wrong CCA domain, a rule stated one qualifier too strongly, a mechanism that sounds plausible but doesn't exist in Cilium, or a true statement that simply doesn't answer the question that was asked. That is how CNCF-style multiple-choice items are actually constructed, and it is why "I recognised a true statement" is not the same skill as "I found the one that answers this stem" — see CCA — the exam for how the real exam is built the same way, and the Platform Engineering track's parallel CCA deep dive if you want the full walkthrough with worked YAML behind every domain.

The eight piles, sized like the blueprint

Twenty-four questions split across eight domains can't hit 20/18/16/10/10/10/10/6 exactly, but they land close, and in the same rank order — Architecture, Network Policy and Service Mesh are still the three piles worth well over half the bank between them:

Architecture — questions 1–5 (20% of the blueprint)

☺ Like you're 10: This pile is about the building itself — which robot does which job, and how apartments get their addresses.

1. What is Cilium's fundamental role in a Kubernetes cluster?

   1. A vendor-neutral admission controller that validates Kubernetes manifests before they're stored
   2. A Container Network Interface (CNI) plugin that provides networking, identity-based security enforcement and observability, using eBPF as its datapath
   3. A GitOps controller that continuously reconciles application manifests from Git
   4. A service-mesh sidecar proxy that must be injected into every pod before traffic can flow
   Show answer & explanation

   Answer: B. Cilium is a CNI — it owns pod networking, and layers identity-based policy and Hubble observability on top of the same eBPF datapath. A describes an admission controller, a different Kubernetes extension point entirely. C describes a project like Argo CD, not a CNI. D is specifically wrong for Cilium's own mesh, which is deliberately sidecarless — no per-pod injection webhook required.

2. Which pairing correctly describes Cilium's two core components?

   1. cilium-agent runs once per cluster and allocates IP pools; cilium-operator runs on every node and programs eBPF maps
   2. cilium-agent runs as a DaemonSet on every node, computing identities and programming eBPF maps for that node's endpoints; cilium-operator runs once per cluster, handling cluster-wide work like cluster-pool IPAM allocation and garbage-collecting stale identity and endpoint objects
   3. cilium-agent and cilium-operator are two names for the same binary, started with different command-line flags
   4. cilium-operator has been deprecated in favor of running all cluster-wide logic inside every cilium-agent
   Show answer & explanation

   Answer: B. The agent is per-node, watching the API and programming that node's own eBPF state; the operator is per-cluster, doing exactly the jobs that don't make sense to run redundantly on every node. A has the scopes reversed. C and D are both fabrications — they're separate binaries with separate, complementary jobs, and neither has absorbed the other.

3. A bare-metal cluster has no cloud ENI integration and wants the Cilium operator, not each Node object individually, to own carving up Pod CIDR blocks per node. Which IPAM mode is being described?

   1. kubernetes mode, which reads each Node's own spec.podCIDR
   2. cluster-pool mode — the default — where the operator allocates per-node blocks from a configured cluster-wide pool
   3. eni mode, which assigns pods real AWS VPC addresses
   4. azure mode, which assigns pods real Azure VNET addresses
   Show answer & explanation

   Answer: B. cluster-pool is exactly this: the operator, not Kubernetes' own per-Node field, carves and hands out the per-node blocks, and it's Cilium's default. kubernetes mode (A) does the opposite — it defers to each Node's podCIDR instead of operator-managed allocation. eni and azure (C, D) are both real modes, but they hand pods real cloud-VPC addresses — a different problem than the one this stem describes.

4. A platform team's underlay network already knows how to route the cluster's Pod CIDRs without any encapsulation. Which Cilium routing mode avoids the extra MTU overhead of VXLAN or Geneve encapsulation?

   1. tunnel mode
   2. native routing mode
   3. cluster-pool mode
   4. "overlay" mode — Cilium's only supported routing option
   Show answer & explanation

   Answer: B. native routing hands packets straight to the underlay, which already knows how to route the Pod CIDRs — no encapsulation, no MTU tax. tunnel mode (A) is the encapsulating option this stem is asking you to avoid. cluster-pool (C) is an IPAM mode, not a routing mode — a category mix-up, not an alternative answer. D is a fabrication: tunnel routing is also fully supported, so "only option" is false on its face.

5. Why does an eBPF-based datapath scale better than a traditional iptables datapath as the number of Kubernetes Services in a cluster grows?

   1. eBPF replaces the linear, sequentially-walked rule chain iptables builds with kernel hash-map lookups that stay close to constant-time regardless of Service count
   2. eBPF programs are written in a faster general-purpose language than the C code iptables is implemented in
   3. eBPF automatically disables Services above a configurable count, keeping the chain short
   4. eBPF requires a kernel module to be recompiled every time a new Service is added
   Show answer & explanation

   Answer: A. This is the datapath-model competency in one sentence: hash-map lookups replace a chain that grows — and gets slower to walk — with every Service, which is the whole reason kubeProxyReplacement exists. B misattributes the speedup to "language," not architecture — both are ultimately compiled/JIT'd kernel code. C and D are both fabrications; nothing disables Services, and eBPF programs are loaded and JIT-compiled at runtime, with no kernel module recompilation involved.

Network Policy — questions 6–9 (18% of the blueprint)

☺ Like you're 10: This pile is about the doors — how they decide who's allowed through, based on who you are, not which room you're standing in.

6. What does Cilium derive a pod's security identity from, and why does that matter for how policy behaves over time?

   1. The pod's IP address, recalculated fresh on every single packet
   2. The pod's labels — every pod sharing the relevant labels shares one identity, so policy written against that identity keeps meaning the same thing even after the pod is rescheduled onto a new IP
   3. The container image's digest, so identical images always share one identity regardless of labels
   4. The node's hostname, so every pod on a given node shares that node's identity
   Show answer & explanation

   Answer: B. Identity-based security is the CCA's central idea: labels, not IPs, are the unit policy is written against, so autoscaling and rescheduling never invalidate a rule. A describes exactly the IP-centric model Cilium replaces. C and D each swap in a plausible-sounding but wrong source — image digest and node hostname are not how Cilium computes identity.

7. A pod has never been selected by any CiliumNetworkPolicy, and the cluster is running Cilium's default policy enforcement mode. What is that pod's traffic posture, in both directions?

   1. All traffic is denied by default until an explicit allow rule is written
   2. All traffic is allowed — nothing is enforced for an endpoint until some policy selects it, and only then does that direction become default-deny
   3. Ingress is allowed and egress is denied, unconditionally, in every mode
   4. It inherits whichever enforcement mode was set on the oldest policy object in its namespace
   Show answer & explanation

   Answer: B. This is the classic exam trap: in default mode, selection is what flips a direction to default-deny — an endpoint no policy has ever touched allows everything. A describes always mode instead. C invents an asymmetric rule that doesn't exist — ingress and egress are independently gated, not fixed to one direction. D is a fabrication; enforcement mode isn't inherited from "the oldest policy."

8. This policy is the only one deployed for the checkout pod, and the cluster is in default enforcement mode:

   apiVersion: cilium.io/v2
   kind: CiliumNetworkPolicy
   metadata:
     name: checkout-egress
     namespace: prod
   spec:
     endpointSelector:
       matchLabels:
         app: checkout
     egress:
       - toFQDNs:
           - matchName: "api.stripe.com"
         toPorts:
           - ports:
               - port: "443"
                 protocol: TCP

   Deployed alone, this policy causes checkout's egress to api.stripe.com to fail. Why?

   1. toFQDNs is not a valid field in a CiliumNetworkPolicy
   2. The policy selects the pod, which turns its egress into default-deny — but there is no separate rule permitting DNS lookups on port 53, so the hostname can never actually be resolved in the first place
   3. matchName only accepts wildcard patterns, never an exact hostname like this one
   4. toFQDNs requires Cluster Mesh to be enabled before it will resolve anything
   Show answer & explanation

   Answer: B. This is the single most common Cilium outage pattern: selecting a pod for egress policy makes that direction default-deny, and a toFQDNs rule is useless if DNS itself (typically to kube-dns on port 53) isn't separately permitted — the hostname never resolves, so the FQDN rule never matches anything. A and C are both fabrications about the field itself. D invents a Cluster Mesh dependency that doesn't exist — toFQDNs works standalone.

9. Which of the following is something a CiliumNetworkPolicy can express that a standard Kubernetes NetworkPolicy cannot?

   1. L7-aware rules — matching specific HTTP methods and paths, or DNS names via toFQDNs — plus explicit ingressDeny/egressDeny rules
   2. Matching on L3/L4 alone — source and destination selectors plus ports, exactly like a standard NetworkPolicy
   3. Restricting a workload to ingress-only enforcement, since Cilium cannot enforce egress at all
   4. Replacing Kubernetes Service objects, since CiliumNetworkPolicy also performs load balancing
   Show answer & explanation

   Answer: A. Cilium enforces plain NetworkPolicy faithfully and layers extra expressiveness on top — L7 HTTP/DNS/Kafka rules, toFQDNs egress by hostname, entity selectors, and explicit deny rules that override allows cluster-wide. B describes the ceiling of the standard resource, not the extra capability the question asks for. C is false — Cilium enforces egress just as readily as ingress. D confuses policy with Service load-balancing, an unrelated Kubernetes primitive Cilium doesn't replace.

Service Mesh — questions 10–13 (16% of the blueprint)

☺ Like you're 10: This pile is about routing letters through the building without giving every single room its own extra mail clerk.

10. Cilium's service mesh is described as "sidecarless." What underlies that design, and what's the trade-off?

    1. Every pod still runs a sidecar container — it's just written in eBPF instead of a userspace proxy
    2. The datapath already inspects every packet at the node level, so L4 mesh functions need no per-pod proxy at all; L7 parsing runs through an Envoy proxy that executes once per node rather than once per pod, at the cost of a thinner L7 feature set and a proxy whose blast radius is the node, not the pod
    3. "Sidecarless" means mTLS in transit is not supported under Cilium's mesh
    4. "Sidecarless" refers to removing kube-proxy, and is unrelated to the mesh's proxy model
    Show answer & explanation

    Answer: B. Because the eBPF datapath already sees every packet, L4 mesh work is free; only L7 rules route traffic through Envoy, and that Envoy runs per node — no injection webhook, no per-pod resource tax, but a node-scoped rather than pod-scoped proxy blast radius. A contradicts "sidecarless" outright. C is false — Cilium supports encryption in transit via WireGuard or IPsec regardless of the mesh's sidecar model. D confuses two separate "no extra thing per pod/node" features that happen to share a reputation, not a mechanism.

11. Per the CCA curriculum, which of the following is a genuine benefit of the Gateway API over the classic Ingress resource?

    1. Gateway API requires no CRDs to be installed, unlike Ingress
    2. Gateway API is role-oriented — separate GatewayClass, Gateway and HTTPRoute objects with distinct RBAC for infrastructure providers, cluster operators and application developers — and expresses routing like header, method and weighted matching directly in the spec instead of through vendor-specific annotations
    3. Gateway API only works when Cilium is the CNI, and has no other implementations
    4. Gateway API replaces the need for writing any CiliumNetworkPolicy at all
    Show answer & explanation

    Answer: B. This is exactly the "benefits of Gateway API over Ingress" competency: role separation with matching RBAC, and expressive routing captured in the API instead of scattered across implementation-specific annotations. A is backwards — Gateway API requires its CRDs installed first. C is false; Gateway API is a portable, multi-implementation specification, Cilium being one of several. D confuses two unrelated layers — routing north-south HTTP traffic and enforcing network policy are separate concerns.

12. A team wants to encrypt node-to-node traffic across a Cilium cluster without changing any application code. Which two options does Cilium support for this, configured as a cluster-wide setting?

    1. TLS terminated inside a sidecar in every pod, or mTLS via a separate SPIFFE deployment
    2. WireGuard or IPsec
    3. IPsec only — Cilium has never supported WireGuard
    4. A per-Service annotation that terminates TLS at an external LoadBalancer
    Show answer & explanation

    Answer: B. Both are cluster-level, transparent, node-to-node encryption options — WireGuard for simplicity and speed, IPsec where its broader configurability or FIPS relevance matters — and neither touches application code. A describes a sidecar-based approach the sidecarless mesh specifically avoids. C is a fabrication — WireGuard is a first-class, supported option. D describes edge/ingress TLS termination, a different problem than encrypting traffic between nodes.

13. To route north-south HTTP traffic to a Service through Cilium's Gateway API implementation, which of the following is required?

    1. A GatewayClass named cilium and the Gateway API CRDs installed in the cluster, referenced by a Gateway and one or more HTTPRoute objects
    2. Nothing beyond a standard Kubernetes Ingress object — Cilium treats Gateway API objects as aliases for Ingress
    3. An active Cluster Mesh connection to at least one peer cluster
    4. An Istio VirtualService, since Cilium delegates all L7 routing decisions to Istio
    Show answer & explanation

    Answer: A. Cilium ships its own Gateway API implementation — a cilium-named GatewayClass, the upstream CRDs, and standard Gateway/HTTPRoute objects. B invents an alias relationship that doesn't exist; Ingress and Gateway API are separate, parallel routing mechanisms Cilium implements independently. C ties an unrelated feature (multi-cluster connectivity) to a single-cluster routing question. D is false — Cilium's Gateway API support has no dependency on Istio.

Network Observability — questions 14–16 (10% of the blueprint)

☺ Like you're 10: This pile is about the security cameras — who's watching every hallway, and how you actually pull up the footage.

14. Which Hubble component aggregates flow data from every node into a single cluster-wide API that the hubble CLI and Hubble UI query?

    1. hubble-relay
    2. cilium-operator
    3. The per-node Envoy proxy
    4. clustermesh-apiserver
    Show answer & explanation

    Answer: A. Each agent already collects its own node's flows; hubble-relay is the piece that fans out to every agent and aggregates the result into one cluster-wide stream. cilium-operator (B) does cluster-scoped IPAM and garbage collection, not flow aggregation. The per-node Envoy (C) handles L7 parsing, not cross-node aggregation. clustermesh-apiserver (D) is Cluster Mesh's cross-cluster API, an entirely different domain.

15. A team wants Hubble to report HTTP methods and status codes for a pod's egress traffic, without narrowing what that pod is already allowed to reach. What do they actually have to do?

    1. Nothing — L7 visibility has been on by default for every flow since Cilium's first release
    2. Add a permissive L7 rule to a CiliumNetworkPolicy that matches everything — for example an empty http: [{}] block — so the flow is routed through the per-node Envoy proxy for parsing, while the rule still allows everything it already allowed
    3. Enable a long-standing pod annotation that has always been Cilium's supported way to turn on L7 visibility
    4. Install a dedicated sidecar container inside the pod purely for observability
    Show answer & explanation

    Answer: B. L7 visibility is not free — a flow is only parsed above L4 when a policy attaches L7 rules to it, which is what steers it through Envoy in the first place; writing the rule to match everything gets visibility without changing what's permitted. A is false — visibility above L4 requires an L7 rule to exist. C is a trap: an annotation-based form existed on older Cilium releases but was removed in Cilium 1.15, so it is not "always" the supported mechanism. D contradicts the sidecarless design this course keeps coming back to.

16. Which hubble CLI invocation shows only flows that were denied by policy, streamed live as they happen?

    1. hubble observe --verdict DROPPED -f
    2. hubble status --wait
    3. cilium connectivity test --verdict DROPPED
    4. hubble observe --type l7 --http-status 200
    Show answer & explanation

    Answer: A. --verdict DROPPED filters to denied flows and -f follows the stream live — exactly the incident-response one-liner the curriculum wants you fluent in. hubble status --wait (B) reports relay/agent health, not flows. cilium connectivity test (C) doesn't take a --verdict flag at all — it's a different tool for a different job. D filters to successful L7 HTTP flows, the opposite of what the stem asks for.

Installation and Configuration — questions 17–18 (10% of the blueprint)

☺ Like you're 10: This pile is about turning the building's power on, checking every light works, and knowing which switch is the real one.

17. After running cilium install --version 1.15.6, which single command runs a comprehensive suite of pod-to-pod, pod-to-service, DNS, egress and policy connectivity checks?

    1. cilium status --wait
    2. cilium connectivity test
    3. cilium sysdump
    4. cilium config view
    Show answer & explanation

    Answer: B. cilium connectivity test is purpose-built to exercise exactly that list of paths end to end. cilium status --wait (A) reports whether agents, the operator and Hubble have converged — health, not connectivity. cilium sysdump (C) collects a support archive; it runs no checks itself. cilium config view (D) just reads back the current configuration.

18. A cluster's Cilium install is managed by GitOps — an Argo CD Application syncing a Helm values file. Why is running cilium config set directly against the live cluster a poor way to make a change that should persist?

    1. The command doesn't exist — Cilium has no live config-editing CLI verb
    2. It edits the live cilium-config ConfigMap directly; the GitOps controller will either flag it as drift or simply revert it on the next sync, since the values file in Git — not the live ConfigMap — is the actual source of truth
    3. cilium config set only ever affects the Hubble UI, never the agent itself
    4. It permanently and irreversibly disables kube-proxy replacement cluster-wide
    Show answer & explanation

    Answer: B. This is a GitOps-versus-imperative-CLI collision that shows up across every project in this course, not just Cilium: a live edit made outside Git is either drift to be flagged or a change to be quietly reverted, depending on the reconciliation settings — the values file is what should actually change. A is false; the command is real and does exactly what it says. C understates its scope — it edits agent configuration broadly, not just Hubble UI behavior. D overstates the blast radius and invents irreversibility that isn't real.

Cluster Mesh — questions 19–20 (10% of the blueprint)

☺ Like you're 10: This pile is about joining two buildings with one shared hallway, and making sure their room numbers never collide.

19. Two clusters being joined with Cluster Mesh turn out to have overlapping Pod CIDRs. What happens?

    1. Cilium automatically re-numbers one cluster's Pod CIDR range to resolve the conflict
    2. Cluster Mesh requires strictly non-overlapping Pod CIDRs between meshed clusters as a hard prerequisite — the overlap has to be fixed, typically by re-provisioning one cluster's networking, before meshing will work correctly
    3. Overlapping Pod CIDRs are fine as long as the two clusters' names differ
    4. Cluster Mesh silently falls back to enforcing policy only, dropping cross-cluster connectivity but leaving policy intact
    Show answer & explanation

    Answer: B. A globally unique cluster name, a globally unique cluster ID, and strictly non-overlapping Pod CIDRs are Cluster Mesh's three hard prerequisites — this is exam-favourite territory precisely because it's a real, common planning mistake. A invents an auto-remediation feature that doesn't exist. C is false; distinct names don't fix an IP-space collision. D is a fabrication — there's no such graceful partial-degradation mode.

20. Which annotation, applied to same-named, same-namespace Services in each meshed cluster, merges their endpoints into one globally load-balanced Service?

    1. service.cilium.io/global: "true"
    2. service.kubernetes.io/topology-aware-hints: "auto"
    3. cilium.io/clustermesh: "enabled"
    4. service.beta.kubernetes.io/aws-load-balancer-type: "external"
    Show answer & explanation

    Answer: A. That single annotation, matched on Services with the same name and namespace across meshed clusters, is what promotes a Service to global — merging endpoints and enabling cross-cluster failover. B is a real, but unrelated, Kubernetes topology-hints annotation. C is a plausible-sounding fabrication — no such annotation exists. D is an AWS cloud-controller annotation, unrelated to Cluster Mesh entirely.

eBPF — questions 21–22 (10% of the blueprint)

☺ Like you're 10: This pile is about the tiny, carefully-checked programs living inside the kernel itself — and why they're safe to trust.

21. What ensures an eBPF program cannot crash the kernel or run an unbounded loop, before it is ever attached to a hook?

    1. The program is interpreted line by line at runtime and is never compiled ahead of time
    2. A kernel verifier statically checks the program for safety — bounded loops, valid memory access, and so on — before it is JIT-compiled to native code and attached
    3. Cilium's userspace agent test-runs the program in a staging pod first, and only attaches it if that succeeds
    4. eBPF programs execute inside a full container runtime, isolated from the kernel like any other workload
    Show answer & explanation

    Answer: B. The verifier is the safety mechanism the "eBPF Key Benefits" competency is pointing at — static analysis proves safety before the JIT compiles it to native code, with no kernel module and no reboot required. A misdescribes the pipeline; eBPF programs are compiled, not interpreted, once loaded. C invents a staging-pod test step that doesn't exist. D is backwards — the entire point of eBPF is running attached, verified code inside the kernel, not isolated in a container alongside it.

22. What does Cilium's kube-proxy replacement mode actually do?

    1. It removes Kubernetes Service objects from the API entirely
    2. It uses eBPF — including, for some traffic, socket-layer load balancing — to implement Service load-balancing directly, bypassing the need for kube-proxy's iptables or IPVS rule chains
    3. It replaces kube-proxy with a second, faster copy of iptables running in userspace
    4. It disables Service load-balancing altogether and requires every Service to front an external LoadBalancer
    Show answer & explanation

    Answer: B. kubeProxyReplacement is the eBPF datapath doing kube-proxy's job — including the shortcut of resolving some traffic straight at the socket layer, skipping the network stack entirely. A confuses the Service object (still fully present in the API) with the implementation that load-balances it. C just relocates iptables rather than replacing its approach, missing the point of the eBPF answer. D is a fabrication with no basis in how the feature works.

BGP and External Networking — questions 23–24 (6% of the blueprint)

☺ Like you're 10: This pile is about the building's front door to the rest of the world — how mail gets a consistent return address, and how the street outside learns the building's own address.

23. A partner's firewall will only allowlist one stable external IP address, but the pods that need to reach it are horizontally scaled and rescheduled constantly, each normally masqueraded behind its own node's IP on the way out. Which Cilium feature solves this?

    1. Cluster Mesh, joining the cluster to a second cluster that happens to have a static IP
    2. An egress gateway, which routes selected pods' external traffic out through designated nodes so it always leaves the cluster from a known, stable address
    3. A CiliumNetworkPolicy toFQDNs rule pointed at the partner's hostname
    4. BGP peering that advertises each individual pod's own /32 address directly to the partner's router
    Show answer & explanation

    Answer: B. An egress gateway is built exactly for this: it gives a group of pods a stable, allowlistable source identity for external traffic regardless of where those pods are actually scheduled. Cluster Mesh (A) solves cross-cluster connectivity, not a stable-egress-IP problem. A toFQDNs rule (C) controls whether the traffic is allowed, not what source IP it leaves with. Advertising individual pod addresses via BGP (D) is neither how Cilium's BGP feature is used nor something most partner firewalls would accept.

24. An on-premises cluster has no cloud load balancer available, and wants LoadBalancer-type Services to receive real, externally routable addresses by peering directly with the data center's physical routers. Which Cilium capability is built for this?

    1. The Cilium BGP control plane, which peers with physical routers and advertises Pod CIDRs and LoadBalancer VIPs
    2. Cluster Mesh, since it also happens to handle traffic leaving the cluster
    3. Hubble, using a flow-export feature that notifies routers of new Services
    4. IPsec encryption mode, which advertises new routes as a side effect of key exchange
    Show answer & explanation

    Answer: A. This is the on-prem answer to a problem cloud providers solve with a managed load balancer — Cilium's own BGP control plane peers with real routers and advertises the addresses that need to become routable, doing MetalLB's job as a built-in CNI feature. Cluster Mesh (B) is about connectivity between clusters, not to physical routers. Hubble (C) observes traffic; it doesn't participate in routing. IPsec (D) encrypts traffic and has no route-advertisement side effect at all.

Turning a wrong answer into a fact

☺ Like you're 10: The score isn't the point. What matters is why you got one wrong — because "I never knew that" and "I knew it but misread the question" need completely different fixes.

Finishing the bank and noting a percentage teaches you almost nothing on its own. When you miss one, decide honestly which of two things happened. If you genuinely didn't know the fact, that's a content gap — go reread the matching section of CCA — the exam, and don't move on until you can restate it in your own words. If you knew the material but picked wrong anyway, that's almost always a misread stem or a distractor that got you on speed rather than knowledge — reread the exact wording of the question you missed before you touch the next one. Either way, questions you miss twice on a later pass are the ones actually worth writing down.

If you want a rough, self-graded pass/fail signal: the Linux Foundation's published cut score for its multiple-choice exams, CCA included, is 75%. Scoring at or above that here, cold, across all 24, is a reasonable — though entirely unofficial — readiness signal before you book the timed mock exam.

Check your answers

1. 24 questions — 5 Architecture, 4 Network Policy, 4 Service Mesh, 3 Network Observability, 2 Installation and Configuration, 2 Cluster Mesh, 2 eBPF, 2 BGP and External Networking, tracking the blueprint's 20/18/16/10/10/10/10/6 split in rank order if not in exact percentage.
2. Architecture — because it's the single largest domain on the real CCA blueprint at 20%, ahead of Network Policy's 18%.
3. From the pod's labels. Pods sharing the relevant labels share one identity, so policy keeps meaning the same thing when pods are rescheduled onto new IPs — the datapath never has to chase IP churn.
4. default (allows everything until a policy selects the endpoint, at which point that direction becomes default-deny), always (default-deny everywhere from the start), never (not enforced). In default mode, an endpoint no policy has ever selected allows all traffic.
5. False. Visibility (routing a flow through the per-node Envoy proxy so it can be parsed) and authorization (what the flow is actually permitted to do) are separate concerns — a permissive rule like http: [{}] gets you visibility without narrowing what's already allowed, but it still has to be paired with whatever the pod is genuinely allowed to reach, DNS included.
6. service.cilium.io/global: "true".
7. Reread the exact wording of the question you missed before moving on — most misses on material you actually know come from a misread stem or a distractor that won on speed, not from a real content gap, and you can only tell the difference by rereading immediately.