The Kubernetes and Cloud Native Associate (KCNA) exam objective 2.2 requires you to explain the Kubernetes API, YAML manifests, and core objects. This chapter covers the fundamental building blocks you need to understand before you can manage applications in a Kubernetes cluster. Without this knowledge, you would be trying to drive a car without knowing what the steering wheel, pedals, and gears do, let alone how they work together.
Jump to a section
A simple way to picture Kubernetes API and Core Objects
A building superintendent is the central person who manages everything in an apartment building. Tenants don't just walk into any apartment or turn on any utility whenever they want. Instead, they submit a request to the superintendent through a standard form. The form has specific fields: what they want (a new lightbulb), where (apartment 3B), and when (by Friday). The superintendent reads the form, checks if it's valid, and then makes it happen by telling the right worker (electrician, plumber) to carry out the task.
In this analogy, the superintendent is the Kubernetes API server. The standard form is the Kubernetes API. Tenants are you, the developer or operator. The workers (electricians, plumbers) are the components inside Kubernetes (like the scheduler, controller manager, and kubelet). The specific fields on the form are the YAML manifest you write. Each type of request – like asking for a new lightbulb versus asking for a plumbing fix – corresponds to a different "core object" in Kubernetes, such as a Pod, a Service, or a Deployment.
The key point is that everyone must talk to the superintendent using the correct form. No one is allowed to shout across the hallway or leave sticky notes. This ensures that every request is recorded, validated, and executed consistently. Without the superintendent, there would be chaos – orders lost, jobs duplicated, and disputes over who did what. The Kubernetes API server provides that same single source of truth and order for your containerised applications.
At its heart, Kubernetes is a system for running and managing containers. A container is a lightweight, standalone, executable package that includes everything needed to run a piece of software: code, runtime, system tools, libraries, and settings. Kubernetes (often shortened to K8s) automates the deployment, scaling, and operation of these containers across a cluster of machines.
To tell Kubernetes what you want it to do, you talk to its brain: the Kubernetes API. API stands for Application Programming Interface. Think of it as a waiter in a restaurant. You (the customer/developer) tell the waiter (the API) what you want. The waiter takes your order (the request) to the kitchen (the cluster components). The kitchen then prepares the dish (deploys your application) and brings it back to you. The entire conversation between you and Kubernetes happens through this API. You never shout directly into the kitchen; you always go through the waiter.
How do you give your order to the API? You write a YAML manifest. YAML stands for "YAML Ain't Markup Language". It is a human-readable data-serialisation language. Imagine instructions for assembling a piece of flat-pack furniture. Those instructions are written in a way that a human can read (words and pictures) and a machine can interpret (the structured steps). A YAML manifest is exactly that – a text file that describes the desired state of a piece of your application in a structured, predictable format. The file uses indentation (spaces, not tabs) to show hierarchy, and it uses key-value pairs to define properties.
Here is a minimal example of a YAML manifest that asks Kubernetes to run a single container:
apiVersion: v1 kind: Pod metadata: name: my-first-pod spec: containers: - name: nginx-container image: nginx:latest
This file says: - apiVersion: v1 – This is the version of the Kubernetes API I am using. Different API versions support different features. v1 is the stable, core version. - kind: Pod – This tells Kubernetes what object I want to create. A Pod is the smallest deployable unit in Kubernetes. It represents a single instance of a running process in your cluster. It can contain one or more containers that share storage, network, and a specification for how to run. - metadata: name: my-first-pod – This is the name for my Pod. It must be unique within the same namespace (a virtual cluster within the physical cluster). - spec: containers: – This is where you define what runs inside the Pod. Here, we specify one container named nginx-container using the official nginx image from a container registry (a library of pre-built container images).
Now, core objects are the different kinds of requests you can make through the API. They are the predefined categories or templates that Kubernetes understands. The most important core objects include:
Pod: As described, the smallest and simplest unit. It runs your container(s). Pods are ephemeral – they can be created, destroyed, and replaced at any time. You typically do not create a single Pod directly because if it crashes, it is gone. Instead, you use higher-level objects.
Deployment: This is the object you will use most often. A Deployment manages a set of identical Pods. You tell it "I want three copies of my web app running at all times." The Deployment controller then creates three Pods and watches them. If one Pod dies, the Deployment automatically creates a new one to replace it. It allows you to roll out updates, scale up (create more copies), and scale down (destroy some copies) without downtime.
Service: Pods come and go, and each time they are created, they get a unique IP address inside the cluster. That is not helpful if another part of your application needs to talk to your web app. A Service provides a stable, permanent network endpoint (an IP address and a DNS name) that points to the set of Pods managed by, for example, a Deployment. It acts like a receptionist – you call the main number, and the receptionist routes you to whoever is available.
Namespace: A way to divide cluster resources between multiple users or projects. Think of it as a separate folder on your computer. You can have a Namespace called "development" and another called "production", each containing its own Pods and Services, with no risk of name collisions.
ConfigMap and Secret: Used to manage configuration data separately from your container image. For example, a ConfigMap might hold database connection strings, and a Secret holds sensitive data like passwords (in an encoded form). This design makes your containers portable – you can reuse the same image in different environments (dev, test, prod) by changing only the ConfigMap or Secret.
Ingress: A way to expose HTTP and HTTPS routes from outside the cluster to Services within the cluster. It acts like a door that tells external traffic (from the internet) which internal Service to visit based on the URL.
These objects are not just concepts; they are actual resources that exist inside the etcd database (the cluster's persistent storage). Every time you submit a YAML manifest to the API, Kubernetes validates it, stores your desired state in etcd, and then the different controllers (like the Deployment controller) work to make that desired state the actual state in the cluster. This is known as the "desired state" model.
Why does this matter for the KCNA exam? Because the entire Kubernetes system is built on this API and these core objects. You must know what each object does, when to use it, and how to write a basic YAML manifest. Exam questions will ask you to identify the correct core object for a given scenario (e.g., "You need to run a stateless web application with automatic scaling and self-healing. Which object should you use?" Answer: Deployment). They will also test your understanding of what happens when you submit a manifest (validation, storage, reconciliation).
Imagine you are a platform engineer at a mid-sized e-commerce company called "ShopQuick". The company's main website is a Node.js application that runs in containers. Before Kubernetes, the team deployed this application manually to a few virtual machines (VMs) using SSH. The process was fragile: one typo in a configuration file could take the site down for hours.
Now, the company has adopted Kubernetes. You are tasked with deploying the ShopQuick website to a Kubernetes cluster. Here is what you would actually do, step by step:
Write a YAML manifest for a Deployment. You open your code editor and create a file called shopquick-deployment.yaml. You specify the container image (shopquick/web:v2), the number of replicas (3), and a health check endpoint. You also add labels – key-value pairs that help you identify and group resources. For example, you add a label app: shopquick.
Write a YAML manifest for a Service. You create a second file called shopquick-service.yaml. You specify that the Service should look for all Pods with the label app: shopquick. You set the type to ClusterIP (the default, which exposes the Service only inside the cluster). You map port 80 on the Service to port 3000 on the container (where the Node.js app listens).
Apply the manifests using kubectl. kubectl ("Kube Control") is a command-line tool that acts as a client to the Kubernetes API. You open a terminal and run:
kubectl apply -f shopquick-deployment.yaml kubectl apply -f shopquick-service.yaml
The kubectl tool reads the YAML file and sends an HTTP request to the Kubernetes API server. The API server validates the YAML against its schema (like checking that the fields are spelled correctly, the image exists, etc.). If valid, it stores the desired state in etcd.
Verify the resources. You run:
kubectl get deployments kubectl get pods kubectl get services
You see that three Pods have been created, and the Service has an internal cluster IP address. You can test the application by running a temporary Pod (using kubectl run) that curls (makes a network request to) the Service's IP.
Expose the application to the internet. You write an Ingress manifest that maps the domain www.shopquick.com to the Service. You apply it with kubectl apply. Once the Ingress controller (a separate component in the cluster) processes it, external traffic can reach the website.
Perform a rolling update. A new version of the app (v3) is ready. You update the Deployment manifest by changing the image tag from v2 to v3 and run kubectl apply again. Kubernetes performs a rolling update: it slowly replaces the old Pods with new ones one at a time, ensuring zero downtime. If the new version has a bug and the health check fails, Kubernetes automatically rolls back to the previous version.
Debug a failed Pod. One of the three Pods crashes. You run:
kubectl logs <pod-name> kubectl describe pod <pod-name>
The logs show a database connection timeout. The describe command shows events (like "Back-off restarting failed container"). You fix the database credentials in a Secret, update the Secret, and the new Pod automatically starts correctly.
Throughout this process, you never logged into a virtual machine. You never manually fixed a broken process. Every interaction was through the Kubernetes API, using YAML manifests. The cluster took care of the rest. For the KCNA exam, you need to understand these steps conceptually, even if you have never actually performed them. The exam will ask multiple-choice questions about the sequence, the purpose of each object, and what commands do.
The KCNA exam tests your understanding of the Kubernetes API and core objects through multiple-choice questions, drag-and-drop scenarios, and sometimes ordering tasks. You will not be asked to write YAML from scratch, but you must be able to read and interpret a YAML manifest.
Here are the specific topics and traps the exam focuses on:
Distinguishing between core objects: The exam loves to ask which object to use in a given situation. Common wrong answers are: using a Pod when you need resilience (the Pod does not self-heal, so you need a Deployment), using a Service when you need load balancing across multiple Pods (a Service does this, but a Pod does not), or using a ConfigMap for secrets (ConfigMap values are stored in plain text; Secrets are base64-encoded).
Understanding the desired state model: A typical question: "When you submit a Deployment manifest, what immediately happens?" Traps: answers claiming that Pods are created instantly (they are not; the request is stored in etcd, then controllers work asynchronously), or that the manifest is sent directly to nodes (it always goes through the API server). The correct pattern is: validation, storage in etcd, then reconciliation by controllers.
YAML syntax and structure: The exam may show a manifest with incorrect indentation or missing required fields and ask what is wrong. Key traps: using tabs instead of spaces (YAML only allows spaces), incorrect apiVersion (e.g., using apps/v1 for a Pod, but a Pod uses v1), or missing the spec field.
API versioning: You must know that different object kinds use different API versions. For example, Pods use apiVersion: v1, Deployments use apiVersion: apps/v1 (note the plural 'apps'). The exam may ask: "Which apiVersion is correct for a Deployment?" Traps include offering v1 or batch/v1.
Labels and Selectors: The concept of labels (attached to objects) and selectors (used by Services and Deployments to pick which Pods to manage) appears frequently. A common question: "A Service is not reaching any Pods. What is a likely cause?" The answer often involves a mismatch between the Service's selector and the Pod's labels.
Namespace behaviour: Questions might ask which objects are scoped to a namespace (Pods, Services, Deployments, ConfigMaps, Secrets) and which are cluster-scoped (Nodes, PersistentVolumes, Namespaces themselves, ClusterRoles). A trap: claiming that a Service is cluster-scoped, but it is namespace-scoped.
Immutability of certain fields: Some fields in a manifest cannot be changed after creation. For example, the name, namespace, and container image in a Pod spec are immutable. To change them, you must delete and recreate the object. The exam may present a scenario where you try to update an immutable field and ask what happens (the API server rejects the request).
Core objects versus custom resources: The exam tests whether you know which objects are part of the core Kubernetes API. Custom Resource Definitions (CRDs) exist but are not core objects. A trap might list CRDs as core objects.
Health checks and probes: Liveness probes, readiness probes, and startup probes are defined in the Pod spec. The exam may ask: "Which probe determines when a container is ready to serve traffic?" Answer: readiness probe. Or: "Which probe is used to know when to restart a container?" Answer: liveness probe.
Resource requests and limits: These are fields in the container spec (under spec.containers.resources.requests and .limits). The exam tests the difference: requests are what the container is guaranteed to get (used for scheduling), limits are the maximum it can use (used for throttling). A trap: confusing limit with request for scheduling decisions.
To summarise the correct answer pattern for these questions: always think in terms of the API-first architecture. Every object is created via a YAML manifest sent to the API server. The API server validates and stores the desired state. Controllers then work to converge the actual state to the desired state. If you keep that mental model, you will avoid the common traps that focus on direct, synchronous actions.
The Kubernetes API is the single entry point for all operations; you never interact with nodes or containers directly.
YAML manifests declare the desired state of your application; Kubernetes controllers work to make the actual state match.
A Pod is the smallest deployable unit and can contain one or more containers that share the same network and storage.
A Deployment manages a set of identical Pods and provides self-healing, scaling, and rolling updates.
A Service provides a stable network endpoint to a set of Pods, even as Pods are created and destroyed.
Namespace is a virtual cluster that isolates resources like Pods and Services from other teams or environments.
ConfigMap and Secret decouple configuration from container images, enabling portability across environments.
You must specify the correct apiVersion for each resource kind; Pod uses v1, Deployment uses apps/v1.
Labels and Selectors are how objects (like Deployments and Services) find and manage the correct Pods.
Secrets are only base64-encoded by default; they are not encrypted at rest unless you configure encryption.
Mistake
A Pod is the same as a container.
Correct
A Pod is a wrapper that can contain one or more containers. The containers inside a Pod share the same network namespace, storage volumes, and lifecycle. While many applications use one container per Pod, the Pod is the unit of scheduling, not the container.
Beginners hear the word 'container' constantly and assume that is the smallest unit. But Kubernetes abstracts containers inside Pods, which is confusing when first learning.
Mistake
You can directly change a Pod's container image after it is created by editing the YAML and reapplying it.
Correct
Many fields in a Pod spec are immutable after creation, including the image field. If you need to change the image, you must delete the Pod and create a new one (or use a Deployment, which handles this automatically).
People are used to editing configuration files and restarting a service. Kubernetes deliberately treats Pods as disposable and encourages using Deployments for updates.
Mistake
A Service makes an application accessible from the internet automatically.
Correct
By default, a Service of type ClusterIP is only reachable inside the cluster. To expose it externally, you need a different Service type (NodePort or LoadBalancer) or an Ingress object. The Ingress is often needed for HTTP/HTTPS traffic with host-based routing.
The word 'Service' sounds like it serves the outside world, but Kubernetes separates internal from external networking. This misunderstanding leads to wasted debugging time.
Mistake
A Deployment creates a single Pod.
Correct
A Deployment manages a ReplicaSet, which in turn manages a set of identical Pods. The number of Pods is defined by the replicas field. A Deployment can create one, many, or zero Pods. It is a controller, not a Pod itself.
Newcomers think of Deployment as a fancier Pod, when in reality it is a layer above Pods that provides self-healing, scaling, and update capabilities.
Mistake
Secrets are secure by default because they are stored in Kubernetes.
Correct
Secrets are only base64-encoded, not encrypted at rest by default. A user with access to etcd or the API can decode them. You must enable encryption at rest in the cluster configuration to truly secure them.
The word 'Secret' implies strong security. Beginners treat it as a password vault, but it is more of a configuration file that happens to be base64-encoded.
Mistake
When you run kubectl apply, the Pods exist immediately.
Correct
kubectl apply sends a request to the API server. The API server validates and stores the desired state in etcd. Then the scheduler and kubelet work asynchronously to create the Pod on a node. There is a delay, and the Pod goes through phases (Pending, Running, etc.).
People expect command-line tools to be synchronous. Kubernetes' eventual consistency model is unintuitive at first because the system is designed for reliability, not speed.
You've finished Kubernetes API and Core Objects. Continue through the KCNA study guide to build a complete picture of the exam.
Done with this chapter?