CKA Exam Domains Breakdown: Weightage and Focus Areas for 2026

The CKA exam consists of six distinct domains, each testing different aspects of Kubernetes cluster administration. Understanding the weightage and focus areas of each domain is crucial for allocating study time effectively. This comprehensive breakdown explores each domain in detail, explaining the most important topics and providing study recommendations.

CKA Domain Overview

Domain	Weightage	Key Focus	Difficulty
Cluster Architecture, Installation & Configuration	25%	Cluster setup, RBAC, upgrades, etcd	Moderate-Hard
Workloads & Scheduling	12%	Pods, Deployments, scheduling, affinity	Easy-Moderate
Services & Networking	22%	Services, Ingress, Gateway API, NetworkPolicies	Hard
Storage	10%	PV, PVC, StorageClass, persistence	Easy-Moderate
Troubleshooting	31%	Debugging, logging, cluster issues	Very Hard

Domain 1: Cluster Architecture, Installation & Configuration (25%)

This domain forms the foundation for understanding how Kubernetes clusters work. It’s the second-largest domain and requires both theoretical knowledge and practical skills.

Key Topics

1. Understanding Kubernetes Architecture (30% of domain)

Core Components:

Control Plane components: API server, controller manager, scheduler, etcd
Worker node components: kubelet, kube-proxy, container runtime
Add-on components: DNS, dashboard, metrics server

What You Should Know:

Each control plane component’s role and interaction
How requests flow through the API server
The relationship between components

Practice Tasks:

# Understand cluster topology
kubectl cluster-info
kubectl get nodes
kubectl get componentstatuses

# Check control plane pods
kubectl get pods -n kube-system -o wide

2. kubeadm Cluster Setup (25% of domain)

Critical Skills:

Create a cluster from scratch with kubeadm
Bootstrap control plane: kubeadm init
Join worker nodes: kubeadm join
Configure network plugins
Set up kubeconfig for access

Common Questions:

Initializing a control plane node
Adding worker nodes with proper tokens
Recovering from failed initialization
Configuring different network plugins

Practice Setup:

# Practice full cluster creation 2-3 times:
# 1. Create VMs or cloud instances
# 2. Run kubeadm init
# 3. Install CNI plugin
# 4. Join worker nodes
# 5. Verify cluster health

3. RBAC Configuration (25% of domain)

Essential Knowledge:

Users vs. service accounts
Roles vs. ClusterRoles
RoleBindings vs. ClusterRoleBindings
Permission verification with kubectl auth can-i
API groups and resource verbs

Common Scenarios:

Creating users for external authentication
Limiting service account permissions
Implementing namespace isolation
Delegating permissions to teams

Practice Topics:

# Create 10+ RBAC configurations:
k create role developer --verb=get,list --resource=pods
k create rolebinding dev-binding --clusterrole=view --user=dev-user
k auth can-i get pods --as=dev-user

4. Cluster Upgrades (10% of domain)

Upgrade Process:

Understanding upgrade paths and prerequisites
Upgrading control plane components
Upgrading worker nodes safely
Managing API deprecations
Testing upgrades in non-prod environments

Focus Areas:

kubeadm upgrade process
Draining nodes gracefully
Verifying cluster health after upgrade
Handling certificate expiration

Practice:

# Practice upgrading in a lab environment:
# 1. Start with 1.28, upgrade to 1.29
# 2. Verify components at each stage
# 3. Practice rollback procedures
# 4. Understand breaking changes

5. etcd Management (10% of domain)

Critical Tasks:

Backing up etcd data
Restoring from backups
Understanding etcd structure
Recognizing etcd issues
Cluster recovery procedures

Practice Commands:

# Backup and restore etcd
etcdctl snapshot save backup.db
etcdctl snapshot restore backup.db --data-dir=/var/lib/etcd.restored

# Monitor etcd health
etcdctl member list
etcdctl endpoint status

Study Recommendations

Time Allocation: 15-20 hours

Architecture understanding: 2 hours
kubeadm setup practice: 8 hours (2-3 full setups)
RBAC exercises: 5 hours
Upgrade procedures: 3 hours
etcd operations: 2 hours

Practice Priority:

