How to Ace the CKAD: Certified Kubernetes Application Developer

Question 1 · Application Design and Build

You need to create a container image for a Node.js application. Your Dockerfile has the following structure: FROM node:18 / WORKDIR /app / COPY package*.json ./ / RUN npm install / COPY . . / EXPOSE 3000 / CMD ["node", "server.js"]. When you build this image with 'docker build -t myapp:v1 .', which layer would be most frequently rebuilt during development?

• The EXPOSE layer, because it changes every time you modify source code
• The COPY . . layer, because it copies updated source code
• The RUN npm install layer, because dependencies need to be reinstalled
• The FROM node:18 layer, because it's always rebuilt first

Correct answer: The COPY . . layer, because it copies updated source code

The COPY . . layer runs last and copies your source code, so it's invalidated most frequently during development. Docker's layer caching means previous layers (FROM, WORKDIR, COPY package*.json, RUN npm install) are reused if unchanged, but the final COPY is executed whenever source files change.

Question 2 · Application Deployment

You have a Deployment with image 'myapp:v1'. You realize a security vulnerability exists and need to update to 'myapp:v2' immediately. You run 'kubectl set image deployment/myapp myapp=myapp:v2'. What happens to the current Pods?

• All Pods are deleted immediately, and new ones with v2 are created
• A rolling update begins with new Pods running v2 gradually replacing v1 Pods
• The Deployment image is changed, but existing Pods continue running v1 until manually restarted
• The update waits for a scheduled maintenance window

Correct answer: A rolling update begins with new Pods running v2 gradually replacing v1 Pods

'kubectl set image' triggers a rolling update by default. New Pods with the v2 image are created and old v1 Pods are gradually terminated, respecting the Deployment's update strategy parameters (maxUnavailable, maxSurge).

Question 3 · Application Observability and Maintenance

An application logs to stdout, and you need to retrieve logs from the last 2 hours for debugging. Which kubectl command is most appropriate?

• kubectl logs <pod-name> --since=2h
• kubectl logs <pod-name> --tail=1000
• kubectl describe pod <pod-name> | grep -i log
• kubectl get pod <pod-name> -o yaml | grep 'log'

Correct answer: kubectl logs <pod-name> --since=2h

'kubectl logs --since=2h' retrieves log entries from the last 2 hours. The '--tail' flag limits the number of lines, not the time window. 'describe' and 'get' show metadata, not the actual logs.

Question 4 · Services and Networking

You have a web application pod that should only be accessible from other pods within the cluster, not from outside. Which Service type should you create?

• NodePort service to expose on a random port
• LoadBalancer service with external IP
• ClusterIP service (default) for internal-only access
• ExternalName service

Correct answer: ClusterIP service (default) for internal-only access

ClusterIP is the default Service type and provides only internal cluster access via a stable internal IP and DNS name. It's not accessible from outside the cluster.

Question 5 · Application Design and Build

You have a multi-container Pod with an application container and a logging sidecar. The sidecar reads logs from a shared volume at /var/log/app and sends them to a centralized logging service. Which volume type would be most appropriate for this use case?

• hostPath volume, to write directly to the node's filesystem
• emptyDir volume, to provide temporary shared storage for the pod's containers
• persistentVolumeClaim, to persist logs across pod restarts
• configMap volume, to mount configuration files

Correct answer: emptyDir volume, to provide temporary shared storage for the pod's containers

An emptyDir volume is created when a Pod is assigned to a node and persists for the Pod's lifetime, making it ideal for inter-container communication. Since both containers are in the same Pod, they can share data via emptyDir without needing node-level or persistent storage.