CKAD Exam Questions and Answers

env: - name: DB_URL valueFrom: configMapKeyRef: name: db-config key: DB_URL

This is the correct and idiomatic way to inject a single value from a ConfigMap into an environment variable. The configMapKeyRef field explicitly names the ConfigMap (db-config) and the specific key (DB_URL), and Kubernetes resolves this reference when the pod is created. Unlike envFrom, it gives precise control over which entry gets injected, and unlike a literal value, it keeps the configuration externalized so the same manifest can be reused with different ConfigMaps.

hostPath

This is the only volume type that directly mounts a file or directory from the host node into the pod, making it the correct way to access a pre-existing host file such as /etc/hosts or a custom configuration file. By specifying the path and type, Kubernetes ensures the container sees the exact content stored on that node. However, because it is node-specific, it requires careful scheduling and carries security implications, but for this use case it unambiguously satisfies the requirement.

NetworkPolicy

NetworkPolicy is the correct Kubernetes resource for restricting network traffic to and from pods. It uses label selectors to match pods and defines ingress/egress rules in the spec, allowing you to control traffic at the IP/port level. For example, you can default-deny all ingress and then allow only from specific pod labels.

runAsUser: 1000

runAsUser: 1000 directly sets the container process's user ID to 1000, overriding any default user defined in the image's Dockerfile or container runtime configuration. This makes the process run as UID 1000 regardless of the image's original settings, and it is the only way to deterministically satisfy a policy that explicitly requires UID 1000. It is the exact, explicit control needed when the container starts as root by default.

env: - name: SECRET_KEY valueFrom: secretKeyRef: name: my-secret key: key

This correctly uses secretKeyRef to reference a specific key from a Secret. The name field identifies the Secret resource, and key specifies which entry to extract; the value is base64-decoded before being set as the environment variable. This is the standard, explicit method for injecting a single secret value into a container.

envFrom: - secretRef: name: my-secret

This uses envFrom with secretRef, which imports all key-value pairs from the referenced Secret as environment variables. It is a convenient way to bulk-load a Secret's data, though individual env entries take precedence if any collisions occur. This is valid because secretRef is the Secret-specific counterpart to configMapRef.

defaultAddCapabilities

`defaultAddCapabilities` specifies a list of Linux capabilities that are appended to the `default` set of capabilities for every container created under the policy. It is a valid capability field because it directly controls which capabilities are added by default, complementing the container runtime defaults.

requiredDropCapabilities

`requiredDropCapabilities` explicitly lists capabilities that must be removed from every container's capability set, regardless of the image or runtime configuration. It is a valid field because it enforces a mandatory reduction of privileges, ensuring that dangerous capabilities are always dropped even if the container image requests them.

allowedCapabilities

`allowedCapabilities` enumerates the Linux capabilities that a container may explicitly request to add beyond the default set defined by the runtime. This field governs which additional capabilities are permitted without requiring a privileged container, making it a core capability management field for fine-grained access control.

kubectl exec web-app -- top

kubectl exec web-app -- top is correct because it runs the top utility inside the container, which reads /proc to display a live view of processes with their PID, CPU usage, memory usage, and command name. This directly identifies the process consuming the most CPU from the perspective of the container's PID namespace. Note that top must exist in the container image, or you may need an alternative like kubectl exec web-app -- ps aux or /bin/sh -c 'top -b -n 1'.

Increase the memory limit in the deployment spec and apply the change; the rollout will automatically restart pods.

Editing the Deployment's pod template and applying the manifest updates the desired state, which makes the Deployment controller create a new ReplicaSet while scaling down the old one according to the configured strategy (default RollingUpdate). New pods are launched with the increased memory limit, and old pods are terminated only once the new ones are Healthy, keeping the service available throughout. Because the Pod spec is immutable, the template change is the declarative, supported path to alter resources without manual pod handling.

kubectl logs my-pod --tail=20

The --tail=20 flag instructs kubectl to print only the last 20 lines of the container's log output. For a pod in CrashLoopBackOff, these final lines almost always contain the exact exception, panic, or error that triggered the latest restart. This targeted snapshot cuts through the noise of earlier failed attempts and gives you the actionable diagnostic information you need immediately.

The service selector does not match the labels of any running pod.

Endpoints are created by the endpoint controller, which watches pods and compares each pod's labels against the service's spec.selector. If no running pod carries every label key/value in that selector, the Endpoints object remains with an empty address list, even though the service itself exists. This is the textbook cause of an empty Endpoints resource and the correct answer to this symptom.

Examine the container logs via 'kubectl logs' for error messages around the time of the failures.

