All Linux Foundation / CNCF exams
Free CKNE practice test: 30 questions with answers
30 original questions for Certified Kubernetes Network Engineer, drawn from every topic area. Answer each one to see whether you got it right and why. No sign-up.
- Free questions
- 30
- Full bank
- 100 questions
All 30 CKNE questions with answers
The same questions as the test above, grouped by exam topic. Open any question to see the answer and explanation.
Services and Ingress (8 questions)
Question 1
An application must be exposed to clients outside the cluster through an HTTP host and path rule, with a single load balancer address. Which resource should be used?
- AA ClusterIP Service that exposes pods on an internal virtual address
- BA headless Service with no selector and manually managed Endpoints
- CAn Ingress with rules, served by an Ingress controller behind a LoadBalancer Service
- DA ConfigMap with the host name and path prefixes listed as key-value entries for the application
Show answer and explanationHide answer
Correct answer: CAn Ingress defines host and path rules, and an Ingress controller exposed through a LoadBalancer provides one entry point. ClusterIP is internal, headless services do not route traffic, and ConfigMaps are not routing objects.
Question 2
An Ingress resource is created, but no traffic reaches the application. Which component is missing?
- AA PersistentVolumeClaim bound to a storage volume
- BAn Ingress controller that implements the Ingress resource
- CA ServiceAccount with cluster-admin bound by a RoleBinding in kube-system
- DA ResourceQuota capping pod count in a namespace
Show answer and explanationHide answer
Correct answer: BThe Ingress resource is only configuration; an Ingress controller must be running to act on it. Storage claims, service accounts and quotas do not route HTTP traffic.
Question 3
A team wants TLS termination for an application exposed through an Ingress. Which configuration is required?
- AA TLS section in the Ingress that references a Secret containing the certificate and key
- BStoring the certificate in the pod's container image name as a tag suffix in CI
- CA plaintext password in the Ingress annotations that the controller decodes for termination
- DTurning off the Ingress controller and removing the IngressClass resource from the cluster
Show answer and explanationHide answer
Correct answer: AThe TLS section references a Secret with the certificate and private key, which the controller uses for termination. Plaintext passwords, disabled controllers and image names are not TLS configuration.
Question 4
Which newer Kubernetes API provides a more expressive model for routing and gateways than Ingress, with separate roles for infrastructure and application teams?
- AJob API
- BConfigMap API
- CGateway API
- DCronJob API only
Show answer and explanationHide answer
Correct answer: CThe Gateway API separates gateways managed by infrastructure teams from routes managed by application teams. Job, CronJob and ConfigMap are not gateway APIs.
Question 5
A Service with type LoadBalancer is created on a cluster without a cloud controller or load balancer implementation. What is the most likely result?
- AThe external IP stays pending because no load balancer controller provisions one
- BThe Service type is silently converted to ClusterIP by the API server during reconciliation
- CThe Service is removed entirely by the scheduler when pods are absent
- DThe external IP is set to the node name of one of the cluster's worker nodes
Show answer and explanationHide answer
Correct answer: AWithout a load balancer implementation, the external address remains pending. The Service type does not change automatically, the scheduler does not delete Services, and node names are not external IPs.
Question 6
A Service's traffic must always reach pods on the same node that received the request, to preserve client source IPs. Which setting helps?
- AsessionAffinity: ClientIP only
- BclusterIP: None
- Ctype: ExternalName
- DexternalTrafficPolicy: Local
Show answer and explanationHide answer
Correct answer: DexternalTrafficPolicy Local keeps traffic on the receiving node and preserves the client source IP. Session affinity controls stickiness, headless services remove virtual IPs, and ExternalName is a DNS alias.
Question 7
An endpoint slice for a Service is empty. The pods appear running. What is the most likely cause?
- AThe CoreDNS deployment is offline in kube-system, so Service DNS lookups are failing
- BThe pod names exceed the maximum length allowed by the endpoint slice controller
- CThe Service selector does not match the pod labels, or the pods are not Ready
- DThe cluster has too many worker nodes registered with the control plane scheduler in one zone
Show answer and explanationHide answer
Correct answer: CEndpoints come from Ready pods that match the selector, so a mismatch or unready pods leave the slice empty. Node counts, DNS and name length do not empty endpoint slices.
Question 8
A Service port must map external port 80 to container port 8080. Which fields express this?
- AexternalName: 8080, protocol: TCP
- Bport: 80 and targetPort: 8080
- CnodePort: 80 with type: NodePort
- DclusterIP: 8080, type: ClusterIP
Show answer and explanationHide answer
Correct answer: Bport is the Service port and targetPort is the container port that traffic is forwarded to. The other fields do not express the mapping.
Kubernetes Networking Fundamentals (8 questions)
Question 9
Kubernetes requires that every pod receives its own IP address and can reach other pods without NAT. Which component implements this requirement?
- Aetcd cluster store
- BCoreDNS name server
- Ckube-scheduler pods
- DA CNI network plugin
Show answer and explanationHide answer
Correct answer: DThe CNI plugin assigns pod IPs and sets up the routing that gives the flat pod network model. The scheduler places pods, etcd stores state, and CoreDNS resolves names.
Question 10
Two containers in the same pod need to communicate with each other. Which address do they use?
- AThe node's public IP, reached through an external NAT
- Blocalhost, because they share the pod's network namespace
- CA ClusterIP Service that forwards to the pod IP
- DA NodePort exposed on the pod's high host port
Show answer and explanationHide answer
Correct answer: BContainers in one pod share a network namespace, so they communicate over localhost. Node IPs, Services and NodePorts are not needed for in-pod communication.
Question 11
A Service of type ClusterIP is created. Which network does its virtual IP belong to?
- AThe cluster service IP range configured for the control plane
- BThe node's physical subnet, assigned by the host network configuration
- CThe public internet range, globally routable from external client networks
- DThe pod's container network interface, created for each pod by CNI
Show answer and explanationHide answer
Correct answer: AClusterIP addresses come from the configured service CIDR and are virtual. They are not public addresses, not node subnets, and not pod interfaces.
Question 12
A NodePort Service is accessed on a node's IP address and a port in the high range. What forwards that traffic to the pods?
- AThe Ingress controller that proxies NodePort traffic to pod IPs directly
- BA VPN client on the node tunneling NodePort traffic to remote pods over WireGuard on each hop
- CThe kubelet on the node sending each packet to the pod manually over a VXLAN tunnel per pod
- Dkube-proxy programming rules on each node that route to the Service endpoints
Show answer and explanationHide answer
Correct answer: Dkube-proxy programs node rules that forward NodePort and ClusterIP traffic to ready endpoints. The kubelet does not route traffic, and an Ingress controller is not required for NodePorts.
Question 13
Which kube-proxy mode uses kernel IPVS for load balancing across Service endpoints?
- Aiptables-only mode with no rules
- BDNS mode
- CIPVS mode
- DUserspace mode with a single thread
Show answer and explanationHide answer
Correct answer: CIPVS mode uses the Linux IP Virtual Server for efficient load balancing. The other descriptions do not match the kube-proxy modes.
Question 14
A pod needs a dedicated address that is reachable from outside the cluster without a Service. Which feature is most appropriate?
- AA permanent public IP for every pod by default, assigned by the cloud provider at scheduling time and kept across restarts
- BUsing the pod name as a stable address that the scheduler maps to the pod across moves
- CStoring the pod's IP in a ConfigMap that the kubelet refreshes on every restart to route traffic
- DHostnetwork or a dedicated routing design, with awareness that pod IPs are not stable across restarts
Show answer and explanationHide answer
Correct answer: DPod IPs change when pods are recreated, and hostNetwork or specialized routing is used when a fixed address is needed. Default public IPs do not exist, ConfigMaps do not provide addressing, and pod names do not route traffic.
Question 15
Which DNS record format does a ClusterIP Service receive inside the cluster?
- Aservice.namespace.cluster.net
- Bservice.namespace.svc.cluster.local
- Cnamespace-service.dns.public.net
- Dpod-ip.service.k8s.local.net
Show answer and explanationHide answer
Correct answer: BCluster DNS resolves services as service.namespace.svc.cluster.local by default. The other formats do not follow Kubernetes conventions.
Question 16
Pods in a namespace cannot resolve a Service in their own namespace by short name. Which component should be checked first?
- AThe Helm chart version used to install the application and its release values
- BThe pod's CPU limit and memory request set in the container resource spec
- CThe kube-scheduler logs and its pod binding decisions written to disk on the node
- DThe DNS configuration in the pod's resolv.conf and the CoreDNS service
Show answer and explanationHide answer
Correct answer: DShort-name resolution depends on the pod's search domains and CoreDNS. Scheduler logs, Helm versions and CPU limits do not affect name resolution.
Troubleshooting Network Connectivity (7 questions)
Question 17
A packet capture is needed to see whether traffic reaches a pod's interface. Which approach is most practical in a cluster?
- ATaking a screenshot of the dashboard and sharing it with the team to decide if traffic reaches the pod
- BReading the pod's labels and comparing them against the Service selector to see which pods match
- CRunning a debug container in the pod's network namespace or on the node and capturing on the relevant interface
- DPrinting the Service manifest and the Endpoints object to a file, then reviewing the YAML for port numbers and selectors and labels
Show answer and explanationHide answer
Correct answer: CCapturing in the pod's network namespace or on the node interface shows real packets. Screenshots, labels and manifests do not show traffic.
Question 18
Connections to a Service fail only from one node. Which check is most useful?
- AChanging the Service's selector to match every pod in the cluster and tuning readiness probes
- BDeleting that node from the cluster immediately without draining its workloads or reviewing logs
- CVerifying kube-proxy and the CNI state on that node compared with healthy nodes
- DChanging the container image of every pod in the namespace to a newer tag
Show answer and explanationHide answer
Correct answer: CComparing the failing node's kube-proxy and CNI state with healthy nodes isolates the fault. Changing selectors, deleting the node immediately and changing images do not diagnose the node-specific failure.
Question 19
A team suspects that CoreDNS is returning stale records. Which check helps most?
- AComparing the record returned from inside a pod with the Service's current endpoints and checking the cache settings
- BIncreasing the number of replicas of the application without checking DNS and raising the HPA maximum for the frontend deployment
- CRestarting the Dashboard pod and clearing the browser cache on the operator's laptop over the weekend
- DChanging the node names in the kubeconfig and the cluster's inventory file, then re-running the join command on each worker
Show answer and explanationHide answer
Correct answer: AComparing returned records with current endpoints and checking cache configuration identifies staleness. The other actions do not address DNS data.
Question 20
Which tool helps observe network flows between pods and identify dropped traffic by policy?
- AA calendar app that syncs team events and meeting reminders
- BA flow observability tool integrated with the CNI, such as Hubble for Cilium
- CA word processor with track changes and shared document review history
- DA printer driver utility that manages queue settings and paper trays
Show answer and explanationHide answer
Correct answer: BFlow observability tools show allowed and dropped flows with policy context. Word processors, printer utilities and calendars do not observe network traffic.
Question 21
Which two checks help diagnose a pod that cannot connect to an external API? (Choose two.)
- AChanging the pod's name to see if the connection changes
- BRestarting the cluster's Dashboard
- CIncreasing the Service's port number
- DTesting DNS resolution of the external host from the pod
- EVerifying egress rules and any NetworkPolicy applied to the pod
Show answer and explanationHide answer
Correct answer: D, EDNS resolution and egress policy checks identify the most common external connectivity failures. Renaming pods, restarting the Dashboard and changing unrelated ports do not address the cause.
Question 22
A pod in one namespace cannot reach a Service in another namespace by name, but it reaches the Service by IP. Which name format should be used?
- Apod IP address in the 10.244.0.0/16 range
- Bservice.namespace.svc.cluster.local
- Cnode name of the worker host
- Dservice name only, without the namespace
Show answer and explanationHide answer
Correct answer: BCross-namespace names use the service and namespace with the cluster suffix. A short name only resolves in the same namespace, and pod IPs and node names are not Service DNS names.
Question 23
A pod can reach the internet by IP address but cannot resolve external names. Which component should be checked first?
- AThe pod's memory limit and CPU request in the workload's resource section
- BCoreDNS forwarding configuration and upstream DNS reachability
- CThe Service's type and its selector labels matching the backend pods
- DThe node's kernel version and the eBPF features compiled into the kernel
Show answer and explanationHide answer
Correct answer: BCoreDNS forwarders and upstream reachability explain external name failures when IPs work. Memory limits, Service types and kernel versions are not the first check.
Network Policies (7 questions)
Question 24
A namespace must deny all inbound traffic to its pods by default. Which NetworkPolicy achieves this?
- AAn ingress rule with no from selector admitting every source
- BAn egress-only policy with no ingress types in the namespace
- CAn empty podSelector with policyTypes Ingress and no ingress rules
- DA policy that selects no namespaces but permits every pod
Show answer and explanationHide answer
Correct answer: CAn empty pod selector applies to all pods, and listing Ingress with no rules denies inbound traffic. Allow-all rules, egress-only policies and namespace-free selections do not implement default deny for ingress.
Question 25
A NetworkPolicy must allow pods labeled app=web to reach pods labeled app=db on TCP port 5432 only. Which part expresses the source?
- AA policy that sets hostNetwork true for web pods
- BThe ingress rule's from.podSelector matching app=web
- CThe egress rule's to.nodeSelector matching the web nodes
- DA ConfigMap listing the web pods
Show answer and explanationHide answer
Correct answer: BThe ingress rule on the database pods names the source with from.podSelector. Node selectors, host networking and ConfigMaps do not express the source pod relationship.
Question 26
After applying a default-deny egress policy, pods cannot resolve names. Which rule restores DNS resolution without opening all egress?
- AAn egress rule allowing UDP and TCP port 53 to the CoreDNS pods in kube-system
- BAllowing ingress traffic from the kube-scheduler pods on port 10259
- CAn egress rule allowing traffic on every port to the public internet CIDR 0.0.0.0/0, unrestricted
- DRemoving the default-deny policy entirely and recreating it in the kube-system namespace
Show answer and explanationHide answer
Correct answer: AAllowing port 53 to CoreDNS restores name resolution while keeping other egress blocked. Opening all egress and removing the policy broaden access, and scheduler traffic is unrelated to DNS.
Question 27
Which two steps help validate that a NetworkPolicy works as intended? (Choose two.)
- ATesting allowed and denied connections from representative pods
- BConfirming the CNI plugin supports and enforces NetworkPolicy
- CAssuming the policy works because it was applied
- DChecking only the policy's name
- EDeleting the policy to see whether traffic changes
Show answer and explanationHide answer
Correct answer: A, BTesting both allowed and denied flows and confirming CNI enforcement validate the policy. Assumptions, name checks and deleting the policy to observe are not reliable validation methods.
Question 28
A policy must allow egress from a namespace only to a specific external CIDR on TCP port 443. Which NetworkPolicy elements express this?
- Aingress rule with from.namespaceSelector and podSelector
- Begress rule with to.ipBlock for the CIDR and ports for 443 over TCP
- CpolicyTypes set to Ingress alone, leaving egress unrestricted
- DnodeName selector for the CIDR range, matched against the target node's IP
Show answer and explanationHide answer
Correct answer: BAn egress rule with ipBlock and a port of 443 over TCP restricts outbound traffic to that destination. Ingress rules, policy types alone and node name selectors do not express it.
Question 29
Multiple NetworkPolicies select the same pod. How are they combined?
- AThe last policy alphabetically overrides the others by name in the namespace's sorted list
- BPolicies cancel each other out when their allow rules overlap, so the pod is isolated from traffic
- CTheir allow rules are additive, so traffic is permitted if any policy allows it
- DJust the first policy applies and the rest are ignored, as the order of creation sets precedence
Show answer and explanationHide answer
Correct answer: CNetworkPolicies are additive, and a connection is allowed if any applied policy allows it. The other behaviors do not match the model.
Question 30
A default-deny policy is applied to a namespace, and monitoring tools in another namespace must scrape pods. Which rule allows this?
- ADisabling the default-deny policy permanently across the namespace after the monitoring rollout
- BA rule that allows every namespace with no ports, so traffic from the cluster reaches the pod
- CAn egress rule for the monitoring pods to the internet on TCP 443 and UDP 53, with the destination CIDR left open
- DAn ingress rule with a namespaceSelector for the monitoring namespace and the scrape port
Show answer and explanationHide answer
Correct answer: DAn ingress rule that matches the monitoring namespace and scrape port allows only what is needed. Egress from monitoring pods, disabling default deny and allow-all rules broaden access too much.