Complete kubeadm cluster creation 2-3 times end-to-end
Create 15+ different RBAC configurations from scratch
Practice etcd backup and restore on your lab cluster
Simulate cluster upgrade process
Test RBAC with kubectl auth can-i

Domain 2: Workloads & Scheduling (12%)

This domain tests your ability to deploy and manage application workloads. It’s the most straightforward domain but still requires hands-on practice.

Key Topics

1. Pod Creation and Management (25% of domain)

Essential Skills:

Creating pods imperatively and declaratively
Understanding pod lifecycle
Managing multi-container pods
Implementing initContainers
Using sidecar containers

Important Patterns:

# Init container pattern (runs first)
initContainers:
- name: init-db
  image: busybox
  command: ['sh', '-c', 'until curl http://db-init:8080; do sleep 1; done']

# Sidecar pattern (runs alongside main container)
containers:
- name: main
  image: myapp:latest
- name: logging-sidecar
  image: logging-agent:latest

2. Deployments (25% of domain)

Core Knowledge:

Creating deployments with kubectl create deployment
Understanding ReplicaSets and pod replicas
Rolling updates and rollback
Update strategy: RollingUpdate vs. Recreate
Deployment status and conditions

Common Tasks:

k create deployment web --image=nginx --replicas=3
k set image deployment/web nginx=nginx:latest --record
k rollout status deployment/web
k rollout undo deployment/web --to-revision=1
k patch deployment web -p '{"spec":{"replicas":5}}'

3. StatefulSets (20% of domain)

Critical Concepts:

Ordered pod naming and creation
Persistent identity and stable hostnames
Headless services for StatefulSets
Persistent storage requirements
When to use StatefulSets vs. Deployments

When to Use:

Databases (MySQL, PostgreSQL)
Message queues (Kafka, RabbitMQ)
Distributed systems requiring stable identities
Applications with persistent state

4. DaemonSets (10% of domain)

Purpose and Use:

Ensuring one pod per node
Node-specific monitoring or logging
System-level tasks across cluster
Common use cases: fluentd, prometheus node-exporter

5. Scheduling and Affinity (20% of domain)

Important Topics:

Node selectors for simple node targeting
Node affinity for complex selection rules
Pod affinity for colocating related pods
Pod anti-affinity for preventing colocation
Taints and tolerations for node reservation

Examples:

# Node affinity: target large nodes
nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchExpressions:
      - key: node-size
        operator: In
        values: ["large"]

# Pod affinity: colocate with frontend
podAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchLabels:
          app: frontend
      topologyKey: kubernetes.io/hostname

Study Recommendations

Time Allocation: 8-10 hours

Pod creation: 2 hours
Deployments: 3 hours
StatefulSets: 2 hours
Scheduling and affinity: 2 hours

Practice Priority:

Create 20+ pods imperatively and declaratively
Deploy 10+ applications as Deployments
Practice rolling updates and rollbacks
Set up StatefulSets with persistent storage
Implement complex affinity rules

Domain 3: Services & Networking (22%)

This domain tests your understanding of how applications communicate. It’s one of the harder domains due to networking complexity and the inclusion of the newer Gateway API.

Key Topics

1. Services (25% of domain)

Service Types:

ClusterIP: Internal-only service (default)
NodePort: Exposed on every node’s port
LoadBalancer: Cloud provider load balancer
ExternalName: Maps to external DNS name

Critical Concepts:

# Service discovery via DNS
service-name.namespace.svc.cluster.local
service-name.namespace.svc  # shorter form

Practice:

# Create all service types
k expose deployment web --type=ClusterIP --port=80
k expose deployment web --type=NodePort --port=80
k expose deployment web --type=LoadBalancer --port=80

2. Ingress (25% of domain)

What Ingress Does:

Routes HTTP/HTTPS traffic to services
Hostname-based routing
Path-based routing
TLS termination
Requires ingress controller (nginx, haproxy, etc.)

Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /static
        pathType: Prefix
        backend:
          service:
            name: static-service
            port:
              number: 80

3. Gateway API (20% of domain) - NEW in 2026

Gateway API is the modern alternative to Ingress:

Three Key Resources:

GatewayClass: Defines gateway implementation
Gateway: Listener configuration and pod selection
HTTPRoute: Routing rules (like Ingress rules but more flexible)

