CKAD Application Deployment — Timed 15 Questions

Question 1

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?

15 minute time limit — choose an answer to begin.

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 2

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 3

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 4

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 5

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. 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 6

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 7

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 . `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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

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