Container logs are the most direct source of information about what the application was doing when the liveness probe failed, because the application often writes an error, panic, or timeout message immediately before it becomes unresponsive. Use `kubectl logs <pod>` to view the current logs, and `kubectl logs <pod> --previous=true` if the container has been restarted, to find logs from the failed run. Correlating log timestamps with probe failure events from `kubectl describe` lets you pinpoint the exact code path or dependency failure causing the probe to fail.

Reduce the CPU request of the pod and reapply the manifest.

The scheduler places pods on nodes using the CPU request as the reservation; a pending pod with 'Insufficient cpu' events has a request larger than any node's free capacity. Reducing the CPU request in the pod spec to fit within an existing node's available allocatable CPU allows the scheduler to find a suitable node, and reapply the manifest (via kubectl replace -f or delete/recreate) so the pod is re-created with the lowered request. This directly addresses the root cause and is faster than infrastructure changes.

Service of type ClusterIP

A ClusterIP Service is the default and correct Service type for internal-only communication. It assigns a stable virtual IP from the cluster's service CIDR that is reachable only from inside the cluster, and it provides built-in load balancing across the backend Pods via iptables/IPVS rules managed by kube-proxy. The frontend Pods can reliably resolve the Service by DNS name and connect to it, without any external exposure, which exactly matches the requirement for a backend that should not be accessible from outside the cluster.

The Service selector does not match any Pods in the same namespace

A Kubernetes Service's selector is strictly namespace-scoped: it only matches Pods that have the same labels AND are in the same namespace as the Service. If no Pod in the 'prod' namespace carries the labels defined in the Service's 'spec.selector', the Endpoints and EndpointSlice controllers find zero backing Pods, resulting in an empty endpoints list. As a consequence, even though DNS resolves the Service's ClusterIP, any connection attempt to that IP gets no forwarding target and fails with a connection refused or timeout. This is the correct explanation because it directly addresses why no endpoints exist for the Service.

ExternalName

An ExternalName Service maps a Service's DNS name to an external fully-qualified domain name. When queried, CoreDNS returns a CNAME record directly to the target, such as db.example.com, so pods can reach the database through an in-cluster alias without any proxy or selector.

The cluster does not have a cloud provider configured

A pending external IP on a LoadBalancer Service almost always indicates that no cloud provider integration is active in the cluster. The component responsible for creating and managing the cloud load balancer is the cloud-controller-manager (or an in-tree cloud provider in older versions); if it is not running or the cluster is on bare metal, the Service will never transition out of the '<pending>' state. This is a common scenario in minikube, kind, or on-premises deployments, where you need a solution like MetalLB to provide LB functionality.

NodePort

NodePort allocates a static port on every node's IP and forwards traffic to the backing Pods, satisfying the requirement to expose Pods on a specific port on each node. ClusterIP and LoadBalancer do not provide per-node port exposure.

Check the readiness probe of the Pods

A 503 Service Unavailable from an Ingress almost always means the Ingress controller has no healthy endpoints to forward the request to. Readiness probes are the gate that determines whether a Pod is included in the Service's Endpoints or EndpointSlice object; if the probe fails, the Pod is removed. The Ingress controller then sees an empty endpoint list for the backend Service and returns 503 before any request reaches the application. Therefore, checking the readiness probe configuration and the current Pod status is the correct first step to diagnose a 503.

Define an init container with the script and mount the shared volume to both init and main containers.

Init containers always run to completion before any application container in the pod is started, and each init container must exit with status 0. By mounting the same volume in both the init container and the main container, the script can write required files that the main container reads immediately upon startup. This guarantees the initialization is fully completed before the microservice process begins.

NodePort

NodePort is the simplest Service type that exposes an application to traffic from outside the cluster by opening a static port (default range 30000-32767) on every worker node's IP address. Traffic sent to any node's IP at that port is forwarded through the Service to the backing pod(s) selected by the Deployment, regardless of which node actually runs those pods. In the absence of a cloud-provider load balancer, NodePort works on any Kubernetes cluster and is precisely the mechanism that satisfies the developer's requirement to expose the web app externally.

Secret data is base64 encoded in YAML manifests.

Secret data is base64 encoded in YAML manifests. Base64 encoding is not encryption; it is an encoding scheme that converts arbitrary binary data into ASCII text, making secrets safe to include in YAML without formatting issues. However, anyone who can read the manifest can trivially decode the base64 string, so a base64-encoded secret provides no confidentiality whatsoever.

Secrets can be mounted as volumes in a Pod.

