CKAD Application Deployment — 20 Questions

Question 1

During a deployment update, the rollout is stuck and new pods are not becoming ready. The developer checks the events and sees 'Back-off restarting failed container'. What is the most likely cause?

Accepted Answer

The container's entrypoint command fails immediately after start. The 'Back-off restarting failed container' event indicates that the container process exits immediately after starting, causing Kubernetes to repeatedly restart it with increasing back-off delays. This is most commonly caused by a container entrypoint or command that fails at runtime, such as a misconfigured binary, missing dependency, or incorrect startup script. Unlike probe failures, which cause restarts after the container is already running, this error occurs before the container can even become ready.

Answer

The liveness probe is failing

Answer

The image pull secret is missing

Answer

The pod exceeds its memory limit and is OOMKilled

Question 2

Which THREE of the following are valid ways to expose a set of pods as a network service?

Accepted Answer

LoadBalancer Service. A LoadBalancer Service is a valid way to expose a set of pods as a network service because it provisions an external load balancer (e.g., from a cloud provider) that distributes traffic to the pods via a NodePort and ClusterIP underneath. This allows external clients to access the service using a single IP address or hostname, making it suitable for production-grade external exposure.

Answer

Ingress

Answer

ExternalName Service

Question 3

You are deploying a multi-tier application consisting of a frontend web service and a backend API. The frontend is deployed as a Deployment with 3 replicas, exposed via a ClusterIP Service named 'frontend-svc'. The backend is a StatefulSet with 3 replicas, each with its own PersistentVolumeClaim, and exposed via a headless Service named 'backend-svc'. The backend pods need to discover each other via DNS for clustering. After deployment, the backend pods cannot resolve the hostnames of other backend pods. The frontend can reach the backend via the Service name. You verify that the StatefulSet and its Service are correctly named. What is the most likely cause of the issue?

Accepted Answer

The backend Service is not headless. For a StatefulSet to provide DNS-based pod discovery, its associated Service must be headless (clusterIP: None). A headless Service creates DNS A/AAAA records for each pod's hostname (e.g., backend-svc-0.backend-svc.default.svc.cluster.local), enabling direct pod-to-pod resolution. If the Service is not headless, DNS queries for individual pod hostnames will not resolve, breaking clustering discovery.

Answer

The StatefulSet's serviceName does not match the backend Service name

Answer

The backend pods are not using the correct DNS domain

Answer

The frontend Service is interfering with the backend DNS

Question 4

You are responsible for deploying a critical application that must be highly available. The application consists of a single pod that should always be running on a node that has an SSD. You have two node pools: one with standard HDD and one with SSD. The application must be rescheduled immediately if the node fails. You create a Deployment with replicas: 1 and a nodeSelector for the SSD label. However, after a node failure, the pod is not rescheduled on another SSD node for several minutes. You check the Deployment and it shows the desired replica count is 1 but the current replica count is 0. What is the most likely reason for the delay?

Accepted Answer

The pod is in Terminating state on the failed node and the ReplicaSet waits for it to be fully deleted. When a node fails, the kubelet on that node is unreachable and cannot perform a graceful termination. The node controller detects the failure after the node-monitor-grace-period (default 40s) and then, after another timeout period (pod-eviction-timeout, default 5 minutes), forcibly deletes the pod. Until the pod object is removed from the API server, the ReplicaSet controller sees the existing pod and does not create a replacement. The terminationGracePeriodSeconds (30s) is not a factor here because it applies only when the kubelet can run graceful shutdown logic; it does not apply when the node is unreachable. The observed delay of several minutes is due to the pod-eviction-timeout, not the termination grace period.

Answer

The Deployment's progressDeadlineSeconds is set too high

Answer

The application's readiness probe is failing on the new node

Answer

The nodeSelector is preventing the pod from being scheduled on available SSD nodes

Question 5

A team is deploying a microservice that requires a ConfigMap mounted as a volume. The ConfigMap is expected to be updated frequently, and the application should read the latest values without restarting. Which volume type should be used?

Accepted Answer

Projected volume. A Projected volume allows you to mount multiple existing volume sources, including ConfigMaps, Secrets, and others, into the same directory. When the ConfigMap is updated, the contents of the Projected volume are automatically updated via the kubelet's periodic sync (default every 60 seconds), enabling the application to read the latest values without restarting the pod.

Answer

hostPath

Answer

persistentVolumeClaim

Answer

emptyDir

Question 6

The exhibit shows a Deployment configuration. The application's /health endpoint returns HTTP 200 only after 30 seconds, while /ready returns 200 immediately. After applying this Deployment, what is the expected behavior?

