KCNA

KCNA Study Guide: Your First Kubernetes Certification

A practical KCNA study guide covering all five exam domains, what to study, what to skip, and whether the KCNA is the right starting point for you.

Table of Contents

The KCNA is the entry-level Kubernetes certification. It is a 90-minute, multiple-choice exam that tests your understanding of Kubernetes concepts and the cloud native ecosystem. You need a 75% to pass. No terminal, no live cluster, no typing kubectl commands under pressure. Just 60 questions about how Kubernetes works and what the surrounding tools and patterns are for.

That makes it the easiest of the five Kubernetes certifications to pass. It also makes it the weakest on a resume. This guide covers how to prepare for the KCNA efficiently, but it also helps you decide whether the KCNA is the right certification for you or whether you should skip it and go straight to the CKA.

Should You Take the KCNA or Skip to the CKA?

Before spending $250 and 4 to 6 weeks studying, answer this honestly.

Take the KCNA if:

  • You have never used Kubernetes and want a low-pressure introduction
  • You are in a non-technical role (manager, product owner, sales engineer, pre-sales) and need to understand K8s concepts without operating clusters
  • You are a student building credentials before entering the job market
  • You want a confidence boost before tackling the CKA
  • You are going for the Kubestronaut title and need all five certs anyway

Skip to the CKA if:

  • You are comfortable with Linux and containers
  • You have used Docker or deployed anything to Kubernetes, even once
  • You learn better by doing than by reading
  • You want the certification that actually moves the needle on your resume
  • You are targeting DevOps, SRE, or platform engineering roles

The reason this matters: the CKA covers everything the KCNA covers and more. Every concept on the KCNA exam (Pods, Deployments, Services, control plane architecture) appears on the CKA at a deeper, hands-on level. Spending $250 on the KCNA and then $445 on the CKA means paying $695 for ground you could have covered in a single $445 exam.

The KCNA is not a prerequisite for the CKA. There is no formal dependency. The only Kubernetes cert with a prerequisite is the CKS, which requires a valid CKA.

If you are still reading and the KCNA feels like the right starting point for you, here is how to pass it.

Register for the KCNA

$250 with one free retake included. A 90-minute, multiple-choice exam. No hands-on component.

Register for the KCNA Exam

KCNA Exam Domains and Weights

Five domains. Kubernetes Fundamentals is nearly half the exam.

DomainWeightWhat It Covers
Kubernetes Fundamentals46%Pods, Deployments, Services, architecture, API, kubectl
Container Orchestration22%Container basics, orchestration concepts, runtime, networking
Cloud Native Architecture16%Microservices, 12-factor apps, autoscaling, serverless, roles
Cloud Native Observability8%Monitoring, logging, tracing, Prometheus, cost management
Cloud Native Application Delivery8%GitOps, CI/CD, Helm, service mesh, messaging

Kubernetes Fundamentals at 46% means almost half your questions are about core Kubernetes. If you know Pods, Deployments, Services, and how the control plane works, you are nearly halfway to passing before you study anything else.

The two 8% domains (Observability and Application Delivery) are the lowest weight. Do not skip them, but do not spend weeks on them either. A couple of hours each is enough.

The Study Plan

The KCNA is a conceptual exam. You need to understand what things are and why they exist, not how to configure them from a terminal. That changes the study approach compared to the CKA or CKAD.

Weeks 1 to 2: Kubernetes Fundamentals (46%)

This is your highest priority. Almost half the exam. Get this right and the rest is manageable.

Cluster architecture:

You need to explain what each control plane component does.

  • API Server (kube-apiserver): The front door to the cluster. Every request (from kubectl, from other components, from the kubelet) goes through the API server. It validates and processes API requests.
  • etcd: The database. Stores all cluster state. Key-value store. If etcd dies, the cluster loses its memory.
  • Scheduler (kube-scheduler): Watches for Pods that have no assigned node and picks the best node for them based on resource requirements, taints, affinities, and other constraints.
  • Controller Manager (kube-controller-manager): Runs control loops that watch the cluster state and make changes to move toward the desired state. The Deployment controller, ReplicaSet controller, and Node controller all live here.

And the node components:

  • kubelet: An agent on each node that makes sure containers described in PodSpecs are running and healthy.
  • kube-proxy: Manages network rules on each node so that Pods can communicate with each other and with Services.
  • Container Runtime: The software that actually runs containers. containerd is the default in modern Kubernetes. Docker as a runtime was removed in Kubernetes 1.24 (but Docker images still work).

Core objects:

