CKAD Application Deployment — 30 Questions

Question 1

A developer wants to deploy a stateless application as a set of identical pods. They need the pods to be distributed across nodes and have stable network identities. Which resource should they use?

Accepted Answer

Deployment. A Deployment is the correct choice for a stateless application that needs identical pods distributed across nodes. It manages a ReplicaSet to ensure the desired number of replicas, supports rolling updates, and provides stable network identities via a headless Service or a regular Service, but the pods themselves do not require stable identities—only the Service provides a stable endpoint. For stateless workloads, Deployments are the standard resource.

Answer

Job

Answer

DaemonSet

Answer

StatefulSet

Question 2

A team is deploying a microservice that must be reachable within the cluster via a stable DNS name. They also need to distribute traffic among pods. Which Kubernetes resource provides both service discovery and load balancing?

Accepted Answer

Service. A Service in Kubernetes provides a stable DNS name (via cluster DNS, e.g., CoreDNS) that resolves to the Service's ClusterIP, and it load-balances traffic across the pods selected by its label selector using iptables or IPVS rules. This directly fulfills the requirement for both service discovery and load balancing within the cluster.

Answer

ConfigMap

Answer

Secret

Answer

Ingress

Question 3

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 4

A developer needs to run a one-time batch job to process data. After completion, the pod should be retained for logs inspection. Which Job configuration parameter should be set?

Accepted Answer

Leave ttlSecondsAfterFinished unset. To retain a Job's Pod after completion for log inspection, the `ttlSecondsAfterFinished` field must be left unset (or set to nil). When this field is unset, the Job controller does not automatically delete the Pod, allowing logs to be inspected. Setting it to any non-negative integer would schedule automatic deletion after that many seconds, which contradicts the requirement.

Answer

backoffLimit: 0

Answer

ttlSecondsAfterFinished: -1

Answer

activeDeadlineSeconds: 3600

Question 5

A company wants to deploy a stateful database cluster where each pod has its own persistent storage. They need stable network identities and ordered pod creation. Which resource should they use?

Accepted Answer

StatefulSet. StatefulSet is the correct resource because it provides stable, unique network identities (via headless Services and ordinal hostnames) and ordered, graceful deployment and scaling (pod creation/deletion in sequence). This matches the requirements for a stateful database cluster where each pod requires its own PersistentVolumeClaim (PVC) and stable identity for clustering.

Answer

Deployment

Answer

CronJob

Answer

DaemonSet

Question 6

A Deployment has replicas: 5. During a rolling update, the developer sets maxSurge: 2 and maxUnavailable: 1. What is the maximum number of pods that can be running during the update?

Accepted Answer

7. Option A is correct because during a rolling update, the total number of pods running is the sum of the desired replicas (5) plus the maxSurge (2), which equals 7. The maxUnavailable setting (1) controls how many pods can be down, not the upper limit of running pods. Kubernetes ensures that the number of pods above the desired count does not exceed maxSurge, so the maximum running pods is 5 + 2 = 7.

Answer

5

Answer

8

Answer

6

Question 7

A developer wants to ensure that a critical application always runs on every node in the cluster. Which resource should they use?

Accepted Answer

DaemonSet. A DaemonSet ensures that a pod runs on every node in the cluster, or on a subset of nodes based on a node selector. This is the correct resource for deploying a critical application that must be present on all nodes, such as a logging agent or a monitoring daemon.

Answer

StatefulSet

Answer

ReplicaSet

Answer

Deployment

Question 8

A pod is running but not responding to requests. The developer suspects the liveness probe is misconfigured. Which command can they use to check the probe configuration of a running pod?

Accepted Answer

kubectl describe pod . Option B is correct because `kubectl describe pod ` displays the full pod specification, including the liveness probe configuration (e.g., `Liveness: http-get /healthz delay=0s timeout=1s period=10s #success=1 #failure=3`). This allows the developer to verify the probe type, endpoint, initial delay, timeout, and failure threshold directly from the running pod's definition.

Answer

kubectl logs <pod-name>

Answer

kubectl exec <pod-name> -- env

Answer

kubectl get pod <pod-name>

Question 9

A Deployment has replicas: 3 and uses a ConfigMap. The ConfigMap is updated. The developer wants to update the pods to use the new ConfigMap without recreating the Deployment. What is the correct approach?

Accepted Answer

