Understanding the CKAD exam domains is essential for effective preparation. The exam tests five main domains, each with specific weightage that tells you where to focus your study effort. This comprehensive guide breaks down each domain with key topics, important commands, and practical examples.
CKAD Exam Domains Overview
| Domain | Weightage | Focus Area |
|---|---|---|
| Application Design and Build | 20% | Container fundamentals, Docker, image optimization |
| Application Deployment | 20% | Deployments, scaling, rolling updates |
| Application Observability and Maintenance | 15% | Logging, monitoring, debugging, probes |
| Application Environment, Config & Security | 25% | ConfigMaps, Secrets, RBAC, SecurityContext, policies |
| Services & Networking | 20% | Services, Ingress, networking, DNS |
The Application Environment, Config & Security domain is the largest at 25%, followed by the two 20% domains. This tells you where to allocate most of your study time.
Domain 1: Application Design and Build (20%)
Overview
This domain covers the fundamentals of containerization and building applications for Kubernetes. It tests your understanding of Docker, image creation, and container best practices.
Key Topics
1. Container Fundamentals
What You Need to Know:
- Container vs. Virtual Machine differences
- Container runtime concepts (Docker, containerd, CRI-O)
- OCI (Open Container Initiative) standards
- Image layers and how they work
- Container isolation and namespaces
Practical Understanding: Containers are isolated processes that share the kernel. Each layer in a Docker image adds filesystem changes. Understanding layers is crucial for optimization.
2. Docker Images
What You Need to Know:
- Creating Dockerfiles
- Build context and .dockerignore
- Image tagging and versioning
- Image registries (Docker Hub, private registries)
- Image pull policies in Kubernetes
Essential Dockerfile Concepts:
# Multi-stage build for optimization
FROM golang:1.21 as builder
WORKDIR /app
COPY . .
RUN go build -o myapp
# Final stage - much smaller
FROM alpine:latest
COPY --from=builder /app/myapp /myapp
ENTRYPOINT ["/myapp"]
Key Commands:
# Build an image
docker build -t myapp:v1 .
# Tag image for registry
docker tag myapp:v1 myregistry.com/myapp:v1
# Push to registry
docker push myregistry.com/myapp:v1
# View image layers
docker history myapp:v1
# Inspect image
docker inspect myapp:v1
3. Image Optimization
What You Need to Know:
- Creating small, efficient images
- Multi-stage builds
- Choosing minimal base images (alpine, distroless)
- Removing unnecessary dependencies
- Layer caching in builds
Optimization Techniques:
# Bad - large image, unnecessary packages
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y python3 pip curl git
COPY app.py /app.py
CMD ["python3", "/app.py"]
# Good - minimal, efficient image
FROM python:3.11-alpine
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py /app.py
CMD ["python3", "/app.py"]
4. Multi-Container Pod Patterns
Sidecar Pattern: A utility container that extends functionality of the main application.
apiVersion: v1
kind: Pod
metadata:
name: app-with-sidecar
spec:
containers:
- name: main-app
image: myapp:v1
ports:
- containerPort: 8080
volumeMounts:
- name: logs
mountPath: /var/logs
- name: log-processor
image: busybox:latest
args:
- /bin/sh
- -c
- tail -f /var/logs/app.log | some-processor
volumeMounts:
- name: logs
mountPath: /var/logs
volumes:
- name: logs
emptyDir: {}
Init Container Pattern: Runs to completion before main containers start.
apiVersion: v1
kind: Pod
metadata:
name: app-with-init
spec:
initContainers:
- name: init-db
image: postgres-client:latest
command:
- /bin/sh
- -c
- until pg_isready -h db-service; do echo waiting for db; sleep 2; done
containers:
- name: app
image: myapp:v1
Ambassador Pattern: A container that acts as a proxy or translator for the main container.
apiVersion: v1
kind: Pod
metadata:
name: app-with-ambassador
spec:
containers:
- name: app
image: myapp:v1
ports:
- containerPort: 8080
- name: ambassador
image: proxy:latest
ports:
- containerPort: 8001
env:
- name: TARGET_PORT
value: "8080"
Domain 1 Practice Questions
- Create a Dockerfile that builds a Node.js application and optimizes the image size
- Implement a sidecar container pattern for logging
- Create an init container that waits for a database to be ready
- Optimize a multi-layer Docker image using multi-stage builds
Domain 2: Application Deployment (20%)
Overview
This domain covers deploying and managing applications in Kubernetes using Deployments, managing replicas, and handling updates safely.
Key Topics
1. Deployments
What You Need to Know:
- Deployment structure and purpose
- ReplicaSets and role in Deployments
- Pod templates in Deployments
- Selectors and labels
- Creating and managing Deployments
Creating Deployments:
# Imperative creation
kubectl create deployment web --image=nginx:latest --replicas=3
# Check deployment status
kubectl get deployments
kubectl describe deployment web
kubectl get replicasets
# View deployment in YAML
kubectl get deployment web -o yaml
Deployment YAML:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:latest
ports:
- containerPort: 80
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
2. Scaling Deployments
What You Need to Know:
- Manual scaling
- Horizontal Pod Autoscaling (HPA)
- Resource requests and limits (needed for autoscaling)
- Scaling strategies and considerations
Scaling Commands:
# Manual scaling
kubectl scale deployment web --replicas=5
# Check scaling status
kubectl get deployment web
kubectl get pods
# Autoscaling (requires metrics server)
kubectl autoscale deployment web --min=2 --max=10 --cpu-percent=80
# View autoscaling status
kubectl get hpa
HPA Configuration:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 80
3. Rolling Updates and Rollback
What You Need to Know:
- Rolling update strategy (default)
- Recreate strategy
- Update procedures
- Rollback commands
- Checking rollout history
Rolling Update Process:
# Update image
kubectl set image deployment/web web=nginx:1.21
# Watch rollout progress
kubectl rollout status deployment/web
# Check history
kubectl rollout history deployment/web
# Rollback to previous version
kubectl rollout undo deployment/web
# Rollback to specific revision
kubectl rollout undo deployment/web --to-revision=2
Deployment Update Strategy:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # One extra pod during update
maxUnavailable: 0 # Zero pods unavailable during update
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:latest
4. Deployment Patterns
Blue-Green Deployment Pattern:
# Blue deployment (current)
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-blue
spec:
replicas: 3
selector:
matchLabels:
app: web
version: blue
template:
metadata:
labels:
app: web
version: blue
spec:
containers:
- name: web
image: nginx:1.20
---
# Green deployment (new)
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-green
spec:
replicas: 3
selector:
matchLabels:
app: web
version: green
template:
metadata:
labels:
app: web
version: green
spec:
containers:
- name: web
image: nginx:1.21
---
# Service points to blue initially, switch to green after testing
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
version: blue # Change to "green" to switch
ports:
- port: 80
Domain 2 Practice Questions
- Create a Deployment with 5 replicas and update the image version
- Implement autoscaling with minimum 2 and maximum 10 replicas
- Perform a rolling update and rollback if needed
- Configure deployment strategy with maxSurge and maxUnavailable
Domain 3: Application Observability and Maintenance (15%)
Overview
This domain covers monitoring, debugging, and maintaining applications. You need to understand logging, probes, and troubleshooting.
Key Topics
1. Pod Logging
What You Need to Know:
- Accessing pod logs
- Container-specific logs in multi-container pods
- Previous logs for crashed containers
- Log streaming and following
Logging Commands:
# View pod logs
kubectl logs pod-name
# View logs from specific container
kubectl logs pod-name -c container-name
# Stream logs in real-time
kubectl logs -f pod-name
# View previous logs (for crashed container)
kubectl logs pod-name --previous
# View logs from deployment/all pods
kubectl logs deployment/my-deployment
# View multiple pods' logs
kubectl logs -l app=web --all-containers=true
Log Analysis Example:
# Check last 50 lines
kubectl logs pod-name --tail=50
# View logs from last hour
kubectl logs pod-name --since=1h
# Export logs to file
kubectl logs pod-name > pod-logs.txt
2. Health Checks (Probes)
What You Need to Know:
- Liveness probe (is app alive?)
- Readiness probe (is app ready for traffic?)
- Startup probe (has app started?)
- Probe types: httpGet, tcpSocket, exec
- Probe parameters and thresholds
Liveness Probe:
apiVersion: v1
kind: Pod
metadata:
name: app-with-liveness
spec:
containers:
- name: app
image: myapp:latest
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15 # Wait 15s before first check
periodSeconds: 20 # Check every 20s
timeoutSeconds: 1 # Timeout after 1s
failureThreshold: 3 # Restart after 3 failures
Readiness Probe:
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
timeoutSeconds: 1
failureThreshold: 3
Startup Probe (for slow-starting apps):
startupProbe:
httpGet:
path: /startup
port: 8080
failureThreshold: 30 # Allow 30 failures (30 * 10s = 300s)
periodSeconds: 10
3. Debugging Strategies
What You Need to Know:
- Describing resources and reading events
- Executing commands in running containers
- Using debugging containers
- Identifying and fixing common issues
Debugging Commands:
# Get detailed resource information
kubectl describe pod pod-name
kubectl describe deployment deploy-name
# Execute command in container
kubectl exec pod-name -- ps aux
kubectl exec pod-name -c container-name -- /bin/sh
# Interactive shell
kubectl exec -it pod-name -- /bin/bash
# Check recent events
kubectl get events --sort-by='.lastTimestamp'
# Debug pod with attached shell
kubectl debug node/node-name -it --image=ubuntu
# Copy files from pod
kubectl cp pod-name:/path/to/file ./local-file
# Port forward for debugging
kubectl port-forward pod-name 8080:8080
4. Resource Monitoring
What You Need to Know:
- Resource usage (CPU, memory)
- Resource requests and limits
- Monitoring with
kubectl top - Understanding metrics
Monitoring Commands:
# View pod resource usage (requires metrics-server)
kubectl top pods
# View node resource usage
kubectl top nodes
# View detailed pod metrics
kubectl top pod pod-name --containers
# View resource requests vs actual usage
kubectl describe node node-name
Domain 3 Practice Questions
- View logs from a multi-container pod’s specific container
- Configure liveness, readiness, and startup probes for an application
- Troubleshoot a failing pod using logs and describe commands
- Execute commands in a running container to debug issues
Domain 4: Application Environment, Config & Security (25%)
Overview
This is the largest domain, covering configuration management and security. Mastering this domain is critical for CKAD success.
Key Topics
1. ConfigMaps
What You Need to Know:
- Creating ConfigMaps from literals, files, and directories
- Using ConfigMaps as environment variables
- Using ConfigMaps as volume mounts
- Updating ConfigMaps
Creating ConfigMaps:
# From literals
kubectl create configmap app-config \
--from-literal=APP_ENV=production \
--from-literal=LOG_LEVEL=debug
# From file
kubectl create configmap app-config --from-file=config.yaml
# From directory
kubectl create configmap app-config --from-file=config/
# From command output
kubectl create configmap app-config --from-file=config=/path/to/config.yaml
Using ConfigMap in Pod:
apiVersion: v1
kind: Pod
metadata:
name: config-pod
spec:
containers:
- name: app
image: myapp:latest
# Method 1: Environment variables
env:
- name: APP_ENV
valueFrom:
configMapKeyRef:
name: app-config
key: APP_ENV
# Method 2: ConfigMap as volume
volumeMounts:
- name: config-vol
mountPath: /etc/config
volumes:
- name: config-vol
configMap:
name: app-config
Updating ConfigMaps:
# Edit ConfigMap
kubectl edit configmap app-config
# Replace from file
kubectl create configmap app-config --from-file=config.yaml -o yaml --dry-run=client | kubectl apply -f -
2. Secrets
What You Need to Know:
- Secret types: generic, docker-json, tls
- Creating and using Secrets
- Secrets as environment variables and volumes
- Base64 encoding understanding
Creating Secrets:
# Generic secret from literals
kubectl create secret generic db-secret \
--from-literal=username=admin \
--from-literal=password=secretpass
# Docker registry secret
kubectl create secret docker-registry regcred \
--docker-server=myregistry.com \
--docker-username=user \
--docker-password=pass \
[email protected]
# TLS/SSL secret
kubectl create secret tls tls-secret \
--cert=path/to/cert.crt \
--key=path/to/key.key
# From file
kubectl create secret generic app-secret --from-file=secrets.yaml
Using Secrets in Pod:
apiVersion: v1
kind: Pod
metadata:
name: secret-pod
spec:
containers:
- name: app
image: myapp:latest
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: password
volumeMounts:
- name: secret-vol
mountPath: /etc/secrets
readOnly: true
volumes:
- name: secret-vol
secret:
secretName: db-secret
# For docker registry secret
imagePullSecrets:
- name: regcred
3. SecurityContext
What You Need to Know:
- Running as non-root user
- Capability management
- Read-only filesystem
- Privilege escalation prevention
- Pod-level vs container-level security
SecurityContext Examples:
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
# Pod-level security context
securityContext:
runAsUser: 1000 # Run as user ID 1000
runAsNonRoot: true # Enforce non-root
fsGroup: 2000 # Set filesystem group
containers:
- name: app
image: myapp:latest
# Container-level security context
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}
4. Pod Security Policies and Standards
What You Need to Know:
- Pod Security Standards (restricted, baseline, unrestricted)
- Enforcing security policies at namespace level
- Security context requirements
Namespace with Security Labels:
# Apply Pod Security Standards at namespace level
kubectl label namespace default pod-security.kubernetes.io/enforce=restricted
# Verify labels
kubectl get namespace default --show-labels
5. Role-Based Access Control (RBAC)
What You Need to Know:
- Service Accounts for pod identity
- Roles and ClusterRoles (what permissions)
- RoleBindings and ClusterRoleBindings (who has permissions)
- API groups and verbs
- RBAC best practices
RBAC Components:
# 1. Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-sa
---
# 2. Role (namespace-scoped)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/logs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get"]
---
# 3. RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-reader
subjects:
- kind: ServiceAccount
name: app-sa
namespace: default
---
# 4. Pod using Service Account
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
serviceAccountName: app-sa
containers:
- name: app
image: myapp:latest
Common Verbs:
get, list, watch, create, update, patch, delete, deletecollection
Common API Groups:
"" (core)
apps
batch
networking.k8s.io
rbac.authorization.k8s.io
storage.k8s.io
6. Network Policies
What You Need to Know:
- Ingress and egress rules
- Pod and namespace selectors
- Port specifications
- Network policy use cases
Network Policy Examples:
# Deny all ingress traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
spec:
podSelector: {}
policyTypes:
- Ingress
---
# Allow traffic from specific pods
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-frontend
spec:
podSelector:
matchLabels:
tier: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
tier: frontend
ports:
- protocol: TCP
port: 8080
---
# Allow egress to external DNS
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-dns
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- namespaceSelector: {}
ports:
- protocol: UDP
port: 53
Domain 4 Practice Questions
- Create ConfigMap and Secret for application configuration
- Implement SecurityContext for running as non-root user
- Configure RBAC with Service Account, Role, and RoleBinding
- Create NetworkPolicy to restrict traffic between pods
- Use ConfigMap and Secret in Deployment
Domain 5: Services & Networking (20%)
Overview
This domain covers exposing applications and network communication in Kubernetes.
Key Topics
1. Services
What You Need to Know:
- Service types: ClusterIP, NodePort, LoadBalancer
- Service selectors and labels
- Endpoints and service discovery
- Port mapping (port, targetPort)
ClusterIP Service (Default):
# Create ClusterIP service
kubectl expose deployment web --port=80 --target-port=8080
# YAML definition
cat > service.yaml << 'EOF'
apiVersion: v1
kind: Service
metadata:
name: web
spec:
type: ClusterIP
selector:
app: web
ports:
- port: 80 # Service port
targetPort: 8080 # Container port
protocol: TCP
EOF
kubectl apply -f service.yaml
NodePort Service (External Access):
# Create NodePort service
kubectl expose deployment web --type=NodePort --port=80 --target-port=8080
# YAML definition
apiVersion: v1
kind: Service
metadata:
name: web-nodeport
spec:
type: NodePort
selector:
app: web
ports:
- port: 80
targetPort: 8080
nodePort: 30000 # Optional: specify port (30000-32767)
LoadBalancer Service:
apiVersion: v1
kind: Service
metadata:
name: web-lb
spec:
type: LoadBalancer
selector:
app: web
ports:
- port: 80
targetPort: 8080
ExternalName Service:
apiVersion: v1
kind: Service
metadata:
name: external-db
spec:
type: ExternalName
externalName: db.example.com
ports:
- port: 5432
2. DNS and Service Discovery
What You Need to Know:
- Kubernetes DNS service
- FQDN for services
- DNS resolution within cluster
- Service discovery patterns
DNS Name Resolution:
# Within same namespace
service-name
# Across namespaces
service-name.namespace-name.svc.cluster.local
# Full FQDN
service-name.namespace-name.svc.cluster.local
# Pod DNS names (for StatefulSets)
pod-name.service-name.namespace-name.svc.cluster.local
Testing DNS:
# Test service discovery
kubectl run debug --image=curlimages/curl -i --tty -- sh
# Inside container
curl http://web # Same namespace
curl http://web.default.svc.cluster.local # Full FQDN
nslookup web # DNS lookup
3. Ingress
What You Need to Know:
- Ingress for HTTP/HTTPS routing
- Path-based and host-based routing
- TLS/SSL configuration
- Ingress controller requirement
Basic Ingress:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
spec:
ingressClassName: nginx # Specify ingress controller
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web
port:
number: 80
Multi-path Ingress:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-path-ingress
spec:
rules:
- host: api.example.com
http:
paths:
- path: /users
pathType: Prefix
backend:
service:
name: user-service
port:
number: 80
- path: /products
pathType: Prefix
backend:
service:
name: product-service
port:
number: 80
Ingress with TLS:
apiVersion: v1
kind: Secret
metadata:
name: tls-secret
type: kubernetes.io/tls
data:
tls.crt: <base64-encoded-cert>
tls.key: <base64-encoded-key>
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: tls-ingress
spec:
tls:
- hosts:
- example.com
secretName: tls-secret
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web
port:
number: 80
4. Network Connectivity
What You Need to Know:
- Pod-to-pod communication
- Service discovery and DNS
- Network policies for traffic control
- Load balancing behavior
Domain 5 Practice Questions
- Create ClusterIP, NodePort, and LoadBalancer services
- Configure Ingress with path-based routing
- Set up TLS/SSL termination in Ingress
- Test service discovery using DNS names
- Implement multi-host Ingress configuration
Study Strategy by Domain
Time Allocation for Study
Based on weightage, allocate your study time:
| Domain | Weightage | Study Hours (4-week) |
|---|---|---|
| App Design & Build | 20% | 12 hours |
| App Deployment | 20% | 12 hours |
| Observability & Maintenance | 15% | 9 hours |
| Config & Security | 25% | 15 hours |
| Services & Networking | 20% | 12 hours |
| Total | 100% | 60 hours |
Practice Questions by Domain
Ensure you practice questions from all domains:
Domain 1 (Design & Build):
- Create optimized Docker images
- Implement multi-container pod patterns
- Use init containers and sidecars
Domain 2 (Deployment):
- Create and scale deployments
- Perform rolling updates and rollbacks
- Configure deployment strategies
Domain 3 (Observability):
- Access and analyze logs
- Configure health checks
- Debug failing applications
Domain 4 (Config & Security): (Most Important)
- Use ConfigMaps and Secrets extensively
- Implement RBAC and SecurityContext
- Create network policies
Domain 5 (Services & Networking):
- Create services of all types
- Configure Ingress with routing rules
- Test service discovery
Final Tips
- Prioritize Domain 4: It’s 25% of the exam—know it inside and out
- Practice Hands-On: Don’t just read; create resources repeatedly
- Understand Concepts: Know the “why” not just the “how”
- Use Official Docs: Get comfortable referencing kubernetes.io during practice
- Take Full-Length Exams: Use Sailor.sh for comprehensive practice
Ready to master all five domains? Start your comprehensive CKAD preparation with Sailor.sh’s expert-designed exams covering all domains with detailed explanations.