Key Differences from Ingress:

More flexible routing options
Role-based separation (different teams manage different resources)
Better support for complex scenarios
Still in beta but recommended for new deployments

Example:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: main-gateway
    kind: Gateway
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    backendRefs:
    - name: api-v1-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /v2
    backendRefs:
    - name: api-v2-service
      port: 8080

4. NetworkPolicies (20% of domain)

Purpose:

Restrict traffic between pods
Default deny, allow specific traffic
Pod-level firewall rules

Critical Concept:

# Default deny all ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

# Allow specific traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

5. DNS and Service Discovery (10% of domain)

How It Works:

CoreDNS provides cluster DNS
Service names resolve to ClusterIP
Pod names resolve in DNS (with hostname.namespace pattern)
External DNS can be configured
Headless services return pod IPs directly

Study Recommendations

Time Allocation: 15-18 hours

Services: 3 hours
Ingress: 3 hours
Gateway API: 4 hours
NetworkPolicies: 3 hours
DNS and connectivity: 2 hours

Practice Priority:

Create all three service types and test connectivity
Set up Ingress with multiple hosts and paths
Implement Gateway API resources
Create 10+ NetworkPolicy scenarios (deny all, allow specific, etc.)
Test cross-namespace networking
Troubleshoot DNS resolution

Domain 4: Storage (10%)

Storage management is critical for stateful applications. This domain is smaller than others but important to master.

Key Topics

1. Persistent Volumes (PV) (25% of domain)

Essential Concepts:

Cluster-wide storage resource
Different volume types: hostPath, local, nfs, cloud-specific
Access modes: ReadWriteOnce, ReadOnlyMany, ReadWriteMany
Reclaim policy: Retain, Delete, Recycle

Example:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: nfs-server.example.com
    path: "/exports/data"

2. Persistent Volume Claims (PVC) (25% of domain)

Purpose:

Namespace-scoped request for storage
Abstracts underlying storage details
Bind to matching PV based on specifications

Example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: standard
  resources:
    requests:
      storage: 5Gi

3. StorageClass (25% of domain)

Dynamic Provisioning:

Automatically creates PVs when PVC requested
Reduces manual PV management
Provider-specific parameters

Example:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
  replication-type: regional-pd

4. Using Storage in Pods (25% of domain)

Volume Mounting:

Mount PVC in containers
Mount types: emptyDir, configMap, secret, pvc
Mount permissions and access modes

Example:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-storage
spec:
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: my-claim

Study Recommendations

Time Allocation: 6-8 hours

PV/PVC concepts: 2 hours
StorageClass setup: 2 hours
Practical storage mounting: 2 hours
Troubleshooting storage: 1 hour

Practice Priority:

Create 10+ PV/PVC pairs with different configurations
Set up dynamic provisioning with StorageClass
Mount PVCs in Deployments and StatefulSets
Practice storage access modes
Troubleshoot PVC binding failures

Domain 5: Troubleshooting (31%)

Troubleshooting is the largest domain and the most challenging. It tests practical diagnostic and problem-solving skills.

Key Topics

1. Application Troubleshooting (30% of domain)

Pod Issues:

Pods stuck in Pending, CrashLoopBackOff, ImagePullBackOff
Container exit codes and meanings
Log analysis techniques
Debugging with kubectl exec and kubectl debug

Systematic Approach:

# 1. Check pod status
kubectl get pods
kubectl describe pod <pod-name>

# 2. Check logs
kubectl logs <pod-name>
kubectl logs <pod-name> --previous  # for crashed containers

# 3. Debug interactively
kubectl exec -it <pod-name> -- /bin/bash

# 4. Check resource usage
kubectl top pod <pod-name>

2. Cluster Component Troubleshooting (25% of domain)

Control Plane Issues:

API server down or unresponsive
Controller manager failures
Scheduler issues
etcd problems

Diagnostic Commands:

kubectl get componentstatuses
kubectl get pods -n kube-system
kubectl logs -n kube-system -l component=kubelet

3. Network Troubleshooting (20% of domain)

Common Issues:

Pods cannot communicate
Services unreachable
DNS resolution failures
Network policies blocking traffic