You do not need to write YAML for the KCNA. You need to know what each object is and when you use it.

  • Pod: The smallest deployable unit. One or more containers that share networking and storage. Pods are ephemeral. They can be killed and replaced at any time.
  • Deployment: Manages a set of identical Pods. Handles scaling, rolling updates, and rollbacks. This is what you use for stateless applications.
  • ReplicaSet: Ensures a specific number of Pod replicas are running. Deployments manage ReplicaSets automatically. You rarely create ReplicaSets directly.
  • StatefulSet: Like a Deployment, but for stateful applications. Provides stable network identities and persistent storage per Pod. Used for databases, message queues, and similar workloads.
  • DaemonSet: Ensures one copy of a Pod runs on every node (or a subset). Used for monitoring agents, log collectors, and node-level services.
  • Service: An abstract way to expose Pods. Four types:
    • ClusterIP: Internal only (default)
    • NodePort: Exposed on each node's IP at a static port
    • LoadBalancer: Exposed via a cloud load balancer
    • ExternalName: Maps to a DNS name
  • Ingress: Manages external HTTP access to Services. Routes traffic based on hostnames and paths.
  • ConfigMap: Stores non-sensitive configuration data as key-value pairs.
  • Secret: Stores sensitive data (passwords, tokens, keys). Base64-encoded by default, not encrypted unless you configure encryption at rest.
  • Namespace: A virtual cluster within a cluster. Used to isolate resources between teams or environments.
  • PersistentVolume (PV) and PersistentVolumeClaim (PVC): PVs represent storage resources. PVCs are requests for storage. Pods reference PVCs, which bind to PVs.

kubectl basics:

The KCNA does not test kubectl commands directly (it is multiple choice), but questions will reference kubectl operations and you need to understand what they do.

  • kubectl get: List resources
  • kubectl describe: Show detailed info about a resource
  • kubectl create: Create a resource
  • kubectl apply: Apply a configuration (declarative)
  • kubectl delete: Delete a resource
  • kubectl logs: View container logs
  • kubectl exec: Run a command in a container

The Kubernetes API:

Know that Kubernetes is API-driven. Every interaction goes through the REST API exposed by the API server. Resources have API groups and versions (like apps/v1 for Deployments, v1 for Pods). API versions go through stages: alpha, beta, stable.

Weeks 2 to 3: Container Orchestration (22%)

Container basics:

You need to understand containers at a conceptual level.

  • A container is an isolated process running on a host. It packages an application with its dependencies.
  • Containers use Linux kernel features: namespaces (process isolation), cgroups (resource limits), and union filesystems (layered images).
  • Container images are built from a Dockerfile (or similar) and stored in a container registry.
  • Images are composed of layers. Each instruction in a Dockerfile creates a layer. Layers are cached and shared between images.
  • The OCI (Open Container Initiative) defines the standards for container image formats and runtimes.

Container runtimes:

  • containerd: The default container runtime for Kubernetes. Manages the container lifecycle.
  • CRI-O: An alternative runtime designed specifically for Kubernetes.
  • CRI (Container Runtime Interface): The API that kubelet uses to communicate with any container runtime.
  • Docker is not a Kubernetes runtime (since K8s 1.24). But Docker-built images work fine because they follow the OCI standard.

Why orchestration?

The KCNA will ask why container orchestration exists. The answer: running containers on a single machine is easy. Running them across hundreds of machines, handling failures, scaling up and down, managing networking between them, and doing rolling updates without downtime requires an orchestrator. That is what Kubernetes does.

Networking concepts:

  • Every Pod gets its own IP address.
  • Pods on different nodes can communicate directly (flat network).
  • Services provide stable endpoints for sets of Pods.
  • CNI (Container Network Interface) plugins implement the network layer (Calico, Cilium, Flannel).
  • DNS (CoreDNS) provides name resolution inside the cluster.

Week 3 to 4: Cloud Native Architecture (16%)

This domain is about the broader principles, not Kubernetes specifics.

