CKA Domain 3: Services & Networking (20%) - Complete Study Guide 2026

Domain 3 at a Glance

Services & Networking accounts for 20% of the CKA exam, making it the third-largest domain behind Troubleshooting (30%) and Cluster Architecture, Installation & Configuration (25%). If you read our CKA Exam Domains 2026: Complete Guide to All 5 Content Areas, you already know that every domain carries real weight in a 2-hour, 15-20 task exam where partial credit is awarded per task. Domain 3 is not a domain you can skim.

What makes this domain uniquely challenging is that networking problems are silent. A misconfigured Service selector does not throw an exception - pods just never receive traffic. A Network Policy with the wrong podSelector does not print an error - connections simply time out. The exam rewards candidates who can read cluster state, reason about what should be happening, and fix it under pressure.

This guide covers every topic in Domain 3 with the depth needed to score well - not just what the topics are, but how they appear as tasks, where candidates lose points, and how to build the muscle memory to handle them in the exam environment.

Core Topics You Must Master

The breadth here is significant. You need both conceptual understanding (why does pod-to-pod traffic work without a Service?) and operational skill (write a Network Policy YAML from scratch in under 5 minutes). The sections below address each area with that dual lens.

Kubernetes Services: Types, Behavior, and Exam Traps

A Kubernetes Service is a stable abstraction that gives a set of pods a consistent IP address and DNS name, regardless of which individual pods are running at any moment. The exam tests whether you can create Services correctly, debug broken ones, and choose the right type for a given scenario.

The Four Service Types

Where Candidates Lose Points

The most common failure mode on Service tasks is a selector mismatch. The Service uses app: frontend but the pods are labeled app: web. The Service creates without error, endpoints show zero, and traffic silently fails. Always run kubectl get endpoints <service-name> immediately after creating a Service - if the ENDPOINTS column shows <none>, the selector is wrong.

A second trap: the targetPort versus port distinction. The port field is what clients use; targetPort is what the container is actually listening on. Exam tasks frequently specify these as different values to ensure you understand the difference.

Cluster Networking Fundamentals

The CKA expects you to understand the Kubernetes networking model at a conceptual level: every pod gets its own IP address, pods can communicate with any other pod without NAT, and nodes can communicate with all pods. You do not need to implement a CNI plugin from scratch, but you need to know what CNI does and how to install or verify one.

CNI Plugins on the Exam

Flannel, Calico, Weave, and Cilium all appear in CKA study materials. The exam typically specifies which CNI to install by providing the installation manifest URL or command. Your job is to apply it correctly and verify that nodes move from NotReady to Ready after installation. This topic most commonly appears in CKA Domain 1: Cluster Architecture, Installation & Configuration tasks around cluster bootstrapping, but understanding CNI is also required context for Domain 3 Network Policy behavior - Calico and Cilium enforce Network Policies natively; Flannel does not.

Pod-to-Pod Connectivity Verification

A practical skill tested in Domain 3 is verifying that two pods can actually communicate. The exam pattern is: create a temporary pod, kubectl exec into it, and use curl, wget, or nc to test connectivity. Know how to run a one-shot pod for testing:

kubectl run tmp --image=busybox --rm -it --restart=Never -- wget -qO- http://<service-name>.<namespace>.svc.cluster.local

Ingress Controllers and Gateway API

Ingress resources provide HTTP/HTTPS routing from outside the cluster to internal Services. An Ingress resource alone does nothing - it requires an Ingress Controller (typically NGINX in the exam environment) to be running. Exam tasks in this area typically ask you to create an Ingress resource that routes traffic based on hostname or path to a named Service.

Critical Ingress Fields

• spec.ingressClassName - must match the name of the installed IngressClass; missing this is a common failure
• spec.rules[].host - hostname-based routing
• spec.rules[].http.paths[].backend.service.name - must exactly match the Service name
• spec.rules[].http.paths[].pathType - use Prefix unless told otherwise
• spec.tls - TLS termination using a Secret; know the structure even if you don't always need it

Gateway API: Now Explicitly in Scope

The CKA curriculum now explicitly includes the Gateway API, which is a successor to Ingress providing more expressive, role-oriented traffic management. The key resource types are GatewayClass, Gateway, and HTTPRoute. The exam provides approved Gateway API documentation inside the exam VM - this is one of the allowed open-resource references alongside the standard Kubernetes docs. You do not need to memorize every field, but you must understand the three-resource hierarchy and be able to write an HTTPRoute that directs traffic to a backend Service.