Troubleshooting Approach:

# Test DNS
kubectl run -it debug --image=busybox -- nslookup service-name

# Test connectivity
kubectl run -it debug --image=curlimages/curl -- curl http://service:port

# Check endpoints
kubectl get endpoints service-name
kubectl get networkpolicy

# Verify service selectors
kubectl get svc service-name -o yaml | grep -A5 selector
kubectl get pods --show-labels

4. Node and kubelet Issues (15% of domain)

Node Problems:

Node NotReady status
kubelet crash or service stopped
Node resource exhaustion
Certificate expiration

Debugging:

kubectl get nodes
kubectl describe node <node-name>
kubectl logs -n kube-system kubelet  # on the node itself

# SSH to node and check kubelet
systemctl status kubelet
journalctl -u kubelet -n 50

5. Persistent Storage Issues (10% of domain)

Storage Failures:

PVC pending (binding failed)
Mount failures
Disk space issues
Permission problems

Diagnosis:

kubectl get pvc,pv
kubectl describe pvc <pvc-name>
kubectl get events

Study Recommendations

Time Allocation: 20-25 hours

Application debugging: 5 hours
Component troubleshooting: 5 hours
Network troubleshooting: 6 hours
Node troubleshooting: 3 hours
Storage troubleshooting: 2 hours

Practice Priority:

Intentionally break your lab cluster 3-4 times per week
Create troubleshooting scenarios and fix them
Build systematic diagnostic workflows
Learn log file locations and formats
Practice identifying root causes under time pressure

Troubleshooting Workflow Template

1. What is broken? (Status and symptoms)
   - kubectl get <resource>
   - kubectl describe <resource>

2. Where is the problem? (Component or layer)
   - Pod level?
   - Service level?
   - Node level?
   - Cluster level?

3. What caused it? (Root cause analysis)
   - Check logs: kubectl logs
   - Check events: kubectl get events
   - Check configuration: kubectl get -o yaml
   - Check resource usage: kubectl top

4. How do I fix it? (Solution implementation)
   - Correct configuration
   - Restart component
   - Add missing resource
   - Scale or reallocate

5. How do I verify? (Solution testing)
   - Rerun checks from step 1
   - Confirm expected behavior
   - Check for side effects

Study Priority by Weightage

Allocate your study time proportionally to exam weight:

Domain	Weightage	Study Hours
Troubleshooting	31%	20-25
Cluster Architecture	25%	15-20
Services & Networking	22%	15-18
Workloads & Scheduling	12%	8-10
Storage	10%	6-8
Total	100%	65-81

Integrated Study Strategy

Week 1-2: Foundations

All domains overview
Cluster Architecture and Workloads basics
Basic hands-on with minikube/kind

Week 3-4: Services and Storage

Service creation and routing
Storage concepts and practice
Networking fundamentals

Week 5-6: Advanced Topics

Gateway API deep dive
NetworkPolicies
Advanced scheduling with affinity

Week 7-8: Troubleshooting Focus

Intensive troubleshooting practice
Create and fix scenarios daily
Full mock exams under time pressure

Recommended Mock Exam Usage

Use Sailor.sh mock exams to assess domain-specific readiness:

Take domain-specific practice questions first
Then take full-length exams covering all domains
Use analytics to identify weakest domains
Focus additional study on domains scoring below 70%

Quick Reference: What to Know Per Domain

Cluster Architecture (25%)

kubeadm init, join
RBAC roles and bindings
etcd backup/restore
Cluster upgrade procedures

Workloads (12%)

Pod, Deployment, StatefulSet, DaemonSet creation
Rolling updates and rollbacks
Pod scheduling with affinity

Services & Networking (22%)

All service types
Ingress and Gateway API
NetworkPolicies
Service discovery

Storage (10%)

PV, PVC, StorageClass
Volume types and access modes
Dynamic provisioning

Troubleshooting (31%)

Logs analysis: kubectl logs
Pod debugging: kubectl describe, kubectl exec
Component status: kubectl get componentstatuses
Network debugging: DNS, connectivity
Node debugging: kubelet status

Ready to master each domain? Start with Sailor.sh practice questions organized by domain, then progress to full exams covering all topics.