kubectl rollout restart deployment/. A `kubectl rollout restart deployment/` triggers a rolling restart of the Pods managed by the Deployment. Since ConfigMaps are mounted as volumes or injected as environment variables at Pod creation time, the only way to pick up updated ConfigMap data without recreating the Deployment object itself is to force the existing Pods to be terminated and recreated. The Deployment controller handles this gracefully, ensuring zero downtime by following the configured rolling update strategy.

Answer

kubectl set image deployment/ =

Answer

The pods automatically mount the new ConfigMap within seconds

Answer

Delete and recreate each pod manually

Question 10

Which TWO of the following are valid strategies for updating a Deployment?

Accepted Answer

RollingUpdate. RollingUpdate is the default update strategy in Kubernetes Deployments. It gradually replaces old Pods with new ones, ensuring zero downtime by incrementally scaling down old ReplicaSets and scaling up new ones based on configurable parameters like maxSurge and maxUnavailable.

Answer

Canary

Answer

Ramped

Answer

Blue/Green

Question 11

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 12

Which TWO of the following conditions must be met for a RollingUpdate to proceed?

Accepted Answer

The new pod must pass its readiness probe. A is correct because during a RollingUpdate, the new pod must pass its readiness probe before the old pod is terminated. This ensures the new pod is capable of serving traffic, preventing service disruption. The readiness probe is checked by the kubelet, and only when it succeeds does the ReplicaSet controller proceed with the update.

Answer

The new ReplicaSet must have the desired number of pods

Answer

The old ReplicaSet must be scaled to zero

Answer

The old ReplicaSet must be deleted

Question 13

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 14

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. Option C is correct because when a node fails, the pod on that node enters the Terminating state (as the kubelet is unreachable to confirm deletion). The ReplicaSet controller waits for the pod to be fully deleted before creating a replacement, due to the default terminationGracePeriodSeconds (30s) plus the node failure detection time (up to node-monitor-grace-period, default 40s). This delay is compounded by the pod's status not being updated until the node controller marks the node as unreachable, causing the ReplicaSet to not immediately create a new pod.

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 15

A company wants to deploy a stateless web application on Kubernetes. The application needs to be accessible externally via a stable IP address and should support SSL termination at the ingress level. Which resource should be used to route external traffic to the application?

Accepted Answer

Ingress. Ingress is the correct resource because it provides external HTTP/HTTPS access to services within a cluster, supports SSL/TLS termination at the ingress controller level, and can expose multiple services under a single stable IP address or hostname. Unlike other service types, Ingress is specifically designed for layer 7 routing and SSL termination, making it ideal for stateless web applications that require a stable external endpoint.

Answer

ClusterIP

Answer

NodePort

Answer

LoadBalancer

Question 16

A developer needs to deploy a container that runs a batch job to process data once and then exit. The job should be restarted only if it fails. Which Kubernetes resource should be used?

Accepted Answer

Job. A Kubernetes Job is the correct resource for a batch workload that runs to completion and exits. It ensures the pod is restarted only on failure (via the `RestartPolicy: OnFailure` or `Never`), which matches the requirement of restarting only if the job fails. Deployments and DaemonSets are designed for long-running processes, not termination.

Answer

DaemonSet

Answer

Deployment

Answer

StatefulSet

Question 17

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 18

A company wants to deploy a stateful database on Kubernetes. The database requires stable network identities and persistent storage per pod. Which resource should be used?

Accepted Answer

StatefulSet. StatefulSet is the correct resource because it provides stable, unique network identities (via headless Services and ordinal pod names like `db-0`, `db-1`) and persistent storage per pod (via PersistentVolumeClaims that are retained across rescheduling). This matches the requirement for a stateful database where each pod must maintain its identity and data independently.

Answer

Job

Answer

Deployment

Answer

DaemonSet

Question 19

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.. Option D is correct because 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 20

A developer is creating a Deployment with 4 replicas. The application requires a rolling update with zero downtime. Which TWO strategies ensure zero downtime during an update?

Accepted Answer

Set maxSurge=1. Option A is correct because setting maxSurge=1 allows Kubernetes to spin up one new Pod before terminating any old Pod during a rolling update. This ensures that the total number of available Pods never drops below the desired replica count, maintaining service capacity and achieving zero downtime.

Answer

Set maxUnavailable=1

Answer

Use Recreate strategy

Answer

Set maxSurge=0