Home / devops-containers / Kubernetes and Cloud Native Associate (KCNA) / Cheat Sheet
Kubernetes and Cloud Native Associate (KCNA)

KCNA Cheat Sheet

KCNA Tests Which Kubernetes Component Does What — Not How to Run kubectl

KCNA is a 60-question, multiple-choice foundation exam. Nearly half of it is Kubernetes fundamentals, so knowing exactly which component, object or project owns a job beats hands-on command recall.

Check Your Readiness →
Among the harder certs
Avg: Not published by CNCF / The Linux Foundation
Pass: 750 / 1000
Most candidates understand Kubernetes and Cloud Native Associate (KCNA) concepts — and still fail. This exam tests how you apply knowledge under pressure.

KCNA Domain Map (November 2025 curriculum)

The current four-domain outline replaced the 2021 five-domain version, and observability now sits inside Cloud Native Architecture. Questions are short identification items: pick the component, object, project or standard that fits a one- or two-line scenario.

  1. 01
    Kubernetes Fundamentals (44%) — control plane vs. node components, core objects, scheduling, containers and the CRI
  2. 02
    Container Orchestration (28%) — networking, Services, storage, security basics, service mesh and troubleshooting
  3. 03
    Cloud Native Application Delivery (16%) — CI/CD, GitOps with Argo CD or Flux, packaging with Helm
  4. 04
    Cloud Native Architecture (12%) — autoscaling, serverless, observability, CNCF governance and open standards

Wrong instinct vs correct approach

A Pod keeps landing on a node that should only run GPU workloads
✕ Wrong instinct

Add a toleration to the GPU Pods so they are attracted there

✓ Correct approach

Taint the GPU node so ordinary Pods are repelled, then give GPU Pods a matching toleration plus node affinity or a nodeSelector. Tolerations only permit scheduling onto a tainted node; they never pull a Pod toward it.

A team wants every cluster change to come from a Git repository and drift to be corrected automatically
✕ Wrong instinct

Run kubectl apply from a CI pipeline after each merge

✓ Correct approach

This is GitOps: an in-cluster agent such as Argo CD or Flux pulls the desired state from Git and continuously reconciles the cluster. A push-based CI job applies once and does not detect or fix later drift.

Pods in the same namespace must stop talking to each other except the frontend-to-API path
✕ Wrong instinct

Put each workload in its own Service with no selector

✓ Correct approach

Apply a default-deny NetworkPolicy, then allow ingress to the API Pods from Pods labelled as frontend. NetworkPolicy only takes effect if the cluster's CNI plugin enforces it, such as Calico or Cilium.

An app must scale on demand and scale to zero when idle, without managing servers
✕ Wrong instinct

Configure a HorizontalPodAutoscaler with minReplicas set to zero

✓ Correct approach

Scale to zero is a serverless pattern, provided on Kubernetes by projects such as Knative or KEDA. The HPA scales on metrics between a minimum of one and a maximum; the Cluster Autoscaler adds or removes nodes, not Pods.

Know these cold

  • ▸ Only kube-apiserver talks to etcd; every client and component goes through the API server
  • ▸ Scheduler places Pods, kubelet runs them, controllers recreate them, kube-proxy routes Service traffic
  • ▸ ClusterIP is internal only; NodePort opens a port on every node; LoadBalancer adds a cloud LB
  • ▸ HPA scales Pods, VPA resizes requests, Cluster Autoscaler adds or removes nodes
  • ▸ Labels select objects; annotations store metadata and can never be used in selectors
  • ▸ A PersistentVolumeClaim requests storage; a StorageClass provisions the PersistentVolume dynamically
  • ▸ Secrets are base64-encoded, not encrypted, unless encryption at rest is enabled for etcd
  • ▸ Pin images by digest; tags such as latest can be moved to a different image
  • ▸ Observability pillars — etrics with Prometheus, logs, traces; OpenTelemetry standardises collection
  • ▸ CNCF maturity levels run sandbox, incubating, graduated; Kubernetes, Prometheus and Envoy are graduated

Can you answer these without checking your notes?

In this scenario: "A Pod keeps landing on a node that should only run GPU workloads" — what should you do first?
Taint the GPU node so ordinary Pods are repelled, then give GPU Pods a matching toleration plus node affinity or a nodeSelector. Tolerations only permit scheduling onto a tainted node; they never pull a Pod toward it.
In this scenario: "A team wants every cluster change to come from a Git repository and drift to be corrected automatically" — what should you do first?
This is GitOps: an in-cluster agent such as Argo CD or Flux pulls the desired state from Git and continuously reconciles the cluster. A push-based CI job applies once and does not detect or fix later drift.
In this scenario: "Pods in the same namespace must stop talking to each other except the frontend-to-API path" — what should you do first?
Apply a default-deny NetworkPolicy, then allow ingress to the API Pods from Pods labelled as frontend. NetworkPolicy only takes effect if the cluster's CNI plugin enforces it, such as Calico or Cilium.

Common Exam Mistakes — What candidates get wrong

Studying from the old five-domain KCNA outline

CNCF published a new curriculum on 24 November 2025: 44/28/16/12, with Cloud Native Observability folded into Architecture. Courses still showing a separate 8% observability domain underweight Container Orchestration, which rose to 28%.

Thinking the scheduler starts containers or recreates lost Pods

kube-scheduler only picks a node by filtering and scoring. The kubelet starts containers through the CRI, and controllers in kube-controller-manager, such as the ReplicaSet controller, recreate missing Pods. Questions swap these three on purpose.

Using a Deployment where a StatefulSet or DaemonSet is required

Stable names (db-0, db-1) and one volume claim per replica point to a StatefulSet. One Pod on every node, including new ones, points to a DaemonSet. A Deployment fits stateless, interchangeable replicas only.

Mixing up requests, limits and what happens when they are exceeded

Requests drive scheduling; limits cap usage at runtime. A container over its memory limit is OOMKilled, while one over its CPU limit is throttled, not killed. Limits never influence which node the scheduler picks.

Treating Docker Engine as a required Kubernetes runtime

The kubelet talks to any CRI-compliant runtime, usually containerd or CRI-O. Images built with Docker still run because they follow the OCI image format; the dockershim adapter was removed in Kubernetes 1.24.

Resources to help you pass Kubernetes and Cloud Native Associate on your first attempt

KCNA rewards knowing exactly which component owns each job. Check whether yours are sorted.