The Kubernetes Object Model & kubectl for the KCNA Exam: Manifests, the Declarative API, Labels & Namespaces

Introduction

The Kubernetes Fundamentals domain is the largest single section of the Kubernetes and Cloud Native Associate (KCNA) exam — around 44–46% of your score. Most guides map that domain onto architecture: control plane, worker nodes, and what each component does. That matters, and we cover it in the Kubernetes Architecture for the KCNA Exam guide. But there’s a second half of “fundamentals” that is just as heavily tested and far less discussed: how you actually describe and manipulate what runs on a cluster.

That is the object model — the idea that everything in Kubernetes is a persistent record of intent, expressed as a manifest, submitted through an API, and continuously driven toward reality by the control plane. Understand the object model and a whole category of KCNA questions (“What does kubectl apply do?”, “What field selects the Pods behind a Service?”, “What happens when you delete a Deployment?”) becomes answerable by reasoning rather than memorization.

This guide walks through the object model the way a practitioner internalizes it: the declarative API and its reconciliation loop, the anatomy of a manifest, API groups and versions, the kubectl verbs, labels and selectors, annotations, and namespaces. KCNA is conceptual and multiple-choice — you won’t type commands — but you will be asked what each concept means and does.

How the KCNA Tests the Object Model

The KCNA is a proctored, multiple-choice exam — roughly 60 questions in 90 minutes (see the KCNA Exam Format breakdown). It does not drop you into a terminal. Instead it tests whether you understand the model well enough to predict outcomes. Expect questions phrased like:

“Which approach describes the desired state of a resource in a file and applies it?”
“What Kubernetes mechanism continuously works to make actual state match desired state?”
“Which field in a manifest identifies the type of object being created?”
“How does a Service know which Pods to send traffic to?”
“What is the effect of running kubectl delete on a Deployment?”

Each of these maps to one clean concept. Learn the concepts precisely and you can answer by elimination even when the wording is unfamiliar.

The Declarative Model: Desired State and Reconciliation

The most important idea in all of Kubernetes — and the one the KCNA circles back to repeatedly — is that it is declarative. You do not tell Kubernetes how to do something step by step. You tell it what you want, and Kubernetes works continuously to make it so.

Concretely:

You submit a desired state — for example, “I want 3 replicas of this Pod running.”
Kubernetes stores that desired state in etcd via the API server.
Controllers run a never-ending reconciliation loop: observe actual state → compare to desired state → take action to close the gap.

If a node dies and a Pod disappears, the replica count drops below what you declared. The controller notices the drift and creates a replacement Pod. You never issued a “create a new Pod” command — the system self-heals because it is always reconciling toward the state you declared.

Exam framing: The declarative model is why Kubernetes is called self-healing and desired-state driven. The reconciliation loop (sometimes called the control loop) is the mechanism. If a question describes “continuously comparing actual state to desired state,” the answer is the controller / reconciliation loop.

This contrasts with the imperative approach, where you issue explicit commands (“create this, now scale that”). Kubernetes supports both styles through kubectl, but the declarative style is what makes GitOps, version-controlled infrastructure, and self-healing possible — themes that reappear in the Cloud Native Application Delivery domain.

Anatomy of a Kubernetes Object

Every object you create in Kubernetes shares the same top-level structure. Recognizing these four fields is a near-guaranteed KCNA point:

apiVersion: apps/v1        # which API group + version
kind: Deployment           # what type of object
metadata:                  # identity: name, namespace, labels, annotations
  name: web
  namespace: default
  labels:
    app: web
spec:                      # desired state — what YOU want
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
status:                    # actual state — Kubernetes fills this in (you don't write it)
  availableReplicas: 3

Field	What it means	Who sets it
`apiVersion`	The API group and version the object belongs to (e.g. `v1`, `apps/v1`)	You
`kind`	The type of object (`Pod`, `Deployment`, `Service`, `ConfigMap`…)	You
`metadata`	Identity — `name`, `namespace`, `labels`, `annotations`, `uid`	You (mostly)
`spec`	The desired state — the configuration you want	You
`status`	The actual state — observed and updated by the control plane	Kubernetes

The single most common trap here: confusing spec and status. spec is your intent; status is reality as reported by the system. You never hand-write status — controllers own it. A question like “which field records the number of replicas currently available?” points to status; “which field declares the number of replicas you want?” points to spec.

The Kubernetes API: Groups, Resources & Versions

Everything in Kubernetes is exposed through the API server as a RESTful resource. When you run a command, kubectl translates it into an HTTP request to the API server, which reads or writes the object in etcd.

