KCNA - Kubernetes Fundamentals (44% of the exam) - Section 1.3
Explain the Kubernetes API, its declarative model, and how manifests express desired state.
API groups and versions, the apiVersion/kind/metadata/spec/status shape of every object, the difference between declarative apply and imperative commands, and why status is written by controllers rather than by users.
apiVersion and kindspec versus statusdeclarative versus imperativeAPI groups and versioningCustom Resource Definition
Practice question for this objective
lock_openFree sampleKubernetes Fundamentalsmedium
An operator inspects a Deployment and sees that its spec sets replicas to 5, while its status reports readyReplicas as 2. The cluster is under memory pressure and some pods are still being scheduled. What is the correct interpretation of these two fields?
ASpec records the desired state the author requested (5 replicas), while status records the current observed state (2 ready), so the controller is still working to converge themcheck_circle Correct
BThe object is inconsistent and should be deleted and recreated, because spec and status must always hold the same value
CStatus records what the author requested (5) and spec records what is running (2), so the operator should raise spec to close the gap
DThe operator should edit the status field to set readyReplicas to 5, which will bring the additional pods online
In every Kubernetes object spec holds the user's desired state and status holds the controller's observed state, and a gap between them signals reconciliation in progress. Kubernetes objects separate the declared intent (spec) from the reported reality (status); controllers continuously read spec, act on the cluster, and write what they observe back into status, so a temporary difference is normal convergence rather than a fault or an editable field.
Why A is correct: This correctly maps spec to author-declared desired state and status to controller-reported observed state; a gap between them simply means reconciliation is in progress.
Why B is wrong: It is tempting to read the mismatch as corruption, but spec and status are meant to differ during reconciliation; deleting the object is unnecessary and would discard a working desired state.
Why C is wrong: This inverts the roles: it sounds plausible if you assume status is the target, but spec holds desired state and status holds observed state, so editing spec would only change the goal, not the current count.
Why D is wrong: Writing to status seems like a direct fix, but status is populated by the controller from observed reality and is not the lever a user pulls; the pods appear when scheduling succeeds, not when the number is typed in.
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.
Run an imperative kubectl create command for every resource and delete then recreate objects by hand whenever a file in the repository changes.
errorWhy it is wrong: Imperative create does apply the files, which is why it tempts, but it captures a one-off action rather than a desired end state, so it does not reconcile drift and forces manual delete-and-recreate cycles.
Run kubectl create against the directory of manifests so each declared object is registered with the API server on every submission
errorWhy it is wrong: create is tempting because it does read the same YAML, but it is imperative and fails when an object already exists, so re-submitting the directory would error rather than update in place.
apiVersion names the object's owning namespace, while kind sets the number of desired replicas
errorWhy it is wrong: Namespace and replica count are unrelated concerns; this is tempting because both are common manifest values, but neither is what apiVersion or kind expresses.