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.

Question 6 · Application Design and Build

Your Kubernetes cluster runs a web application that must process files uploaded by users and store them permanently. Which workload resource and volume combination best addresses this requirement?

• DaemonSet with hostPath volumes
• Deployment with PersistentVolumeClaim volumes
• CronJob with emptyDir volumes
• Job with configMap volumes

Correct answer: Deployment with PersistentVolumeClaim volumes

A Deployment manages stateless or stateful replicas of your application, and PersistentVolumeClaim volumes provide durable storage that survives pod restarts and rescheduling. This is the standard pattern for applications requiring persistent data.

Question 7 · Application Design and Build

A DaemonSet is running monitoring agents on every node in your cluster. A new node is added to the cluster. What happens to the DaemonSet?

• The DaemonSet is not affected until you manually trigger a redeployment
• A new Pod is automatically created on the new node to match the DaemonSet
• The DaemonSet must be restarted to recognize the new node
• You must edit the DaemonSet to specify the new node name

Correct answer: A new Pod is automatically created on the new node to match the DaemonSet

DaemonSets automatically ensure that a Pod runs on every node in the cluster, including newly added nodes. The controller monitors the cluster state and creates/removes Pods as nodes are added/removed.

Question 8 · Application Design and Build

You're deploying a batch processing job that must run exactly once and complete successfully. The job processes 1000 CSV files. Which Kubernetes resource should you use?

• Deployment, because it manages long-running applications
• CronJob, because it schedules jobs periodically
• Job, because it runs to completion and stops
• StatefulSet, because the files have order dependencies

Correct answer: Job, because it runs to completion and stops

A Job creates Pods and ensures they run to completion. It's designed for one-off or batch workloads that need to execute once or a specified number of times and then stop. Unlike Deployments (which run indefinitely) or CronJobs (which run on a schedule), Jobs are ideal for batch processing.

Question 9 · Application Design and Build

You have a CronJob configured to run every day at 2 AM. The schedule expression is '0 2 * * *'. The job sometimes takes 45 minutes to complete, and the next scheduled run might start before the previous one finishes. How can you prevent overlapping job executions?

• Set the 'concurrencyPolicy' field to 'Forbid' in the CronJob spec
• Reduce the job execution time below 24 hours
• Set the 'backoffLimit' to 1 in the CronJob spec
• Configure 'restartPolicy: Never' in the Pod template

Correct answer: Set the 'concurrencyPolicy' field to 'Forbid' in the CronJob spec

The 'concurrencyPolicy' field controls how concurrent runs are handled. Setting it to 'Forbid' prevents a new Job from starting if the previous one hasn't completed, while 'Allow' (default) and 'Replace' allow different behaviors for overlap handling.

Question 10 · Application Design and Build

An init container in a Pod must download a configuration file from an external service before the main application starts. The main container expects the file at '/etc/config/app.conf'. Which volume should be shared between the init and main container?

• hostPath volume to access the host filesystem
• emptyDir volume to provide temporary shared storage
• secret volume to store sensitive data
• configMap volume to store configuration as a resource

Correct answer: emptyDir volume to provide temporary shared storage

An emptyDir volume is perfect for init containers that prepare data for the main container. Both containers see the same volume, so the init container can write the config file to a shared emptyDir, and the main container can read it from the same path.