Accepted Answer

Pods will become ready quickly but will be restarted repeatedly until the liveness probe starts succeeding after 30 seconds.. The readiness probe passes immediately (since /ready returns 200), so the Pod is marked Ready and added to the Service. However, the liveness probe fails initially (since /health returns non-200 for the first 30 seconds), causing the kubelet to restart the container repeatedly until the liveness probe starts succeeding after 30 seconds. This behavior is defined by Kubernetes: a failing liveness probe triggers container restarts, while a failing readiness probe only removes the Pod from Service endpoints.

Answer

Pods will become ready after 30 seconds when both probes pass.

Answer

Pods will never become ready because the liveness probe fails initially.

Answer

Pods will never become ready because the readiness probe fails initially.

Question 7

You are deploying a microservice application on a Kubernetes cluster. The application consists of a frontend service (type: ClusterIP) and a backend service (type: ClusterIP). The frontend needs to communicate with the backend via DNS name 'backend-service'. The backend service runs three replicas, each listening on port 8080. You have created the backend service and deployment, and verified that pods are running. However, when you deploy the frontend pod and attempt to curl http://backend-service:8080 from within the frontend, you get 'connection refused'. The frontend pod is in the same namespace as the backend. You check the backend pods and they are all running and ready, and the endpoints object shows the correct pod IPs. You suspect a misconfiguration in the service definition. Which of the following is the most likely cause of the issue?

Accepted Answer

The backend deployment's containerPort is set to 8081, but the service's targetPort is 8080, causing a mismatch.. The stem states each backend pod listens on port 8080. If the service's port is 8080 and targetPort is unspecified, targetPort defaults to 8080, which matches the actual listening port. Option D's claim that the deployment's containerPort is 8081 contradicts the stem and, more importantly, containerPort is informational only; it does not determine which port the service targets. The connection refused error is most likely due to a targetPort that does not match the actual listening port, but none of the provided options correctly describe this misconfiguration. Therefore, no option is correct as written.

Answer

The backend pods are not running on the nodes because the cluster has insufficient resources.

Answer

The frontend pod is using the wrong service name; it should be 'backend-service.default.svc.cluster.local'.

Answer

The backend service's port field is set to 8080, but the targetPort is not specified, so it defaults to the port field value, which is correct.

Question 8

You are deploying a microservice that reads from a ConfigMap and a Secret. The application logs show 'Failed to read configuration: missing key' on startup. Which TWO are likely causes?

Accepted Answer

The ConfigMap does not exist in the namespace. If the ConfigMap does not exist in the namespace, any pod referencing it will fail to start or the application will be unable to read the configuration data. Kubernetes validates ConfigMap existence at pod creation time, and missing ConfigMaps cause the pod to remain in a pending state or the application to log errors like 'missing key' when attempting to access the configuration.

Answer

The Secret data is base64 encoded in the manifest, but the application expects decoded values

Answer

The ServiceAccount used by the pod does not have permissions to access Secrets

Answer

The ConfigMap was updated but the pod was not restarted

Question 9

Arrange the steps to create a PersistentVolumeClaim and use it in a Pod.

Accepted Answer

Create PVC, then verify PVC is bound to a PV, then create Pod referencing PVC in volumes.. Create PVC first, ensure it's bound, then define Pod with volume referencing PVC.

Answer

Create Pod referencing PVC first, then create PVC.

Answer

Create PVC, then create Pod referencing PVC, without verifying binding.

Answer

Create Pod with inline volume, then convert to PVC-based volume.

Question 10

Match each kubectl command to its function.

Accepted Answer

kubectl get: Retrieve resource information from the cluster. The correct matches are: kubectl get retrieves information, kubectl describe shows details, kubectl apply creates/updates, and kubectl delete removes. Common confusions include misattributing 'apply' to 'get' or 'delete' to 'describe'.

Answer

kubectl get: Create or update resources from a file

Answer

kubectl describe: Remove resources from the cluster

Question 11

Match each volume type to its use case.

Accepted Answer

emptyDir: Provides temporary storage that is created empty and persists for the lifetime of the pod.. The correct matches are: emptyDir - temporary storage, hostPath - host node directory, PVC - persistent storage, ConfigMap - configuration data. Common confusions involve mixing hostPath and PVC, or emptyDir with hostPath.

Answer

emptyDir: Mounts a file or directory from the host node's filesystem.

Answer

hostPath: Requests persistent storage that survives pod restarts.

Question 12

