KCNA - Kubernetes Fundamentals (44% of the exam) - Section 1.1
Identify the core Kubernetes resources and describe what each one is responsible for.
Pods, ReplicaSets, Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Services, ConfigMaps, Secrets and Namespaces are the vocabulary the rest of the exam is written in. Candidates are expected to match a workload requirement to the controller that satisfies it, and to know which object owns which part of the desired state.
PodDeploymentReplicaSetStatefulSetDaemonSetJob and CronJobNamespace
Practice question for this objective
lock_openFree sampleKubernetes Fundamentalsmedium
A cluster administrator manually deletes a Pod that was created by a Deployment. Within seconds a replacement Pod appears, although no one issued a create command. Which principle of the Kubernetes model best explains this behaviour?
AThe Pod's restartPolicy was set to Always, which caused the deleted Pod to restart itself in place after removal.
BThe kubectl client cached the original request and automatically resubmitted it to the API server after the deletion.
CA controller continuously reconciles the actual state toward the desired state declared in the Deployment, recreating the missing Pod.check_circle Correct
DThe kubelet on the node recreated the Pod object because it detected that the Pod's container had exited unexpectedly.
Kubernetes controllers continuously reconcile observed state toward the declared desired state, recreating resources that drift from the spec. The declarative model runs a reconciliation loop: a controller watches the desired state in an object's spec and the observed state, and when a managed Pod is deleted the observed count drops below the desired count, prompting the controller to create a replacement.
Why A is wrong: restartPolicy is a real field, so it tempts, but it governs restarting containers inside a still-existing Pod on its node and cannot bring back a Pod object that has been deleted from the API.
Why B is wrong: This sounds plausible if you imagine the client retrying, but kubectl is stateless between commands and does not resubmit past requests, so the recreation is not driven from the client side.
Why C is correct: The Deployment's controller compares the desired replica count in the spec against the Pods it observes, and when a Pod disappears the observed count falls below desired, so the controller creates a replacement to close the gap.
Why D is wrong: The kubelet does manage containers for Pods assigned to its node, which makes this tempting, but it does not create new Pod objects in the API server; that ownership belongs to the controller acting on the Deployment's desired state.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
You set status.replicas to 5 to express the desired state, and spec.replicas reports the number the controller currently observes.
errorWhy it is wrong: This inverts the model and tempts anyone who has not internalised the split: status is system-owned observed data and is not where a user declares intent, and spec is not updated by the controller to report reality.
A Deployment with the replica count set to the current number of nodes
errorWhy it is wrong: Matching the replica count to node count seems to give one agent per node, but the scheduler can place several replicas on one node and none on another, and the count does not adjust when nodes are added or removed.
status holds the desired configuration, and spec reports the observed state maintained by the controllers
errorWhy it is wrong: This inverts the two fields; it is tempting because both sound like state, but spec is the desired intent and status is what the system observes, not the reverse.