Objects are organized into API groups:

The core (or “legacy”) group has an empty group name and appears as just a version, e.g. apiVersion: v1. It contains foundational objects: Pod, Service, ConfigMap, Secret, Namespace, Node, PersistentVolume.
Named groups bundle related objects, e.g. apps/v1 (Deployment, ReplicaSet, StatefulSet, DaemonSet), batch/v1 (Job, CronJob), networking.k8s.io/v1 (Ingress, NetworkPolicy).

Versions signal stability:

Version suffix	Meaning	Example
`v1`	Stable / GA — safe for production	`apps/v1`
`v1beta1`	Beta — enabled by default, may still change	`policy/v1beta1`
`v1alpha1`	Alpha — experimental, often disabled by default	`…v1alpha1`

You don’t need to memorize every group for KCNA, but you should recognize that apiVersion combines a group and a version, that v1 (no group) is the core group, and that alpha/beta/GA describe maturity. Custom Resource Definitions (CRDs) let you add your own object types to the API — the mechanism behind Operators and much of the CNCF ecosystem. That extensibility is a recurring KCNA theme: Kubernetes is a platform for building platforms.

kubectl: The Client for the Declarative API

kubectl is the command-line client that talks to the API server. KCNA won’t ask you to run it, but it loves to ask what a given verb does. Learn this table cold:

Command	What it does
`kubectl get <resource>`	List objects and their high-level status
`kubectl describe <resource> <name>`	Show detailed state, events, and configuration
`kubectl apply -f file.yaml`	Declarative — create or update to match the file
`kubectl create -f file.yaml`	Imperative — create; errors if it already exists
`kubectl delete <resource> <name>`	Remove an object
`kubectl logs <pod>`	Print a container’s logs
`kubectl exec -it <pod> -- sh`	Run a command inside a container
`kubectl scale --replicas=5 deploy/web`	Imperatively change replica count
`kubectl explain <resource>`	Describe a resource’s fields from the API schema

Imperative vs Declarative in Practice

This distinction shows up often on the exam:

Declarative (kubectl apply): you keep a manifest that describes the end state; Kubernetes figures out the diff. This is repeatable, version-controllable, and GitOps-friendly.
Imperative (kubectl create, kubectl run, kubectl scale): you issue a command that performs one action. Fast for experiments, but there’s no source-of-truth file to reapply.

The KCNA-preferred answer for production and automation is almost always declarative. If a scenario mentions storing configuration in Git, reproducibility, or “the same manifest applied repeatedly,” it’s pointing at kubectl apply and the declarative model.

Labels and Selectors: How Objects Find Each Other

Kubernetes objects are loosely coupled. A Service does not hold a hard-coded list of Pods; a Deployment does not reference its Pods by name. They connect through labels and selectors — arguably the most elegant idea in the object model, and a frequent KCNA question.

A label is a key/value pair attached to an object’s metadata, e.g. app: web, tier: frontend, environment: prod.
A selector is a query that matches objects carrying particular labels.

A Service uses a selector to decide which Pods receive its traffic:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web          # routes to every Pod labeled app=web
  ports:
    - port: 80
      targetPort: 8080

Any Pod labeled app: web — regardless of which Deployment created it or what node it runs on — becomes a backend for this Service automatically. Scale the Deployment up and the new Pods inherit the label and join the pool with no change to the Service. That is the loose coupling KCNA wants you to recognize.

The same mechanism connects a Deployment to the Pods it manages via spec.selector.matchLabels, and it powers kubectl get pods -l app=web (filter by label) and NetworkPolicy targeting. If a question asks how a Service, Deployment, or ReplicaSet identifies the Pods it governs, the answer is labels and selectors.

Annotations vs Labels

Both live in metadata, but they serve different purposes — an easy pair to mix up:

	Labels	Annotations
Purpose	Identify and select objects	Attach non-identifying metadata
Queryable by selectors?	Yes	No
Typical use	`app=web`, `tier=frontend`	build info, tool config, contact details, ingress hints

Rule of thumb: if something is used to find or group objects, it’s a label; if it’s just extra information for humans or tools, it’s an annotation.

Namespaces: Scoping the Cluster

Namespaces carve a single physical cluster into multiple virtual clusters. They provide a scope for object names and a natural boundary for access control and resource quotas.

Key facts the KCNA tests:

