Services and Networking

Worth 20% of the CNCF Certified Kubernetes Administrator (CKA) exam. CertClue has 20 questions on this objective.

What this objective covers

Service Types, Ingress, and Cluster DNS

Pods are ephemeral and get new IP addresses whenever they are recreated, so nothing in a healthy cluster should ever talk to a Pod IP directly. A Service gives a stable address in front of a changing set of Pods, and CoreDNS gives that address a name. Ingress then adds HTTP aware routing on top of Services for traffic coming from outside the cluster, and NetworkPolicy is the one mechanism that can restrict traffic that would otherwise flow freely between any two Pods.

Exam tip. If a Service has no endpoints, the fix is almost never the Service object itself. Compare the Service selector against the actual Pod labels, and confirm the target Pods are passing their readiness probe, since a Pod that is not ready is removed from the endpoint list.

Practice questions

Free, with the answer and the reasoning. No account needed.

1. A developer wants to expose a Deployment so that it is reachable from outside the cluster by hitting any node's IP address on a specific high numbered port, without deploying a cloud load balancer or Ingress controller. Which Service type should be used?

  • A. ClusterIP
  • B. NodePortcorrect
  • C. ExternalName
  • D. Headless

A NodePort Service opens a static port, by default in the 30000 to 32767 range, on every node, forwarding traffic on that port to the Service, which makes it reachable from outside the cluster via any node's IP without extra infrastructure. ClusterIP only exposes the Service inside the cluster. ExternalName maps a Service name to an external DNS name and does not expose cluster workloads outward. A headless Service, created with clusterIP: None, returns pod IPs directly via DNS and provides no external node port access.

2. You need a NetworkPolicy that allows pods labeled app=frontend to send egress traffic only to pods in the namespace labeled team=payments, and block all other egress. Which policy structure achieves this?

  • A. A policy with policyTypes: [Ingress] and an ingress rule matching namespaceSelector team=payments
  • B. A policy with no podSelector, applying the rule cluster wide to all namespaces
  • C. A policy with egress: [] and no policyTypes field, which implicitly allows only same namespace traffic
  • D. A policy with podSelector matching app=frontend, policyTypes: [Egress], and an egress rule whose to field contains a namespaceSelector matching team=paymentscorrect

Egress restriction requires policyTypes to include Egress, a podSelector to target the source pods, and an egress.to entry using namespaceSelector to scope allowed destinations to the payments namespace. Using Ingress policyTypes controls incoming traffic not outgoing, omitting podSelector applies the policy to every pod in the namespace rather than just frontend, and an empty egress array with no policyTypes does not enforce anything specific.

Work the whole objective

The full CNCF Certified Kubernetes Administrator bank, the study notes behind these summaries, and a readiness score that tells you which objective to revise next. Free, no paid tier.

Take the free CNCF Certified Kubernetes Administrator practice test

The other CNCF Certified Kubernetes Administrator objectives