Secrets can be mounted as volumes in a Pod. When a Secret is mounted as a volume, each key in the Secret becomes a file whose content is the secret value, placed in the mount location you specify. This is useful for injecting configuration files or data that applications expect on the filesystem, and updates to the Secret are automatically pushed to the mounted files unless you use `subPath`.

Each pod requires a stable, unique network identity.

StatefulSet pods are assigned a stable, unique network identity based on their ordinal index (e.g., my-statefulset-0, my-statefulset-1). This hostname remains consistent across pod rescheduling, and when paired with a headless Service, each pod has a stable DNS name that other components can rely on. Deployments, by contrast, create pods with random suffixes and no guarantee of stable hostnames.

Each pod needs its own persistent volume that persists across rescheduling.

StatefulSets use volumeClaimTemplates to automatically provision a unique PersistentVolumeClaim for each replica, ensuring every pod gets its own persistent volume that is reattached when the pod is rescheduled. Deployments share a single volume template across all replicas, so they cannot provide per-pod durable storage that survives rescheduling. This per-pod storage binding is a core reason to prefer StatefulSets for stateful workloads.

Pods must be terminated in reverse order during shutdown.

StatefulSets guarantee that pods are terminated in reverse ordinal order during shutdown or scale-down, meaning the highest-numbered pod is stopped first. Deployments do not impose any ordering on pod termination; they may stop pods concurrently. This controlled, predictable shutdown sequence is valuable for workloads that require graceful teardown, such as database replicas, and is a legitimate reason to opt for a StatefulSet.

The kubelet sync interval delays the propagation of ConfigMap changes to pods.

The correct explanation is that the kubelet runs a periodic sync loop (commonly every 1 minute, configurable via `--sync-frequency`) that refreshes ConfigMap data into mounted volumes. Until that sync cycle runs, pods continue reading the previous version of the ConfigMap, which is why updates appear delayed. After the sync, the files are updated in place and subsequent reads see the new data.

The Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.

Without a readiness probe, kube-proxy considers a Pod 'Ready' as soon as its containers are running, even if the application inside is still initializing, warming up, or temporarily unable to handle traffic. This causes the Service to include such Pods as endpoints, so some requests get routed to a Pod that will sporadically return 5xx errors or drop the connection. A readiness probe solves this by marking the Pod Ready only when it responds successfully to a health check, ensuring the Service’s endpoint list contains only truly available Pods.

StatefulSet

A StatefulSet assigns each pod a stable, zero-based ordinal hostname (e.g., web-0, web-1) derived from the StatefulSet name and replica index. These identities persist across rescheduling because a replacement pod always inherits the same ordinal and, if configured, the same PersistentVolumeClaim. Combined with a headless service, each pod gets a unique DNS name, which perfectly fulfills the requirement for stable network identities in a stateless or stateful application.

Service

A Service provides a stable virtual IP (ClusterIP) and a DNS record via the cluster's internal DNS (e.g., <service>.<namespace>.svc.cluster.local), so clients can resolve the backend without knowing individual Pod IPs. It uses label selectors to identify target Pods and load-balances traffic across them, which is precisely what this microservice needs for reliable internal reachability. This is the standard Kubernetes abstraction for service discovery within a cluster.

Leave ttlSecondsAfterFinished unset

Leaving ttlSecondsAfterFinished unset is the correct way to ensure the Job and its Pods remain after completion. By default, the Kubernetes Job controller does not automatically delete finished Pods or the Job object; they stay in the cluster indefinitely until a human or an automated process removes them. This gives the developer time to inspect the Pod's logs, output files, or status, which is exactly what is needed for a one-time batch job.

StatefulSet

StatefulSet is the correct controller because it assigns each pod a stable, ordinal hostname (e.g., db-0, db-1) backed by a Headless Service, so cluster members can discover each other deterministically. Its volumeClaimTemplates provision a unique PersistentVolumeClaim for every replica, ensuring data survives restarts. StatefulSet also supports ordered, graceful deployment and scaling, which matches the initialization and quorum requirements of stateful databases.

7

With maxSurge=2, the Deployment controller may temporarily create up to 2 extra pods beyond the desired replica count of 5. This means the total number of pods running simultaneously during a rolling update can reach 7. The controller enforces this ceiling to maintain availability while rolling out changes, and 7 is therefore the absolute maximum possible.

DaemonSet

DaemonSet is the correct controller because it automatically ensures a copy of the pod runs on every node in the cluster, including nodes added after the DaemonSet is created. It is designed for cluster-level daemons such as logging agents, monitoring exporters, and network proxies that need node-local presence. DaemonSet respects scheduling constraints like nodeSelectors and tolerations, but by default it provides the per-node coverage the requirement demands.