You have an existing Deployment 'web' created with 'kubectl create deployment web --image=nginx --replicas=3'. You need to change the image to 'nginx:1.19' and record the change. Which command should you use?

Accepted Answer

kubectl set image deployment/web web=nginx:1.19 --record. `kubectl set image deployment/web web=nginx:1.19 --record` directly updates the container image for the 'web' container in the 'web' Deployment and the `--record` flag annotates the change with the command used, which is visible in the rollout history. This is the most straightforward and idiomatic way to update an image and record the change for audit or rollback purposes.

Answer

kubectl replace -f deployment.yaml --record

Answer

kubectl edit deployment web --record

Answer

kubectl patch deployment web -p '{"spec":{"template":{"spec":{"containers":[{"name":"web","image":"nginx:1.19"}]}}}}}' --record

Question 13

You are using Kustomize to manage configurations. Your project structure is: 'base/kustomization.yaml', 'overlays/prod/kustomization.yaml'. The base defines a Deployment with image 'nginx:1.18'. The overlay wants to patch the image to 'nginx:1.19'. Which is the correct way to define the patch in the overlay?

Accepted Answer

Use 'patches: [path: deployment-patch.yaml]'. Kustomize supports both `patchesStrategicMerge` and the more general `patches` field. The `patches` field with a `path` entry is valid for strategic merge patches. For example, `patches: [path: deployment-patch.yaml]` is correct in current Kustomize versions. Thus both A and C are correct ways to override the image.

Answer

Use 'resources: [../base]' and then define a new Deployment with the same name to override.

Answer

Use 'patchesJson6902: [target: ..., patch: ...]'

Question 14

You have a HorizontalPodAutoscaler (HPA) targeting a Deployment. The HPA is configured with 'targetCPUUtilizationPercentage: 50'. The current CPU utilization is 60% across the pods. What action does the HPA take?

Accepted Answer

Scale up the Deployment to reduce per-pod CPU utilization.. The HPA is configured with a targetCPUUtilizationPercentage of 50%, and the current CPU utilization is 60%, which exceeds the target. The HPA will scale up the Deployment by increasing the number of replicas to distribute the load, thereby reducing per-pod CPU utilization toward the target. This is the core behavior of the Kubernetes Horizontal Pod Autoscaler: it adjusts replica count based on observed metrics to meet the target.

Answer

Scale down the Deployment because the target is 50%.

Answer

Mark the HPA as unable to calculate metrics and stop scaling.

Answer

Take no action because the deviation is within tolerance.

Question 15

You are performing a blue-green deployment for an application. You have two Deployments: 'app-blue' (current production) and 'app-green' (new version). Both have label 'app: myapp' and are exposed by a Service 'myapp-svc'. How do you switch traffic from blue to green?

Accepted Answer

Update the Service's selector to match the labels of the green Deployment's pods (e.g., 'version: green').. Updating the Service's selector to match the green Deployment's pod label routes traffic to green. Option A is incorrect because the Service cannot be deleted and recreated without downtime if done incorrectly. Option C is incorrect because deleting the blue Deployment before ensuring the green is serving traffic would cause downtime. Option D is incorrect because changing the image in the same Deployment would perform a rolling update, not a blue-green switch.

Answer

Delete the Service and recreate it with the selector pointing to app-green.

Answer

Delete the blue Deployment after ensuring green is ready.

Answer

Update the blue Deployment's image to the new version.

Question 16

Which TWO of the following are valid methods to achieve a blue-green deployment in Kubernetes? (Select two.)

Accepted Answer

Create two Deployments (blue and green) with different labels, and a Service that selects one of them. Update the Service's selector to switch traffic.. Option D is correct because blue-green deployment requires two parallel, fully-provisioned environments; creating two Deployments (blue and green) with distinct labels and a Service whose selector points at only one set of pods lets you flip all traffic atomically by editing the Service selector (e.g., from version: blue to version: green), which is the canonical Kubernetes blue-green pattern. Option E is correct because a Service selects pods by label, so if the Service selects app: myapp and you change the version label on pods (e.g., from version: blue to version: green), the endpoints controller re-evaluates the selector and shifts traffic to the newly-labeled pods, achieving a blue-green cutover without changing the Service spec. Option A is not a blue-green method: a single Deployment with a changed image performs a rolling update, and kubectl rollout pause/resume only halts or continues that rollout rather than switching between two independent environments. Option B is not blue-green either: maxSurge=100% and maxUnavailable=0% simply configures a rolling update to add all new pods before removing old ones, which is still a rolling strategy, not an atomic blue-green switch. Option C is not blue-green: multiple Deployments with Ingress weight-based routing implements canary (gradual percentage-based) traffic splitting, not the all-at-once cutover characteristic of blue-green.