Network Policies: The Most Exam-Heavy Topic

Network Policies are almost certainly the highest-value single topic in Domain 3. They appear frequently, they require precise YAML, and mistakes are invisible at create-time. A Network Policy selects a group of pods and specifies which ingress and/or egress traffic is allowed.

The Mental Model That Prevents Mistakes

By default, all pod-to-pod traffic is allowed. The moment you create any Network Policy that selects a pod, that pod's traffic in the affected direction (ingress or egress) becomes deny-all except what the policy explicitly allows. This surprises many candidates - you are not adding deny rules, you are opting into a whitelist model.

A practical checklist for every Network Policy task:

1. Identify which pods the policy should protect - this is the podSelector in spec
2. Identify the direction - policyTypes: [Ingress], [Egress], or both
3. Define the allowed sources/destinations using namespaceSelector, podSelector, or ipBlock
4. Specify allowed ports - leaving out ports allows all ports from the selected source
5. Test with kubectl exec + curl from an affected pod

Network Policy mastery connects directly to exam performance in the Troubleshooting domain as well. If you want a broader view of how these skills fit together, see our CKA Study Guide 2026: How to Pass on Your First Attempt, which addresses cross-domain skill overlap in detail.

CoreDNS and Service Discovery

CoreDNS is the default DNS server in Kubernetes clusters. Every Service automatically gets a DNS name following the pattern <service-name>.<namespace>.svc.cluster.local. Pods in the same namespace can use just the Service name; cross-namespace access requires the full FQDN.

What the Exam Tests About DNS

• Resolving a Service name from inside a pod using nslookup or dig
• Identifying CoreDNS issues by examining the CoreDNS pods in the kube-system namespace
• Understanding that headless Services (ClusterIP: None) return individual pod IPs via DNS rather than a single virtual IP
• Knowing that StatefulSets use predictable DNS names per pod: <pod-name>.<service-name>.<namespace>.svc.cluster.local

DNS issues frequently appear as Troubleshooting tasks (Domain 5), but the foundational knowledge lives in Domain 3. Building this understanding now pays double dividends on exam day.

What Domain 3 Tasks Actually Look Like

Understanding the format of CKA tasks is as important as knowing the content. Each task gives you a specific cluster context, a problem statement, and acceptance criteria. You switch clusters with kubectl config use-context at the start of each task. There is no GUI - everything happens in the terminal.

Typical Domain 3 task formats include:

• "Expose deployment X as a NodePort Service on port 30080." - Tests Service creation, type selection, and port configuration.
• "Create a Network Policy that allows only pods labeled role=monitoring in namespace ops to access pods labeled app=database in namespace prod on port 5432." - Tests cross-namespace Network Policy with combined selectors.
• "Create an Ingress resource that routes requests to host api.example.com/v1 to Service backend-svc on port 8080." - Tests Ingress resource creation with path and host rules.
• "The application in namespace staging cannot reach the database. Investigate and fix the issue." - Tests debugging of Network Policy, Service selector, or DNS misconfiguration.

The difficulty of these tasks is real, but manageable with consistent hands-on practice. Our CKA practice tests are structured to simulate this exact task format, including multi-cluster context switching and timed sessions that mirror the 2-hour exam window.

For a realistic picture of how difficult these tasks feel under exam conditions, the How Hard Is the CKA Exam? Complete Difficulty Guide 2026 walks through the pressure factors that separate preparation from performance on exam day.

Domain 3 Study Schedule

Given that Domain 3 carries 20% weight and contains several technically dense topics, it warrants dedicated focus. The schedule below assumes you are studying across all five domains and fits Domain 3 into a broader 6-8 week preparation plan. If you have already completed CKA Domain 2: Workloads & Scheduling, you have the pod and deployment fluency needed to make this domain's hands-on practice efficient.

This schedule concentrates Network Policy work in Week 2 because it is the topic most likely to cause partial-credit losses on the exam. If you are short on time, prioritize Services and Network Policies above Ingress and Gateway API - but do not skip the Gateway API entirely given its explicit inclusion in the current curriculum.

Understanding what this exam ultimately means for your career can sharpen motivation during dense study weeks. The CKA Salary Guide 2026: Complete Earnings Analysis offers qualitative context on how the credential positions professionals in the Kubernetes job market.

Frequently Asked Questions