This guide is for entry-level platform and cloud engineers preparing for the Cilium Certified Associate (CCA). Start with architecture and eBPF, then connect those foundations to policy, routing, observability and deployment decisions. Each concept includes a worked example and a specific mistake to avoid. Basic familiarity with Kubernetes, TCP/IP, DNS and HTTP will help you follow the explanations.
Architecture and networking foundations
1. Cilium's role in the CNI lifecycle
Kubernetes relies on a Container Network Interface implementation to configure workload networking. Cilium integrates with this lifecycle to establish network connectivity and connect workloads to its datapath. Scheduling a Pod and making that Pod reachable are separate responsibilities: the scheduler chooses a node, while networking components establish the required interfaces, addresses and forwarding behavior.
Worked example: A Pod is assigned to node oak but cannot obtain network connectivity. Investigating CNI setup is more relevant than changing the scheduler's placement rules.
Mistake to avoid: Treating successful scheduling as proof that Pod networking succeeded.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
2. Control plane versus datapath
The control plane interprets desired state, such as endpoints, services and policies. The datapath applies forwarding and security decisions to traffic. This distinction helps explain why configuration can appear correct in an API while traffic still fails: the corresponding state must also reach the components that process packets.
Worked example: A new backend exists in Kubernetes, but a node still forwards to the old backend set. Compare the desired service state with that node's datapath state.
Mistake to avoid: Assuming an accepted API object proves every node has applied it.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
3. The node-local Cilium agent
The Cilium agent manages networking and security on its node. It observes relevant workload and cluster information and maintains local endpoint and datapath state. Because packet processing is distributed across nodes, a problem confined to one node calls for checking that node's agent and local configuration before assuming a cluster-wide failure.
Worked example: Requests succeed from Pods on cedar but fail from Pods on pine. Pine's agent health and endpoint state become the first focused checks.
Mistake to avoid: Using one healthy agent as evidence that all nodes are healthy.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
4. The Cilium operator's cluster-wide role
The Cilium operator handles responsibilities that benefit from a cluster-wide view, including resource management and cleanup. Its allocation responsibilities depend on the selected IPAM mode. It complements the node agents; it does not act as the forwarding hop through which ordinary workload packets must pass.
Worked example: Existing workloads communicate, but new address allocation is failing in an operator-managed allocation mode. Operator health is relevant even though established traffic still works.
Mistake to avoid: Expecting the operator to process every packet between Pods.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
5. Endpoints as managed workload attachments
A Cilium endpoint represents a managed network attachment, commonly associated with a Kubernetes Pod. Endpoint state connects workload metadata, addressing and security enforcement. A Pod containing several application containers generally shares its network namespace, so container count alone does not determine how many independent workload network attachments must be investigated.
Worked example: A Pod contains an API container and a helper container sharing one network namespace. Diagnose their shared Pod attachment before searching for separate container IPs.
Mistake to avoid: Equating each application container with an independently addressed Cilium endpoint.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
6. Pod addresses and service addresses
A Pod address identifies a workload network location. A Kubernetes Service supplies a stable access abstraction over eligible backends, often through a virtual address. The service address therefore need not be assigned to an application interface. Distinguishing these addresses helps separate backend reachability problems from service selection or translation problems.
Worked example: A client reaches backend 10.20.1.8 directly but fails through the service address. Inspect service backend selection and translation rather than assuming all routing is broken.
Mistake to avoid: Looking for the service's virtual address on a backend Pod interface.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
7. IPAM pools and usable capacity
IP address management allocates addresses from configured pools while preventing conflicting assignments. Capacity calculations must use the allocation rules of the chosen mode, including excluded addresses and existing allocations. A prefix describes an address space; it does not automatically tell you how many additional Pods the environment can support.
Worked example: A pool contains 64 addresses, with six excluded and five already allocated. Its remaining capacity is 64 minus 6 minus 5, or 53 addresses.
Mistake to avoid: Counting excluded or already allocated addresses as available capacity.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
8. Encapsulation and native routing
An encapsulated datapath carries workload packets inside an outer packet between nodes. Native routing forwards workload addresses through the underlying network without that overlay wrapper. The choice changes underlay requirements: native routing needs suitable routes to workload networks, while encapsulation needs reachability for the tunnel transport between nodes.
Worked example: The underlay knows node addresses but has no Pod-network routes. An overlay can provide cross-node transport if its tunnel traffic is permitted.
Mistake to avoid: Selecting native routing without checking how the underlay reaches Pod addresses.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
9. MTU and encapsulation overhead
The maximum transmission unit limits packet size on a link. Encapsulation consumes some of that space with outer headers, so the inner packet may require a smaller MTU. Oversized packets can cause fragmentation or failures when path-MTU signaling is unavailable. Actual overhead depends on the transport and enabled features.
Worked example: With a 1,500-byte underlay MTU and an assumed 50-byte encapsulation overhead, the calculated inner limit is 1,450 bytes. This assumption must match the deployed transport.
Mistake to avoid: Applying one memorized overhead value to every datapath configuration.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
10. Service selection and backend translation
Service handling combines identifying eligible backends with steering traffic to a selected backend. A service can exist while having no eligible endpoints, and a backend can exist while failing to match the service selector. Diagnose service membership before attributing every unsuccessful connection to the packet-forwarding mechanism.
Worked example: A service selects app=ledger, but all intended Pods carry app=ledger-api. The selector mismatch explains the empty backend set; correcting membership restores a usable destination.
Mistake to avoid: Assuming a service object always has at least one backend.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
11. Routing and source masquerading
Routing determines where a packet travels. Source masquerading changes the source address visible to the next network, commonly to make return traffic reach an address that external systems understand. These solve different problems: translation cannot compensate for a missing outbound route, and a valid route does not guarantee a valid return path.
Worked example: Traffic from Pod 10.8.1.12 leaves with source 192.0.2.14 after translation. The external destination replies to 192.0.2.14, and connection state maps that reply back.
Mistake to avoid: Treating address translation as a replacement for routing.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
12. DNS resolution and network reachability
DNS maps a name to an address; it does not establish a connection to that address. Service discovery therefore has separate resolution and connectivity stages. A successful DNS answer narrows the investigation, but routing, policy, service translation and application availability can still prevent the subsequent request from succeeding.
Worked example: catalog.shop resolves to a service address, but TCP connection attempts time out. Name resolution succeeded; the next checks concern the connection path and destination.
Mistake to avoid: Using successful DNS resolution as proof that the application is reachable.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
eBPF foundations
13. Event-driven execution at kernel hooks
eBPF programs execute when an event reaches a hook to which a program is attached. Networking hooks let programs inspect packet context and influence handling at particular points in the stack. The attachment point matters because it determines which traffic and metadata the program can see and which actions are available.
Worked example: A program attached to a receive-side networking hook examines incoming packets at that location. It does not automatically inspect unrelated filesystem events.
Mistake to avoid: Imagining one eBPF program continuously scans every activity in the kernel.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
14. The verifier and constrained execution
Before loading an eBPF program, the kernel verifier checks whether its behavior satisfies safety constraints, including permitted memory access and valid execution paths. Verification enables controlled extensibility inside the kernel. Passing verification establishes compliance with those execution constraints; it does not establish that the program implements the intended networking policy.
Worked example: A verifier accepts a program that performs valid accesses, but its rule logic selects the wrong destination. Functional testing is still needed to detect that error.
Mistake to avoid: Confusing verifier acceptance with proof of correct application behavior.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
15. Maps as shared datapath state
eBPF maps hold structured state that programs can read and, where permitted, update. User-space components can also manage map contents. This separates packet-processing logic from changing information such as backend membership or connection state. Diagnose both the executing program and the data it consults when behavior differs from expectations.
Worked example: A service map lists two backends. Removing a departed backend from the relevant state changes the available destinations without changing the service's public address.
Mistake to avoid: Assuming correct program logic makes stale map contents harmless.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
16. Packet layers determine available information
Packet handling can use network-layer addresses and transport-layer ports without interpreting application messages. HTTP methods and paths require application-layer understanding. This distinction explains why an address-and-port decision differs from an HTTP rule, and why encrypted application content cannot simply be inferred from an ordinary packet header.
Worked example: Two requests use the same destination IP and TCP port, but one requests /public and the other /admin. Port inspection alone cannot distinguish their paths.
Mistake to avoid: Expecting transport-layer metadata to reveal an encrypted HTTP request path.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
17. eBPF and iptables as implementation approaches
iptables expresses packet-handling behavior through rule chains, while eBPF provides programmable logic and map-based state at kernel hooks. These are different implementation approaches to networking functions. eBPF can support efficient lookups and integrated visibility, but performance depends on the workload and configuration; the implementation choice does not redefine Kubernetes Service semantics.
Worked example: Replacing a rule-chain service implementation with an eBPF implementation changes how backend selection occurs. Clients still use the service abstraction to reach eligible workloads.
Mistake to avoid: Claiming eBPF is universally faster under every workload and configuration.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
18. Kernel processing and user-space cooperation
Cilium combines kernel-level eBPF processing with user-space control components and, for relevant application-layer features, proxy processing. Keeping work in the kernel can avoid some transitions, but different functions need different information and execution environments. Understand the complete path instead of assuming every networking feature runs entirely inside an eBPF program.
Worked example: An address-and-port policy can be enforced through the datapath, while an HTTP-aware decision may involve a configured proxy that interprets the request.
Mistake to avoid: Describing Cilium's application-layer processing as exclusively kernel-resident.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
Network policy and security
19. Security identity versus network location
Cilium's identity-based security model associates policy-relevant labels with security identities. An address tells the network where a workload is located; its identity helps express what that workload represents. Label-based rules can therefore continue expressing the same intent when a replacement workload receives a different IP address.
Worked example: A payments Pod is replaced and changes from 10.30.1.6 to 10.30.2.9. A correctly scoped rule selecting its payments labels still expresses the intended access.
Mistake to avoid: Treating a workload's current IP as its permanent security identity.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
20. Selecting the endpoints a policy governs
A policy's endpoint selector identifies the workloads whose traffic it governs. Peer selectors inside ingress or egress rules identify the other side of allowed or denied communication. Keep these roles separate when reading policy intent, and account for namespace scope when interpreting a namespaced policy.
Worked example: A policy selects app=archive and permits ingress from app=reader. It governs archive workloads; reader is the permitted source, not the policy's target.
Mistake to avoid: Reading a permitted peer selector as the endpoint selector.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
21. Ingress, egress and additive allow rules
Ingress governs traffic entering a selected workload, while egress governs traffic leaving it. Kubernetes NetworkPolicy allow rules are additive across policies selecting an endpoint. A connection must satisfy the applicable controls at both ends: allowing destination ingress does not override restrictive source egress.
Worked example: The database permits ingress from reporting, but reporting's egress rules allow only DNS. The database connection remains blocked until the relevant egress permission also exists.
Mistake to avoid: Checking only destination ingress when both endpoints have enforced policies.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
22. Policy enforcement modes
Cilium distinguishes default, always and never policy enforcement modes. Default mode generally ties enforcement to policies selecting endpoints and directions, with policy-specific controls also affecting isolation. Always mode enforces policy even without a selecting policy; never disables policy enforcement. Determine the effective mode before interpreting an apparent absence of rules.
Worked example: An endpoint has no selecting policy. Default-mode expectations cannot be applied unchanged to an environment configured for always enforcement, where missing allowances can block traffic.
Mistake to avoid: Assuming no policy object necessarily means unrestricted communication.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
23. Combining peer, port and protocol restrictions
A useful access rule identifies both the permitted peer and the permitted traffic. Address or identity selection constrains who can communicate; transport port and protocol constrain which service they can use. TCP and UDP are distinct protocols even when their numerical port values match.
Worked example: A rule permits analytics clients to reach TCP port 8443 on an API. It does not also authorize UDP 8443 or TCP 22.
Mistake to avoid: Interpreting a port number without its associated transport protocol.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
24. Selector intersections and alternative peers
In Kubernetes NetworkPolicy, a namespace selector and Pod selector within the same peer entry combine to narrow the match. Separate peer entries provide alternatives. This structural distinction is important when a rule should permit only a particular application inside a particular namespace rather than all Pods satisfying either condition.
Worked example: One peer entry combines namespace team=finance with Pod app=exporter. It permits finance exporters, excluding other finance Pods and exporters in other namespaces.
Mistake to avoid: Splitting intersecting selectors into separate entries and unintentionally broadening access.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
25. Explicit deny precedence
Cilium policy supports explicit deny rules in addition to allowances. A matching explicit deny takes precedence over a matching allow. Distinguish this from traffic blocked because it lacks an allowance: an explicit deny expresses a prohibition that adding another broad allow does not remove.
Worked example: An allowance permits access to an internal subnet, but an explicit deny matches the audit server within it. The audit server remains inaccessible through that matching traffic path.
Mistake to avoid: Attempting to override an explicit deny by adding a broader allow.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
26. Stateful replies and new reverse connections
Stateful enforcement can recognize replies belonging to an allowed connection. Those replies differ from a new connection initiated in the opposite direction. When diagnosing a bidirectional exchange, identify the initiating flow and tracked response before deciding whether a separate reverse-direction allowance is required.
Worked example: A permitted client opens a TCP connection to a server, and the server responds on that connection. This does not authorize the server to initiate a new client connection.
Mistake to avoid: Treating permission for response traffic as permission for arbitrary reverse connections.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
27. DNS access and name-based destinations
A workload needs permission to reach its resolver before DNS-dependent connections can succeed. Cilium can also express destination intent using DNS names through its DNS-aware policy mechanisms. Resolver access and access to the resolved destination are separate permissions; successful resolution does not grant unrestricted communication to every returned address and port.
Worked example: A worker may query its resolver but lacks permission to reach the resolved API on TCP 443. DNS succeeds while the application connection remains blocked.
Mistake to avoid: Adding only resolver access and expecting the application destination to become allowed.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
28. Application-layer policy restrictions
Application-layer rules refine permitted communication using protocol information such as HTTP methods and paths. They require the relevant protocol-aware processing and visibility. A transport-layer allowance identifies a connection opportunity; an application-layer rule can restrict what requests may pass through it. Preserve both levels when interpreting the policy.
Worked example: A rule permits GET requests to /health on the selected HTTP service. A POST to /health or a GET to /records does not satisfy that allowance.
Mistake to avoid: Reducing an HTTP rule to its destination port and ignoring request restrictions.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
29. Choosing the policy resource
Kubernetes NetworkPolicy provides portable network-policy constructs. CiliumNetworkPolicy adds Cilium-specific capabilities in a namespaced resource, while CiliumClusterwideNetworkPolicy provides cluster-wide policy scope. Choose based on required expressiveness and governance scope, and recognize that portability decreases when a design depends on implementation-specific extensions.
Worked example: A team needs HTTP path restrictions for its namespace. A Cilium-specific policy can express that requirement, whereas standard Kubernetes NetworkPolicy does not express HTTP paths.
Mistake to avoid: Assuming standard Kubernetes NetworkPolicy supports every Cilium policy feature.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
Service mesh and application traffic
30. Traffic directions and mesh use cases
North-south traffic crosses an application environment's boundary; east-west traffic moves between services inside it. Routing, security and observability may be needed in both directions. Classifying a flow helps identify whether ingress infrastructure, internal service communication or an external egress path is central to the problem.
Worked example: A browser reaching a storefront is north-south traffic. The storefront calling inventory is east-west traffic, even when the two Pods run on different nodes.
Mistake to avoid: Classifying every cross-node connection as north-south traffic.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
31. Sidecar-based and sidecarless architectures
A sidecar-based mesh places a proxy alongside application workloads, commonly inside each Pod. A sidecarless design moves mesh functions into shared infrastructure rather than requiring a proxy container in every application Pod. Cilium combines its datapath with proxy capabilities where needed, so sidecarless does not mean proxy-free.
Worked example: An application Pod has no proxy container, but HTTP processing occurs through node-level infrastructure. This is consistent with a sidecarless design.
Mistake to avoid: Assuming the absence of sidecars eliminates all application-layer proxies.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
32. Ingress host and path routing
Ingress routing maps incoming application requests to services using criteria such as hostname and path. Matching the intended route depends on the request's actual host and path, not simply its destination IP. The ingress implementation and its configuration determine how supported rules are realized.
Worked example: A request for reports.example.test with path /charts matches the reports route. Sending the same path with the storefront hostname can select a different backend.
Mistake to avoid: Testing only the ingress IP while omitting the required hostname.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
33. Gateway API's separation of responsibilities
Gateway API separates infrastructure selection, gateway listeners and application routing into resources with different responsibilities. GatewayClass identifies an implementation class, Gateway describes traffic-handling infrastructure and listeners, and route resources express application routing. This separation supports clearer delegation than placing every concern in one application-owned routing object.
Worked example: A platform team manages a shared Gateway while an application team manages its HTTPRoute. Routing ownership is delegated without giving the application team control of every listener.
Mistake to avoid: Treating an HTTPRoute as the resource that independently provisions all gateway infrastructure.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
34. Route attachment and cross-namespace permission
A route must be accepted by an appropriate Gateway listener; merely naming a parent does not guarantee attachment. Listener constraints can govern eligible routes and namespaces. Cross-namespace references to backend resources can also require permission through ReferenceGrant, which is distinct from permission to attach the route to a Gateway.
Worked example: An HTTPRoute attaches successfully but references a Service in another namespace without the required grant. Attachment success alone does not make that backend reference valid.
Mistake to avoid: Confusing listener attachment permission with cross-namespace backend-reference permission.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
35. Transport and application load balancing
Transport-layer load balancing selects destinations using connection-level information. Application-layer routing can inspect request properties such as HTTP hostnames and paths. A stable service address can distribute connections without distinguishing requests by URL, while a configured HTTP-aware gateway or proxy can make those finer routing decisions.
Worked example: Requests to /images and /billing share one address and port. Routing them to different services requires application-aware handling of the request paths.
Mistake to avoid: Expecting ordinary transport-layer backend selection to implement HTTP path routing.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
36. TLS termination and passthrough
TLS termination decrypts a connection at the terminating component, allowing application-layer inspection there. TLS passthrough preserves the encrypted application stream toward its destination, limiting which information an intermediary can inspect. If the backend connection is separately encrypted after termination, that creates a second protected segment with its own trust considerations.
Worked example: A gateway terminates client TLS and forwards plaintext HTTP to a backend. The client-facing segment is encrypted, but the backend segment needs separate protection.
Mistake to avoid: Assuming frontend TLS automatically encrypts the entire path to the application.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
37. Transparent encryption in transit
Cilium can use supported encryption mechanisms such as WireGuard or IPsec to protect eligible traffic in transit. Protection depends on the selected mechanism, configuration and traffic path. Network encryption addresses exposure on covered links; it does not replace application authorization, workload policy or a check of where encryption starts and ends.
Worked example: Covered cross-node traffic is encrypted, but an application still permits unauthorized requests. Encryption protects transport confidentiality without correcting the application's access decision.
Mistake to avoid: Assuming enabling encryption protects every traffic category and every application operation.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
38. Retries and duplicate application effects
Retries can improve resilience to transient failures but may repeat an operation that already reached the server. Evaluate idempotency and request outcomes before applying retry behavior through any supporting proxy or application configuration. A timeout means the caller lacks a timely result; it does not prove the server performed no work.
Worked example: An order-creation request times out after the server commits it. Retrying without an idempotency mechanism can create a second order.
Mistake to avoid: Treating every timed-out request as safe to repeat.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
39. Routing, network authorization and application authorization
Publishing a route makes a backend addressable through a chosen traffic path. Network policy determines whether relevant network communication is permitted, while application authorization determines whether a caller may perform an operation. These controls answer different questions and must be evaluated together when exposing a service.
Worked example: A valid /admin route reaches the service and passes network policy, but the application rejects a user without administrator privileges. Routing success does not imply operational permission.
Mistake to avoid: Using route availability as evidence that an application operation is authorized.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
Hubble and network observability
40. Reading a flow record
A Hubble flow record provides observations about network communication, such as endpoints, direction, protocol and verdict. Read these fields together to identify the actual flow being described. A source label, destination port or timestamp alone rarely establishes the cause of a problem; their combination gives the observation useful context.
Worked example: A record shows worker-to-cache traffic on TCP 6379 with a dropped verdict. The relevant investigation concerns that pair and transport, rather than the worker's unrelated HTTP calls.
Mistake to avoid: Diagnosing a flow from one isolated field while ignoring its endpoints and protocol.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
41. Forwarded and dropped verdicts
A forwarded verdict indicates that traffic passed the observed processing point. It does not prove successful delivery or an application response. A dropped verdict identifies rejection at an observed point, but its accompanying reason matters: policy rejection and another datapath failure require different remedies.
Worked example: An outgoing request is forwarded, yet no response appears. Continue investigating downstream reachability and server behavior instead of declaring the entire transaction successful.
Mistake to avoid: Equating one forwarded observation with end-to-end application success.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
42. Filters define the diagnostic question
Flow filters narrow observations by properties such as workload, namespace, protocol or verdict. Start with the suspected communication pair and expand when necessary. A filter that excludes the relevant direction or protocol can hide the evidence you need, so an empty result must be interpreted in light of the query's scope.
Worked example: Filtering only HTTP traffic returns nothing during a DNS failure. Including resolver traffic reveals the earlier failed dependency that prevented the HTTP request.
Mistake to avoid: Interpreting an empty filtered result as proof that no relevant traffic occurred.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
43. CLI, UI and aggregated access
The Hubble CLI supports focused flow queries, while the Hubble UI provides visual exploration of observed communication. Hubble Relay can aggregate access to observations from multiple nodes. Choose the view that answers the question, and establish which nodes are represented before treating the result as a cluster-wide account.
Worked example: A local view contains client-side observations but misses traffic on the destination node. A working aggregated view provides the additional node context needed for comparison.
Mistake to avoid: Assuming a node-local observation source represents every node in the cluster.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
44. Conditions for layer-seven visibility
Application-layer visibility requires supported protocol-aware observation to be enabled on the relevant path. Ordinary flow visibility does not automatically expose HTTP methods, URLs or status codes. Encryption can also conceal application content unless it is available at an appropriate inspection point, such as after authorized TLS termination.
Worked example: Hubble shows a TCP connection to port 443 but no HTTP path. The encrypted connection and observation configuration explain why transport metadata does not reveal the request URL.
Mistake to avoid: Expecting complete HTTP details merely because basic Hubble flows are available.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
45. Service maps as observed relationships
A service map summarizes communication relationships present in the observations it receives. It is useful for tracing dependencies, but its coverage depends on the observation period, traffic and collection scope. A missing edge can mean a dependency was inactive or unobserved rather than nonexistent or prohibited.
Worked example: A nightly export dependency is absent from a map collected during midday traffic. Observing the export window is necessary before concluding the dependency has disappeared.
Mistake to avoid: Treating an observed service map as a complete specification of permitted architecture.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
Installation, configuration and diagnosis
46. Matching installation choices to the environment
Installation decisions depend on the cluster's network environment, kernel capabilities, address management and intended datapath. Establish those constraints before selecting settings. A configuration suitable for one provider or routing design may fail elsewhere because its assumptions about address allocation, underlay routes or available kernel features do not hold.
Worked example: A design assumes the underlay routes Pod prefixes, but the target network only routes node addresses. Resolve that mismatch before choosing native routing.
Mistake to avoid: Copying another cluster's installation settings without checking its networking assumptions.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
47. Installation as an explicit desired configuration
The Cilium CLI supports installation workflows, but installation should still express deliberate choices about the intended environment. Record important options so the resulting deployment can be explained and reproduced. Distinguish initial installation from later configuration changes, which may have different rollout and compatibility implications.
Worked example: Two clusters are intended to use different IPAM modes. Recording that choice for each installation prevents an unexplained default from determining their address-management behavior.
Mistake to avoid: Treating successful installation as evidence that all configuration choices suit the environment.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
48. Component status versus workload connectivity
The Cilium CLI can report deployment status and component health. Status helps identify unavailable agents or other unhealthy components, but it addresses infrastructure readiness rather than every application path. Combine it with workload-specific evidence because healthy control components can coexist with incorrect policy, missing backends or external routing problems.
Worked example: All agents report healthy, yet one API is unreachable because its Service has no eligible backends. Component readiness does not resolve that application-specific issue.
Mistake to avoid: Stopping diagnosis after a healthy status report.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
49. Connectivity tests and their boundaries
Cilium CLI connectivity tests exercise selected communication paths and help validate networking behavior. Their conclusions apply to the scenarios and environment actually tested. Positive connectivity and intended isolation are different requirements, so a complete operational check should also establish that traffic meant to be denied is blocked.
Worked example: A permitted client reaches a database during testing, but an unauthorized namespace has not been checked. The successful connection does not establish the isolation requirement.
Mistake to avoid: Using one successful test path as proof that all connectivity and policy behavior is correct.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
50. Requested configuration and effective configuration
A declared setting, an installed configuration object and a component's effective behavior are related but distinct. Configuration changes may require reconciliation or component rollout depending on the option. Query the applicable configuration and component state rather than assuming every running node immediately adopted a requested change.
Worked example: A setting is updated, but one agent still operates with its prior configuration. Comparing desired and effective state explains why behavior differs across nodes.
Mistake to avoid: Reading only the desired value and assuming uniform runtime adoption.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
51. Diagnosing the first failing stage
Break a failed request into stages: name resolution, destination selection, routing, policy enforcement, transport establishment and application response. Use evidence to locate the earliest failure, then inspect the responsible component. This avoids changing an unrelated layer and makes the diagnosis specific enough to verify with another observation.
Worked example: DNS resolves and the TCP handshake succeeds, but HTTP returns 503. Investigate application routing or backend availability before modifying Pod-address allocation.
Mistake to avoid: Changing low-level networking when the evidence already shows transport connectivity succeeded.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
Cluster Mesh and multi-cluster networking
52. Connectivity prerequisites between clusters
Cluster Mesh connects Cilium-managed clusters, but it requires an appropriate network foundation and distinct cluster identification. Workload addressing and the chosen datapath must support unambiguous cross-cluster reachability. Overlapping address spaces can make destination selection ambiguous; control-plane connections alone do not establish a usable workload traffic path.
Worked example: Two connected clusters both assign 10.40.1.12 to different workloads in a design requiring unique Pod addresses. Correct the addressing conflict before expecting reliable routed communication.
Mistake to avoid: Assuming connecting cluster control endpoints resolves overlapping workload networks.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
53. Remote identity information
Cross-cluster communication needs more than knowledge of a remote IP address. Cilium's identity model allows policy-relevant information to accompany knowledge of remote workloads. Cluster, namespace and application context should be interpreted together, especially when different clusters reuse familiar namespace and application names.
Worked example: Both staging and production contain an app=processor workload. A production-only trust decision needs cluster context rather than relying on that shared application label.
Mistake to avoid: Treating identical application labels in different clusters as an automatic trust relationship.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
54. Cross-cluster service discovery
Cluster Mesh can make remote service backends available to appropriately configured multi-cluster services. Connecting clusters does not mean every local service automatically becomes a shared service. Service names, namespace context and sharing configuration determine the intended service relationship, while discovery supplies knowledge of eligible destinations.
Worked example: A shared catalog service includes a configured backend in the second cluster. An unrelated local debug service remains local because it is not part of that sharing configuration.
Mistake to avoid: Assuming all services are automatically exported when clusters are connected.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
55. Backend eligibility and locality
Multi-cluster load balancing chooses among eligible backends, potentially spanning local and remote clusters. Eligibility and selection preference are different questions: a backend can be discoverable without being preferred for a particular request. Locality choices can affect latency and traffic cost, while remote eligibility can support resilience when configured appropriately.
Worked example: Both local and remote catalog backends are eligible. A locality preference can favor local requests without erasing knowledge of the remote backends.
Mistake to avoid: Assuming a discovered remote backend must receive an equal share of traffic.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
56. Policy boundaries across clusters
Cluster Mesh connectivity does not itself authorize every cross-cluster connection. Traffic still encounters applicable policy enforcement, and each participating cluster needs rules consistent with the intended trust boundary. Evaluate source egress, destination ingress and the selectors' cluster context instead of equating network reachability with security permission.
Worked example: A remote reporting workload has a valid route to production storage, but production ingress permits only local workloads. The route exists while the connection remains unauthorized.
Mistake to avoid: Broadening production access merely because another cluster can discover its workloads.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education; Cilium Certified Associate (CCA) | CNCF
57. Partitions, failover and application state
A cross-cluster network partition can leave remote destinations known but unreachable. Multi-cluster discovery and load balancing must therefore be considered alongside failure detection and application design. Redirecting new requests to another cluster does not migrate existing connections or replicate the application's data and session state.
Worked example: Traffic shifts to a reachable catalog replica after a partition, but its data is stale because replication has stopped. Network failover alone cannot restore data consistency.
Mistake to avoid: Treating Cluster Mesh as an application-state replication or seamless connection-migration system.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
BGP and external connectivity
58. BGP as route exchange
Border Gateway Protocol exchanges routing information between peers. In Cilium external-networking designs, it can help external routers learn relevant network prefixes. BGP is a control-plane mechanism: packet forwarding follows the resulting routes and underlying network. A healthy peering session does not itself tunnel, encrypt or authorize workload traffic.
Worked example: A router learns a workload prefix through BGP but a firewall blocks the packets. The established session proves route exchange, not successful application connectivity.
Mistake to avoid: Describing BGP peering as an encrypted workload data tunnel.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
59. Advertisements, next hops and external access
External access requires appropriate destinations to be advertised or otherwise routed, with reachable next hops. Workload prefixes and service addresses represent different destination types and need suitable configuration. Check the external router's installed route and the forwarding path, because configured advertisement intent does not prove that a usable route reached the peer.
Worked example: A service address exists in the cluster, but the external router has no matching route. Internal service availability does not make that address externally reachable.
Mistake to avoid: Assuming assigning a service address automatically advertises it to external routers.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
60. Egress identity and the return path
External egress needs an outbound route, permitted traffic and a workable return path. Source translation or a configured egress gateway can provide an externally recognizable source address when appropriate. Determine which source the destination actually sees, especially when external systems use source-based allowlists; internal Pod identity and observed external source are different.
Worked example: An external allowlist accepts 192.0.2.60, but the request leaves as 192.0.2.61. Correcting DNS will not fix the source-based rejection.
Mistake to avoid: Troubleshooting only the destination while ignoring translated source addresses and return routing.
Source reference: Cilium Certified Associate (CCA) - Linux Foundation - Education
Sources
Credential and exam scope verified:
- Cilium Certified Associate (CCA) - Linux Foundation - Education
- Cilium Certified Associate (CCA) | CNCF