Answer

Use a single Deployment and change the image, then use kubectl rollout pause/resume to control traffic.

Answer

Set maxSurge=100% and maxUnavailable=0% in the Deployment strategy.

Answer

Create multiple Deployments with different images and use Ingress with weight-based routing.

Question 17

Which TWO of the following are valid ways to view the rollout history of a Deployment named 'myapp'? (Select two.)

Accepted Answer

kubectl get replicasets -l app=myapp. Option B, `kubectl rollout history deployment myapp`, is correct because the `rollout history` subcommand is specifically designed to display the revision history of a Deployment, listing each revision number and its change-cause annotation. Option A, `kubectl get replicasets -l app=myapp`, is correct because each Deployment revision creates a ReplicaSet whose name embeds the pod-template hash, so listing ReplicaSets with the matching label effectively reveals the rollout history and which revision is currently active. Option C, `kubectl describe deployment myapp`, shows current status, events, and conditions but not the full revision history, so it is not a valid way to view rollout history. Option D, `kubectl rollout status deployment myapp`, only reports whether the current rollout is progressing or complete, not the historical revisions. Option E, `kubectl get deployment myapp -o yaml`, outputs the Deployment's current desired-state manifest and does not enumerate past revisions.

Answer

kubectl describe deployment myapp

Answer

kubectl rollout status deployment myapp

Answer

kubectl get deployment myapp -o yaml

Question 18

You need to scale a Deployment named 'frontend' to 10 replicas. Which command correctly accomplishes this?

Accepted Answer

kubectl scale deployment/frontend --replicas=10. It uses the standard imperative syntax 'kubectl scale / --replicas=N' with the resource specified as 'deployment/frontend' and the flag after the resource. Option D places the flag before the resource and uses space-separated type and name, which is not the expected form in the CKAD exam, making it incorrect despite being functionally valid in some kubectl versions.

Answer

kubectl patch deployment frontend -p '{"spec":{"replicas":10}}'

Answer

kubectl set replicas deployment/frontend 10

Answer

kubectl scale --replicas=10 deployment frontend

Question 19

Which TWO of the following are valid methods to perform a blue-green deployment in Kubernetes?

Accepted Answer

Create a new Deployment for the new version, then update the Service's selector to point to the new pods.. Option B is correct because blue-green deployment requires two distinct, fully-deployed environments: creating a new Deployment for the new version and then switching the Service's selector (or label) to point at the new pods instantly flips traffic from blue to green while keeping the old version available for rollback. Option C is correct because deploying the new version in a separate namespace and using a Service (e.g., via ExternalName or an ingress/Service routing mechanism) to direct traffic to that namespace achieves the same blue-green cutover by isolating the two versions and switching the routing target. Option A is not a blue-green method: patching the image with the Recreate strategy causes downtime and destroys the old pods rather than maintaining two parallel environments. Option D is a rollback operation, not a deployment strategy for releasing a new version. Option E describes a canary/rolling update pattern that gradually replaces pods, not the atomic traffic switch characteristic of blue-green.

Answer

Use kubectl patch to modify the Deployment's image and rely on the Recreate strategy.

Answer

Use kubectl rollout undo to revert to the previous version.

Answer

Use the RollingUpdate strategy with maxSurge=100% and maxUnavailable=0%.

Question 20

Which TWO of the following commands are used to inspect the rollout history of a Deployment?

Accepted Answer

kubectl rollout history deployment/my-deployment. Option B, `kubectl rollout history deployment/my-deployment`, is correct because it directly queries the Deployment's revision history, listing each revision number along with its change-cause annotation, which is exactly the purpose of the `rollout history` subcommand. Option C, `kubectl get replicasets -l app=my-app`, is also correct because each Deployment revision is materialized as a distinct ReplicaSet whose name embeds the pod-template hash, so listing the Deployment's ReplicaSets (filtered by its selector label) reveals the rollout history and lets you correlate revisions with ReplicaSets. Option A is not correct because `kubectl rollout status` only reports whether the current rollout has completed, not the historical revisions. Option D is not correct because `kubectl get events` shows cluster event records (scheduling, pulling, scaling) rather than the Deployment's revision history. Option E is not correct because `kubectl describe deployment` shows the current state, conditions, and the newest ReplicaSet, but not the full list of past revisions.

Answer

kubectl rollout status deployment/my-deployment

Answer

kubectl get events --field-selector involvedObject.name=my-deployment

Answer

kubectl describe deployment my-deployment