Skip to content

Kubernetes Fundamentals: KCNA practice questions

Kubernetes fundamentals is the vocabulary everything else builds on: what the cluster is made of, how objects describe what you want, and the everyday kubectl commands that operate it.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Kubernetes Fundamentals covers in KCNA

Kubernetes fundamentals is the vocabulary everything else builds on: what the cluster is made of, how objects describe what you want, and the everyday kubectl commands that operate it.

A cluster has a control plane and worker nodes. The kube-apiserver exposes the Kubernetes HTTP API and is the component every client and controller talks to. etcd is the consistent, highly available key-value store that holds all API server data. The kube-scheduler watches for Pods that are not yet bound to a node and picks a suitable node for each one. The kube-controller-manager runs the controllers that implement the behaviour of the API, and an optional cloud-controller-manager integrates with a cloud provider. On every node the kubelet makes sure the Pods assigned to it are running with their containers, a container runtime actually runs those containers, and kube-proxy, which is optional, maintains the network rules that implement Services. DNS is an add-on that provides cluster-wide name resolution.

Objects are persistent records of intent. Every manifest needs four top-level fields: apiVersion, kind, metadata and spec. The spec is the desired state you write; the status is the current state that Kubernetes maintains. The control plane works continuously to make the two match, so if a Deployment declares three replicas and one Pod fails, a replacement is started. That is why kubectl apply -f with a YAML file is the declarative way to manage resources: you change the file and Kubernetes reconciles. The metadata block carries identifying data such as the object's name, its UID and, for namespaced objects, its namespace. Since Kubernetes 1.25 the API server can also validate fields on the server side: kubectl --validate accepts Strict, Warn or Ignore, and the default of true behaves like Strict, so an unknown or duplicated field in a manifest is rejected instead of silently dropped.

Node maintenance is a classic set of commands. kubectl cordon marks a node unschedulable: no new Pods are placed there, but the Pods already running stay where they are. kubectl drain goes further and evicts the Pods so their containers can terminate gracefully, respecting any PodDisruptionBudgets. It needs --ignore-daemonsets on nodes that run DaemonSet Pods, because the DaemonSet controller would immediately replace them, and those Pods keep running until the node leaves the cluster. After the work is done, kubectl uncordon makes the node schedulable again. Draining is aimed at planned work such as a kernel upgrade or hardware repair, and the docs note one exception: a Pod that sets nodeName directly is bound to that node and keeps running there even after the node is drained and marked unschedulable.

Key points

  • Control plane: kube-apiserver, etcd, kube-scheduler, kube-controller-manager, optional cloud-controller-manager.
  • Every manifest needs apiVersion, kind, metadata and spec; status is written by the system.
  • kubectl cordon only marks a node unschedulable; running Pods stay.
  • kubectl drain evicts Pods, respects PodDisruptionBudgets and needs --ignore-daemonsets for DaemonSet Pods.
  • After maintenance, kubectl uncordon lets the scheduler place new Pods on the node again.

Three sample questions

123 KCNA questions on Kubernetes Fundamentals, 123 with explanations. How practice works

Question 1

You need to temporarily prevent new pods from being scheduled on a node for maintenance. Which command should you use?
  1. A.kubectl taint nodes node1 maintenance=true:NoSchedule
  2. B.kubectl cordon node1
  3. C.kubectl drain node1
  4. D.kubectl delete node node1

Correct answer: B

kubectl cordon marks a node as unschedulable, preventing new pods from being scheduled while existing pods continue running. This is ideal for temporary maintenance. Option A (taint) is more complex and requires pod tolerations. Option C (drain) would evict existing pods. Option D would remove the node entirely.

Question 2

What is the primary purpose of an init container in Kubernetes?
  1. A.To run alongside the main container throughout the pod's lifecycle
  2. B.To perform setup tasks that must complete before the main container starts
  3. C.To monitor the health of the main container
  4. D.To handle network traffic for the main container

Correct answer: B

Init containers run to completion before the main application containers start. They're used for setup tasks like waiting for services, populating volumes, or running initialization scripts. They don't run alongside the main container (that's a sidecar).

Question 3

Which kubectl command creates a deployment named "web-app" with the nginx image?
  1. A.kubectl run web-app --image=nginx
  2. B.kubectl create deployment web-app --image=nginx
  3. C.kubectl deploy web-app --image=nginx
  4. D.kubectl apply deployment web-app --image=nginx

Correct answer: B

kubectl create deployment creates a deployment resource. Option A creates a pod, not a deployment. Options C and D use non-existent commands.

Practice this topic

Focus mode keeps every question on Kubernetes Fundamentals until you leave it. 10 free guest answers, then a free account; no credit card.

Or open KCNA practice across all topics.

Sources

The explanation above was checked against these official documents.

Frequently asked questions

What is the difference between kubectl cordon and kubectl drain?

cordon only marks the node unschedulable, so new Pods go elsewhere while existing Pods keep running. drain also marks it unschedulable and then evicts the Pods it can, honouring PodDisruptionBudgets, so the node can be taken down for maintenance.