Object names must be unique within a namespace, not across the whole cluster. You can have a Pod named web in dev and another web in prod.
Kubernetes ships with a few built-in namespaces: default (where objects land if you don’t specify one), kube-system (control plane components), kube-public, and kube-node-lease.
Not everything is namespaced. Cluster-scoped objects — Nodes, PersistentVolumes, Namespaces themselves, and ClusterRoles — exist outside any namespace. Namespaced objects include Pods, Deployments, Services, ConfigMaps, and Secrets.
Namespaces pair with RBAC, ResourceQuotas, and LimitRanges to isolate teams and cap resource usage — the multi-tenancy story KCNA expects you to understand at a conceptual level.

If a scenario asks how to give two teams isolated environments on one cluster, or how to apply a memory quota to just one group of workloads, the answer involves namespaces.

Putting It Together: The Lifecycle of an Object

Here’s the end-to-end flow the object model produces — a mental model worth carrying into the exam:

You write a manifest (apiVersion, kind, metadata, spec).
kubectl apply sends it to the API server, which validates it and stores it in etcd.
A controller notices the new desired state and acts — e.g. the Deployment controller creates a ReplicaSet, which creates Pods.
The scheduler assigns each Pod to a node; the kubelet on that node starts the container.
Controllers keep reconciling. If reality drifts (a Pod dies), they act to restore desired state.
status fields are updated to reflect actual state, which you can read with kubectl get / describe.

Notice how the object model ties directly into the cluster architecture: the manifest is the input, the API server and etcd are the record, and controllers plus the scheduler and kubelet are the machinery that makes intent real.

Common KCNA Traps

Trap	The clarification
Confusing `spec` and `status`	`spec` = desired (you write it); `status` = actual (Kubernetes writes it)
Thinking `kubectl create` and `apply` are interchangeable	`create` is imperative and fails if the object exists; `apply` is declarative and reconciles
Believing Services reference Pods directly	Services use label selectors, never hard-coded Pod names
Assuming all objects are namespaced	Nodes, PersistentVolumes, Namespaces, and ClusterRoles are cluster-scoped
Treating labels and annotations as the same	Only labels are selectable; annotations are non-identifying metadata
Reading `apiVersion: v1` as “version 1 of everything”	It means the core group at version `v1`; named groups look like `apps/v1`

Frequently Asked Questions

Is the object model heavily tested on the KCNA?

Yes. It lives inside the Kubernetes Fundamentals domain, the exam’s largest at roughly 44–46%. Manifests, the declarative model, labels/selectors, and namespaces are recurring question sources alongside architecture.

Do I need to memorize YAML syntax for the KCNA?

No. You won’t write manifests in the exam. But you should recognize the four top-level fields (apiVersion, kind, metadata, spec) and understand what each represents, plus the role of status.

What’s the difference between `kubectl apply` and `kubectl create`?

apply is declarative: it creates the object or updates it to match your file, and it’s safe to run repeatedly. create is imperative: it creates the object once and errors if it already exists.

How does a Service know which Pods to route to?

Through label selectors. The Service’s spec.selector matches Pods by their labels, so any Pod carrying the right labels automatically becomes a backend — no Pod names involved.

Are all Kubernetes objects namespaced?

No. Most workload objects (Pods, Deployments, Services, ConfigMaps, Secrets) are namespaced, but Nodes, PersistentVolumes, Namespaces, and ClusterRoles are cluster-scoped and live outside any namespace.

What is the reconciliation loop?

It’s the continuous control loop that controllers run: observe actual state, compare to the desired state you declared, and take action to close the gap. It’s the mechanism behind Kubernetes’ self-healing behavior.

Conclusion

The object model is the quiet backbone of the KCNA’s largest domain. Once you see Kubernetes as a database of desired state (etcd), a declarative API (the API server), and a set of controllers reconciling reality toward that intent, the fundamentals questions stop being trivia. A manifest’s four fields, the spec-vs-status split, the apply-vs-create distinction, label-based loose coupling, and namespace scoping — get these clean and you’ll pick up a meaningful slice of the exam by reasoning alone.

Reading builds the mental model, but the KCNA rewards fast, confident recognition — 60 questions in 90 minutes leaves little room to deliberate. The most efficient way to find your gaps is realistic, exam-style questions with explanations. Warm up with our free KCNA practice questions, and when you’re ready for full-length, timed conditions across every domain, the KCNA Certification Ready Mock Exam Bundle gives you five mock exams with detailed explanations so you walk in knowing exactly where you stand.

To round out the Fundamentals domain, pair this with the Kubernetes Architecture guide and the Container Orchestration guide. And if you’re planning to continue toward CKA or CKAD afterward, the Kubernetes Certification Path Guide 2026 maps the whole journey — the object model you just learned is the same foundation those hands-on exams build on.