CKAD Application Deployment Practice Test 1 — 15 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.