Cloud native definition:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. (That is close to the CNCF's official definition. Know it.)

Microservices:

  • An architectural pattern where an application is a collection of small, independent services.
  • Each service runs its own process and communicates over HTTP/gRPC.
  • Benefits: independent deployment, scaling, and development.
  • Tradeoffs: network complexity, distributed debugging, data consistency challenges.
  • Contrast with monolith: one deployable unit, simpler to develop initially, harder to scale independently.

The 12-Factor App:

You do not need to memorize all 12 factors, but know the key ones:

  • Store configuration in environment variables (not in code)
  • Treat backing services as attached resources
  • Execute the app as stateless processes
  • Export services via port binding
  • Scale out via process model
  • Keep development, staging, and production as similar as possible

Autoscaling:

  • Horizontal Pod Autoscaler (HPA): Scales the number of Pods based on CPU, memory, or custom metrics.
  • Vertical Pod Autoscaler (VPA): Adjusts CPU and memory requests for individual Pods.
  • Cluster Autoscaler: Adds or removes nodes based on pending Pods and resource utilization.

Serverless and Knative:

Serverless on Kubernetes means running workloads that scale to zero when not in use. Knative is the main framework for this. Know that it exists and what problem it solves (scaling to zero, event-driven workloads), not how to configure it.

Roles in cloud native:

The KCNA may ask about roles: DevOps engineers, SREs, platform engineers, and how their responsibilities relate to Kubernetes. Know the basic distinction. DevOps focuses on CI/CD and automation. SRE focuses on reliability and incident management. Platform engineering focuses on building internal platforms that other developers use.

Week 4: Cloud Native Observability (8%)

Small domain, but do not skip it.

The three pillars of observability:

  1. Metrics: Numerical data points over time. CPU usage, request count, error rate. Prometheus is the standard metrics tool in the Kubernetes ecosystem.
  2. Logs: Timestamped text records from applications and system components. Fluentd and Fluent Bit collect them. Loki stores them. Logs answer "what happened."
  3. Traces: Records of requests flowing through distributed systems. Jaeger and Zipkin are tracing tools. OpenTelemetry is the vendor-neutral framework for collecting all three signals. Traces answer "where did the request go and how long did each step take."

Prometheus and Grafana:

Prometheus scrapes metrics endpoints and stores time-series data. Grafana visualizes it in dashboards. This combination is the de facto monitoring standard for Kubernetes. Know what each tool does and how they relate.

Cost management:

Cloud native observability includes understanding resource consumption. Monitoring helps identify over-provisioned workloads (wasting money) and under-provisioned ones (risking outages).

Week 4 to 5: Cloud Native Application Delivery (8%)

Another small domain.

GitOps:

An operational model where the desired state of infrastructure and applications is stored in a Git repository. Changes are made through pull requests. A GitOps tool (Argo CD, Flux) watches the repo and applies changes to the cluster automatically.

Key principles:

  • Git is the single source of truth
  • Changes are declarative
  • Changes are applied automatically
  • Drift is detected and corrected

CI/CD:

  • Continuous Integration: Automatically building and testing code on every commit.
  • Continuous Delivery: Automatically deploying tested code to production (or staging).
  • Kubernetes-native CI/CD tools: Tekton, Argo Workflows, GitHub Actions (not K8s-native but commonly used).

Helm:

A package manager for Kubernetes. Charts are packages of pre-configured Kubernetes resources. Helm lets you install, upgrade, and rollback application deployments as a single unit. Know what Helm is and what problem it solves (templating and managing complex deployments).

Service mesh:

A dedicated infrastructure layer for handling service-to-service communication. Adds observability, traffic management, and security (mTLS) without modifying application code. Istio and Linkerd are the main options. Know the concept and why it exists, not the configuration details.

Feeling ready?

The KCNA is $250 with a free retake. 90 minutes, 60 questions, multiple choice. Pass at 75%.

Register for the KCNA Exam

Exam Day Tips

It is multiple choice, not hands-on

This changes everything about how you prepare compared to CKA, CKAD, or CKS. You do not need muscle memory with kubectl. You do not need to write YAML under time pressure. You need to recognize correct answers and eliminate wrong ones.

Time management is generous

90 minutes for 60 questions is 90 seconds per question. That is comfortable for most people. If a question stumps you, flag it and move on. You will have time to come back.

Watch for "most correct" answers

Multiple-choice exams often have two answers that seem right. One is more right than the other. Read all four options before choosing. The KCNA does this frequently with questions about which component is responsible for something. The scheduler and the controller manager both "manage" Pods in different senses. The question is testing whether you know which one does what.

Concept precision matters

The KCNA tests whether you understand what things are, not what they do in practice. The difference between a Deployment and a StatefulSet. The difference between a ConfigMap and a Secret. The difference between Horizontal Pod Autoscaler and Cluster Autoscaler. These distinctions matter on the exam.

Do not over-study

The KCNA has a clear scope. It does not go deep on any topic. If you find yourself reading about how CNI plugins implement iptables rules or how the scheduler's scoring algorithm works, you have gone too far. That is CKA territory. The KCNA wants you to know that CNI plugins exist and what they do at a high level.

Best KCNA Study Resources

Free resources (these are enough to pass)

CNCF Kubernetes and Cloud Native Associate course by Andrew Brown on freeCodeCamp (YouTube). A full video course covering the entire KCNA curriculum. Free. This single resource has helped thousands of people pass the KCNA.

Kubernetes official documentation (kubernetes.io/docs). The Concepts section covers everything in the Kubernetes Fundamentals domain. Read the top-level explanations, not the detailed configuration guides.

CNCF Landscape (landscape.cncf.io). A visual map of the entire cloud native ecosystem. Browsing it helps you understand the categories (orchestration, service mesh, observability, etc.) and which tools belong where.

Paid resources

Structured online courses with quizzes covering every domain are available from various training providers. Good if you want a guided curriculum rather than piecing together free resources.

Choose courses that have been updated recently to reflect current Kubernetes versions and CNCF curriculum changes.

Practice tests

The KCNA does not include practice sessions (that is only for the professional certs). But practice question sets are available:

  • Free practice questions exist on GitHub and community blogs
  • Many training providers offer practice tests as part of their courses

Do at least two full practice exams before sitting for the real one. If you score above 80% consistently, you are ready.

Study Timeline

BackgroundStudy Time
Already work with Kubernetes1 to 2 weeks (review only)
Familiar with containers, some K8s exposure3 to 4 weeks
IT background, new to Kubernetes4 to 6 weeks
Complete beginner6 to 8 weeks
Already passed CKA, CKAD, or CKSA weekend of review

If you have already passed any professional Kubernetes certification, the KCNA is a strict subset of what you know. A quick review of the cloud native ecosystem topics (GitOps, service mesh, observability tools) is all you need. Everything else is material you have already studied in depth.

What Comes After the KCNA

The KCNA is a starting point. Here are the natural next steps.

CKA (Certified Kubernetes Administrator): The most common path after the KCNA. The CKA takes everything you learned conceptually and tests it hands-on. Budget 6 to 10 weeks of study, with the first couple of weeks feeling familiar thanks to your KCNA preparation. Full details: CKA study guide

CKAD (Certified Kubernetes Application Developer): If you are a developer, the CKAD is an alternative next step. It focuses on application deployment rather than cluster administration. Full details: CKAD study guide

KCSA (Kubernetes and Cloud Native Security Associate): Another associate-level exam, focused on security concepts. If you are going for the Kubestronaut title, you need both KCNA and KCSA. The KCSA is a similar difficulty level.

For the full sequence of all five certifications and the optimal order, see the Kubernetes certification path guide.

For whether investing in Kubernetes certifications makes sense for your career and salary, read Is Kubernetes Certification Worth It?

Ready for the next level?

The CKA is the hands-on certification that hiring managers look for. Your KCNA knowledge gives you a head start.

Register for the CKA Exam

FAQ

How hard is the KCNA exam?

The KCNA is the easiest of the five Kubernetes certifications, but it is not trivial. The 75% passing score means you can miss about 15 questions out of 60. The questions test conceptual understanding, not hands-on skills. If you study the five domains for 4 to 6 weeks, most people pass on the first attempt.

Is the KCNA worth it?

It depends on your situation. For complete beginners, managers, and people in non-technical roles, the KCNA provides a structured learning path and a validated credential. For engineers with any Kubernetes experience, the CKA is a better investment because it carries significantly more weight on a resume and teaches hands-on skills. The KCNA costs $250. The CKA costs $445 but delivers far more career value.

Does the KCNA require hands-on experience?

No. The KCNA is entirely multiple choice. You do not need to operate a Kubernetes cluster or use kubectl to pass. That said, setting up a local cluster with minikube or kind and exploring the concepts hands-on will deepen your understanding and make the material stick better.

How many questions are on the KCNA?

60 multiple-choice questions in 90 minutes. That gives you 90 seconds per question, which is generous. Most people finish with time to spare and can review flagged questions.

Is the KCNA a prerequisite for the CKA?

No. No certification is required before taking the CKA. You can take the CKA as your first and only Kubernetes certification. The KCNA and CKA are completely independent. The only prerequisite in the Kubernetes certification system is the CKS, which requires a valid CKA.

How long is the KCNA valid?

Three years. That is longer than the professional certifications (CKA, CKAD, CKS are valid for 2 years). After 3 years, you need to pass the current version to recertify.

Should I get the KCNA before the CKA?

Only if you have no Kubernetes experience and want a structured, low-pressure entry point. If you have basic Linux skills and any container experience, skip the KCNA and go directly to the CKA. You will save $250 and learn everything the KCNA covers at a deeper level during CKA preparation.

Can the KCNA help me get a job?

The KCNA is a positive signal, but a weak one compared to the professional certifications. Most job postings that mention Kubernetes certifications ask for CKA or CKAD, not KCNA. The KCNA is most useful for career changers who need any credential to get past resume screens, and for non-technical roles where conceptual understanding is sufficient.