Overview
Domain 2 moves from what Kubernetes objects are to how a running cluster orchestrates them. Networking covers the flat Pod network model, CNI plugins, Service types (ClusterIP, NodePort, LoadBalancer, ExternalName), CoreDNS names, Ingress and the newer Gateway API, and the role of a service mesh. Security covers authentication and authorisation with RBAC, ServiceAccounts, Secrets, NetworkPolicy, Pod Security Standards and the 4C model of cloud, cluster, container and code. Troubleshooting covers reading Pod status and events, and recognising states such as CrashLoopBackOff, ImagePullBackOff, OOMKilled and failing probes. Storage covers volumes, PersistentVolumes, PersistentVolumeClaims, StorageClasses, access modes and the Container Storage Interface.
The November 2025 revision raised this domain from 22% to 28% and added Troubleshooting as a named topic. Questions are conceptual, but they often describe a symptom and ask which object or setting explains it.
How it's tested
Questions here are usually scenario-led. A Pod cannot be reached, a user cannot list resources, a container restarts repeatedly, or data disappears after a Pod is rescheduled, and you choose the object, setting or diagnosis that fits. Knowing the default behaviour of each mechanism is usually what separates the right option from a plausible one.
-
Choose the Service type
A requirement such as internal-only access, a cloud load balancer or a DNS alias is given, and you pick the Service type or Ingress that meets it.
-
Read the Pod state
A status such as CrashLoopBackOff, ImagePullBackOff or OOMKilled is shown and you choose its likely cause or the next diagnostic step.
-
Least privilege
An access requirement is described and you select the right combination of Role or ClusterRole, binding and ServiceAccount, or a NetworkPolicy rule.
A Pod shows ImagePullBackOff after a new release. A failing liveness probe is a tempting answer because restarts are involved, but probes only run once a container has started. ImagePullBackOff means the kubelet could not fetch the image, so the likely causes are a mistyped tag, a private registry without an imagePullSecret, or a registry outage. kubectl describe pod shows the exact pull error in events.
Topics 4
Official topics from the CNCF / The Linux Foundation outline, in outline order.
2.1 NetworkingPod networking, Services, DNS, Ingress and service mesh.
- What it means
- Kubernetes gives every Pod its own IP in a flat network where Pods can reach each other without NAT. CNI plugins such as Calico or Cilium implement this. Services give a stable virtual IP and DNS name in front of a changing set of Pods selected by labels.
- What to understand
- ClusterIP is internal only and the default; NodePort opens a port on every node; LoadBalancer asks the cloud provider for an external load balancer; ExternalName returns a DNS CNAME. CoreDNS resolves names like my-svc.my-ns.svc.cluster.local. Ingress and the Gateway API route HTTP traffic by host or path through a controller. A service mesh such as Istio or Linkerd adds mTLS, retries and traffic splitting using sidecar or ambient proxies.
- How it shows up
- Expect to choose a Service type for a requirement, or identify what provides Pod-to-Pod connectivity.
- Common confusion
- Thinking an Ingress object works without an Ingress controller installed in the cluster.
2.2 SecurityAuthentication, authorisation, secrets and workload hardening.
- What it means
- Security in Kubernetes is layered. Requests to the API server are authenticated, authorised (usually by RBAC) and then checked by admission control. Workloads run with a ServiceAccount identity, and their runtime privileges are constrained by securityContext settings and Pod Security Standards.
- What to understand
- A Role grants permissions in one namespace and a ClusterRole cluster-wide; a RoleBinding or ClusterRoleBinding attaches them to users, groups or ServiceAccounts. RBAC is additive with no deny rules. Secrets are base64-encoded and need encryption at rest configured to be protected in etcd. NetworkPolicy is allow-list based once a Pod is selected. Pod Security Admission enforces the Privileged, Baseline and Restricted profiles. The 4C model nests code inside container, cluster and cloud.
- How it shows up
- Questions ask which RBAC object grants a permission, how to restrict Pod traffic, or what protects Secrets.
- Common confusion
- Believing base64 encoding in a Secret is encryption.
2.3 TroubleshootingDiagnosing Pods, nodes and Services from status and events.
- What it means
- Troubleshooting is reading what the cluster reports to find why a workload is not healthy: Pod phase and container states, events, logs, node conditions and Service endpoints.
- What to understand
- Pending usually means a scheduling or volume problem; ImagePullBackOff an image name, tag or registry credential problem; CrashLoopBackOff a container that starts and exits repeatedly; OOMKilled a memory limit exceeded. A failing readiness probe removes a Pod from Service endpoints without restarting it, while a failing liveness probe restarts the container. A Service with no endpoints usually has a selector that matches no ready Pods. kubectl describe and kubectl get events are the first tools to reach for.
- How it shows up
- A symptom is given and you pick its cause or the most useful next command.
- Common confusion
- Restarting or deleting the Pod before reading its events and logs.
2.4 StorageVolumes, persistent storage and the Container Storage Interface.
- What it means
- Container filesystems are ephemeral, so data that must survive restarts or rescheduling lives in volumes. Kubernetes separates the request for storage (PersistentVolumeClaim) from the storage itself (PersistentVolume), with StorageClasses enabling dynamic provisioning.
- What to understand
- emptyDir lives as long as the Pod; a PersistentVolume outlives Pods. Access modes include ReadWriteOnce, ReadOnlyMany, ReadWriteMany and ReadWriteOncePod. Reclaim policies Retain and Delete decide what happens after a claim is removed. CSI lets storage vendors ship drivers without changing Kubernetes code. StatefulSets use volumeClaimTemplates to give each replica its own claim. ConfigMaps and Secrets can also be mounted as volumes.
- How it shows up
- Questions ask which object requests storage, what a StorageClass does, or which volume type survives Pod deletion.
- Common confusion
- Expecting data in an emptyDir volume to survive the Pod being deleted or rescheduled.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Kubernetes network model
Every Pod gets a unique IP and can reach every other Pod without NAT.
- Remember
- A CNI plugin implements the model; Kubernetes itself does not.
- Tested as
- Questions on what provides Pod connectivity point to CNI.
- Trap
- Naming kube-proxy as the Pod network provider.
-
Service types
ClusterIP, NodePort, LoadBalancer and ExternalName expose Pods in different ways.
- Remember
- ClusterIP is the default and is reachable only inside the cluster.
- Tested as
- Choosing the type for a stated access need is a frequent item.
- Trap
- Choosing NodePort when a cloud load balancer is required.
-
CoreDNS
The cluster DNS server that resolves Service and Pod names.
- Remember
- Service names follow service.namespace.svc.cluster.local.
- Tested as
- Cross-namespace connection questions use this format.
- Trap
- Using only the short name across namespaces.
-
Ingress and Gateway API
APIs for routing external HTTP and HTTPS traffic to Services by host or path.
- Remember
- Both need a controller; Gateway API is the role-oriented successor.
- Tested as
- Layer 7 routing requirements point here.
- Trap
- Expecting an Ingress resource to work with no controller.
-
Service mesh
A layer of proxies that handles service-to-service traffic.
- Remember
- It adds mTLS, retries, traffic splitting and telemetry without app code changes.
- Tested as
- Questions on transparent encryption between services lead here.
- Trap
- Treating a mesh as a replacement for CNI networking.
-
RBAC
Role-based access control built from Roles, ClusterRoles and their bindings.
- Remember
- Permissions are additive; there are no deny rules.
- Tested as
- Least-privilege scenarios rely on picking the right pair.
- Trap
- Using a ClusterRoleBinding when access should be limited to one namespace.
-
ServiceAccount
The identity a Pod uses when calling the Kubernetes API.
- Remember
- Each namespace has a default ServiceAccount; bind roles to custom ones for apps.
- Tested as
- Questions on Pod access to the API point here.
- Trap
- Giving the default ServiceAccount broad permissions.
-
Secrets
Objects that hold sensitive data such as passwords and tokens.
- Remember
- Values are base64-encoded; encryption at rest must be enabled separately.
- Tested as
- Questions test whether Secrets are secure by default.
- Trap
- Treating base64 as encryption.
-
NetworkPolicy
Rules that restrict which Pods and endpoints a selected Pod may talk to.
- Remember
- Once a Pod is selected, only allowed traffic passes, and the CNI must support it.
- Tested as
- Pod isolation requirements point here.
- Trap
- Assuming policies apply on a CNI that does not enforce them.
-
Pod Security Standards
Three profiles (Privileged, Baseline, Restricted) enforced by Pod Security Admission.
- Remember
- PodSecurityPolicy was removed in 1.25.
- Tested as
- Hardening questions name these profiles.
- Trap
- Choosing PodSecurityPolicy as the current mechanism.
-
Readiness vs. liveness probes
Readiness controls traffic; liveness controls restarts.
- Remember
- Failing readiness removes a Pod from endpoints; failing liveness restarts the container.
- Tested as
- Troubleshooting scenarios hinge on which probe is failing.
- Trap
- Expecting readiness failures to restart a container.
-
PV, PVC and StorageClass
A PVC requests storage, a PV provides it, and a StorageClass provisions PVs on demand.
- Remember
- Pods reference claims, not volumes directly.
- Tested as
- Persistent data questions are built on this chain.
- Trap
- Thinking a Pod mounts a PersistentVolume by name.
-
CSI
The Container Storage Interface standard for storage drivers.
- Remember
- Vendors ship CSI drivers outside the Kubernetes codebase.
- Tested as
- Pairs with CNI and CRI in standards questions.
- Trap
- Confusing CSI with CNI.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
ClusterIP vs. NodePort vs. LoadBalancer vs. ExternalName
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| ClusterIP | Virtual IP reachable inside the cluster | Default type; no external access | Expecting outside clients to reach it |
| NodePort | Opens the same port on every node | Reachable at nodeIP:port | Choosing it when a managed cloud load balancer is needed |
| LoadBalancer | Provisions an external load balancer from the provider | Builds on NodePort and ClusterIP | Expecting it to work on bare metal with no load balancer implementation |
| ExternalName | Maps the Service to an external DNS name | Returns a CNAME; no proxying or selector | Expecting it to load-balance Pods |
Readiness vs. liveness vs. startup probes
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Readiness | Is the container ready to receive traffic | Failure removes the Pod from Service endpoints | Expecting a restart on failure |
| Liveness | Is the container still healthy | Failure restarts the container | Setting it so strict it causes CrashLoopBackOff |
| Startup | Has a slow application finished starting | Holds off the other probes until it succeeds | Leaving it out for slow-starting apps |
Role vs. ClusterRole
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Role + RoleBinding | Permissions inside one namespace | Scoped to that namespace only | Trying to grant access to nodes, which are cluster-scoped |
| ClusterRole + ClusterRoleBinding | Permissions across the whole cluster | Covers cluster-scoped resources | Granting cluster-wide access when one namespace was asked for |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
kube-proxy as the Pod network
- What candidates pick
- kube-proxy as the component that gives Pods IP connectivity.
- Why it looks right
- Its name suggests networking.
- Why it's wrong
- Pod-to-Pod networking comes from the CNI plugin; kube-proxy only programs Service routing rules.
Clue to watch for A question about how Pods on different nodes reach each other.
-
Secrets are encrypted
- What candidates pick
- Storing data in a Secret as sufficient protection.
- Why it looks right
- The object is called Secret and values look scrambled.
- Why it's wrong
- Values are only base64-encoded; protection needs encryption at rest, RBAC limits or an external secrets store.
Clue to watch for Wording about protecting data stored in etcd.
-
NetworkPolicy without enforcement
- What candidates pick
- Creating a NetworkPolicy and expecting traffic to be blocked on any cluster.
- Why it looks right
- The API accepts the object without error.
- Why it's wrong
- Enforcement depends on a CNI plugin that implements NetworkPolicy, such as Calico or Cilium.
Clue to watch for A scenario where a policy exists but traffic still flows.
-
Readiness restarts the Pod
- What candidates pick
- Choosing the readiness probe to recover a hung process.
- Why it looks right
- Both probes check health.
- Why it's wrong
- Readiness failures only remove the Pod from endpoints; a liveness probe is what restarts a stuck container.
Clue to watch for A requirement to restart a container that stops responding.
-
ClusterRoleBinding for one namespace
- What candidates pick
- Binding a ClusterRole with a ClusterRoleBinding to give a team access to its namespace.
- Why it looks right
- ClusterRoles are reusable and convenient.
- Why it's wrong
- A ClusterRoleBinding grants the permissions in every namespace; a RoleBinding referencing the ClusterRole limits it to one.
Clue to watch for The words 'only in the dev namespace'.
-
ImagePullBackOff read as a crash
- What candidates pick
- Investigating application logs for an ImagePullBackOff Pod.
- Why it looks right
- The Pod is not running, like a crash.
- Why it's wrong
- The container never started, so there are no application logs; the image reference or registry credentials are wrong.
Clue to watch for Status ImagePullBackOff or ErrImagePull.
Answer framework
Work through orchestration scenarios by identifying the layer involved before picking a mechanism.
- Decide whether the problem is connectivity, access, health or data, which maps to Networking, Security, Troubleshooting or Storage respectively.
- For connectivity, separate Pod networking (CNI), stable discovery (Service and CoreDNS), external HTTP routing (Ingress or Gateway) and service-to-service policy (mesh).
- For access, name the subject (user, group or ServiceAccount), the scope (namespace or cluster) and the verbs required, then pick the Role or ClusterRole and binding.
- For unhealthy Pods, read the status and events first, then map the state to a cause: scheduling, image pull, crash, memory limit or probe failure.
- For data, ask whether it must outlive the Pod; if so use a PersistentVolumeClaim, and check the StorageClass and access mode match the workload.
Practice question
Want more like this? The KCNA practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Split this domain into its four topics and give networking and security the most time, because they generate the trickiest options. On a local cluster, expose one Deployment through each Service type and resolve it by DNS from another namespace. Install an Ingress controller and watch an Ingress do nothing until the controller exists.
For security, create a ServiceAccount, a Role and a RoleBinding, then use kubectl auth can-i to test what is allowed. Decode a Secret with base64 to see for yourself that it is not encrypted. Apply a default-deny NetworkPolicy on a CNI that enforces it and add allow rules one at a time.
Troubleshooting is best learned by breaking things on purpose: use a wrong image tag, set a tiny memory limit, and add a liveness probe that fails. Read each status and its events until you recognise the pattern immediately.
Finish storage with a PVC on the default StorageClass mounted in a Pod, then delete the Pod and confirm the data remains. Review older notes carefully, as this domain grew to 28% in 2025.
FAQ
How much is Container Orchestration worth on the KCNA?
Container Orchestration carries 28% of the KCNA score, about 17 of 60 questions. It is the second-largest domain and grew from 22% in the November 2025 curriculum revision.
Do I need to know specific CNI plugins?
Know what CNI does and recognise common plugins such as Calico, Cilium and Flannel, including which ones enforce NetworkPolicy. Configuration details are not expected.
Is service mesh still on the KCNA?
Service mesh is no longer a named heading, but it fits within Networking. Know what Istio and Linkerd add, such as mTLS and traffic splitting.
What troubleshooting depth does the KCNA expect?
Recognise common Pod states and their causes, the difference between probes, and which kubectl command reveals the problem. You will not fix a live cluster.
Are Secrets safe to store passwords in?
Only with extra measures. By default values are base64-encoded in etcd, so enable encryption at rest and restrict access with RBAC.
Which storage topics matter most?
The PVC, PV and StorageClass relationship, access modes, reclaim policies, ephemeral versus persistent volumes, and the purpose of CSI.
What replaced PodSecurityPolicy?
Pod Security Admission, which enforces the Privileged, Baseline and Restricted Pod Security Standards at namespace level. PodSecurityPolicy was removed in Kubernetes 1.25.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
Practise Service type choices, RBAC least-privilege scenarios, Pod state diagnosis and persistent storage questions under timed conditions.