CKA Workloads & Scheduling — 15 Questions

Question 1

A DevOps team wants to ensure that a critical web application pod runs on a dedicated set of nodes with SSDs. Which Kubernetes feature should they use to achieve this?

Accepted Answer

Node affinity. Node affinity is a Kubernetes feature that allows you to constrain which nodes a pod can be scheduled on based on node labels. By labeling nodes with SSDs (e.g., `disk-type=ssd`) and defining a `requiredDuringSchedulingIgnoredDuringExecution` node affinity rule in the pod spec, the scheduler will only place the pod on nodes matching that label, ensuring it runs on nodes with SSDs.

Answer

Pod priority and preemption

Answer

Taints and tolerations

Answer

Resource quotas

Question 2

A Kubernetes cluster has a deployment with 3 replicas. After a node failure, you notice that only 2 pods are running, and the deployment has not rescheduled the missing pod. What is the most likely cause?

Accepted Answer

The node controller has not yet evicted the pod. When a node fails, the node controller marks the node as `NodeReady=False` and waits for a configurable timeout (`pod-eviction-timeout`, default 5 minutes) before evicting pods. Until eviction, the deployment's ReplicaSet sees the pod as still existing (though on an unreachable node) and does not create a replacement. Option C correctly identifies that the node controller has not yet evicted the pod, which is the default behavior.

Answer

The deployment has a resource quota that prevents new pods

Answer

The pod's terminationGracePeriodSeconds is set to 0

Answer

The deployment's replicas field is set to 2

Question 3

You have a StatefulSet with 5 pods, each requiring a unique stable network identity. The StatefulSet is scaled down from 5 to 3. Which pods will be terminated?

Accepted Answer

Pods with the highest ordinals (4 and 3). When a StatefulSet is scaled down, Kubernetes terminates pods in reverse order of their ordinal indices, starting from the highest. For a StatefulSet with 5 pods (ordinals 0-4) scaled to 3, pods with ordinals 4 and 3 are terminated first, ensuring that the remaining pods (0, 1, 2) maintain their stable network identities and storage.

Answer

Random pods

Answer

Pods with the lowest ordinals (0 and 1)

Answer

Pods with the highest resource usage

Question 4

An application requires that a pod runs on a node that has a GPU. The cluster has nodes with and without GPUs labeled as 'gpu=true' and 'gpu=false'. Which scheduling method should be used?

Accepted Answer

nodeSelector with gpu=true. To make Option C unambiguously incorrect while keeping it as a plausible distractor, we should change it to use 'preferredDuringSchedulingIgnoredDuringExecution' (soft affinity). Since the stem states the application 'requires' a GPU node, a preferred (soft) affinity rule would not satisfy this hard constraint, leaving Option D (nodeSelector, which is a hard constraint) as the single correct answer.

Answer

Taint on non-GPU nodes and toleration on the pod

Answer

Pod affinity to prefer GPU nodes

Answer

Node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule for gpu=true

Question 5

A cluster administrator wants to ensure that no pods are scheduled on the master node(s). Which approach is the best practice?

Accepted Answer

Add a taint to the master node. Adding a taint to the master node(s) with the `node-role.kubernetes.io/master:NoSchedule` effect is the best practice because it prevents the Kubernetes scheduler from placing any pods on that node unless a pod explicitly tolerates the taint. This ensures that only critical system pods (which include the toleration) can run on the master, keeping it dedicated to cluster control plane operations.

Answer

Delete the master node from the cluster

Answer

Use a resource quota on the master namespace

Answer

Set nodeSelector on the master node

Question 6

A pod is stuck in 'Pending' state. The 'kubectl describe pod' output shows the event: '0/4 nodes are available: 3 node(s) had taint {node.kubernetes.io/unreachable: }, and 1 node(s) had taint {node.kubernetes.io/not-ready: }.' What is the most likely reason?

Accepted Answer

The pod does not have tolerations for the node taints. The pod is stuck in 'Pending' because none of the available nodes can schedule it. The events explicitly show taints: 'node.kubernetes.io/unreachable' on 3 nodes and 'node.kubernetes.io/not-ready' on 1 node. By default, pods do not tolerate these taints, so the scheduler cannot place the pod unless it has matching tolerations. Option B correctly identifies that the pod lacks the required tolerations.

Answer

The pod has resource requests that exceed available capacity

Answer

The nodes are cordoned

Answer

The kube-scheduler is not running

Question 7

You have a Deployment that runs a batch job. The job should run on a node that has a specific custom resource (e.g., a license dongle). Which approach should you use?

Accepted Answer

Use node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule. Node affinity with a `preferredDuringSchedulingIgnoredDuringExecution` rule is the correct approach because it specifies a soft constraint (preference). The scheduler will try to find a node matching the label `hardware=license-dongle`, but if none are available, it will still schedule the pod on another node. In contrast, `nodeSelector` and `requiredDuringSchedulingIgnoredDuringExecution` are hard constraints that would prevent the pod from scheduling if no matching nodes were available.

Answer

Define a nodeSelector in the pod spec

Answer

Assign the pod a high priority so it gets scheduled on any node

Answer

Use pod anti-affinity to avoid nodes without the resource

Question 8

Which TWO of the following are valid methods to ensure a pod is scheduled on a node that is part of a specific availability zone? (Assume nodes are labeled with 'failure-domain.beta.kubernetes.io/zone').

Accepted Answer

Use nodeSelector with the zone label. `nodeSelector` is a simple, declarative way to constrain a pod to nodes with specific labels. By setting `nodeSelector` with `failure-domain.beta.kubernetes.io/zone: <zone>`, the scheduler will only consider nodes that have that exact label key-value pair, ensuring the pod lands in the desired availability zone.

Answer

Use a toleration for a taint that exists only on nodes in the zone

Answer

Use pod affinity to attract pods to nodes in that zone

Answer

Set spec.nodeName to the name of a node in the zone

Question 9

Which THREE of the following are characteristics of DaemonSets?

Accepted Answer

A DaemonSet runs exactly one pod per node. A DaemonSet ensures that exactly one pod runs on each node in the cluster (or a subset of nodes if node selectors are used). When a new node is added, the DaemonSet automatically schedules a pod on it; when a node is removed, the pod is garbage collected. This is enforced by the DaemonSet controller, which does not use a replica count like a Deployment or StatefulSet.

Answer

DaemonSets can be scaled down by reducing the number of replicas

Answer

A DaemonSet can be used to run a batch job that completes

Question 10

Which TWO of the following are valid reasons to use a StatefulSet instead of a Deployment?

Accepted Answer

The application requires unique network identities (e.g., hostnames). StatefulSets are designed for stateful applications that require stable, unique network identities (e.g., hostnames) and stable, persistent storage that persists across pod rescheduling. Each pod in a StatefulSet gets a predictable ordinal name and can have its own PersistentVolumeClaim, ensuring data persistence across rescheduling. Deployments, in contrast, provide arbitrary pod names and are more suitable for stateless applications, though they can be used with persistent volumes in some cases.

Answer

The application is a batch job that should run to completion

Answer

The application needs to run on all nodes in the cluster

Answer

The application is stateless and can be scaled arbitrarily

Question 11

Your team is deploying a new application that consists of a web frontend and a backend API. The frontend must be accessible from outside the cluster, and the backend should only be accessible from within the cluster. The cluster has multiple namespaces: 'frontend' and 'backend'. You have been asked to design the deployment. The frontend Deployment should have 5 replicas, and the backend Deployment should have 3 replicas. Additionally, you need to ensure that the frontend pods can communicate with the backend pods using a stable DNS name. You also want to isolate the backend from other namespaces. Which set of resources should you create?

Accepted Answer

Frontend: Deployment, Service (LoadBalancer); Backend: Deployment, Service (ClusterIP); NetworkPolicy to allow ingress from frontend namespace and deny others. It uses a LoadBalancer Service for the frontend to provide external access, a ClusterIP Service for the backend to restrict access to within the cluster, and a NetworkPolicy that allows ingress traffic from the frontend namespace to the backend while denying all other ingress, thus isolating the backend. This ensures the frontend pods can reach the backend via a stable DNS name (the ClusterIP Service's DNS name) and meets the requirement of backend isolation from other namespaces.

Answer

Frontend: Deployment, Service (NodePort); Backend: Deployment, Service (ClusterIP); no NetworkPolicy

Answer

Frontend: Deployment, Service (ClusterIP); Backend: Deployment, Service (ClusterIP); NetworkPolicy to allow ingress from frontend namespace

Answer

Frontend: Deployment, Service (LoadBalancer); Backend: Deployment, Service (LoadBalancer); NetworkPolicy to allow only frontend to backend

Question 12

A developer deployed a Pod that is stuck in Pending state. The cluster has one worker node with taint 'node.kubernetes.io/disk-pressure:NoSchedule'. The Pod does not specify any tolerations. What is the most likely cause?

Accepted Answer

The node has a taint that the Pod does not tolerate.. A Pod stuck in Pending state indicates the scheduler cannot find a suitable node. The cluster has a worker node with the taint 'node.kubernetes.io/disk-pressure:NoSchedule', and the Pod has no tolerations. Since taints with effect NoSchedule prevent scheduling of Pods that do not tolerate them, the Pod cannot be placed on that node, leaving it in Pending.

Answer

The Pod was evicted due to resource pressure.

Answer

The Pod requests more CPU than available on the node.

Answer

The scheduler failed to communicate with the API server.

Question 13

An administrator wants to ensure that a critical Pod always runs on a node that has an SSD. Which approach should be used?

Accepted Answer

Label SSD nodes with 'disk=ssd' and use nodeSelector in the Pod spec.. Using a nodeSelector with a label like 'disk=ssd' ensures that the Pod is scheduled only on nodes that have that specific label, which directly matches the requirement to run the Pod on a node with an SSD. This is the simplest and most reliable method for node-level selection in Kubernetes, as it leverages the scheduler's built-in filtering mechanism.

Answer

Use podAffinity to prefer nodes running other Pods.

Answer

Set spec.nodeName to an SSD node's name.

Answer

Add a taint to nodes without SSD and add a toleration to the Pod.

Question 14

A team observes that a Deployment's Pods are being scheduled on nodes with different architectures (amd64 and arm64). The Deployment does not specify nodeSelector or affinity. The cluster has a mix of node pools. What is the best practice to ensure Pods only run on amd64 nodes?

Answer

Add a toleration for 'arch=amd64:NoSchedule' to the Pod.

Answer

Add a label 'kubernetes.io/arch: amd64' to all amd64 nodes and use nodeSelector.

Answer

Use podAntiAffinity to avoid scheduling on arm64 nodes.

Answer

Set a runtimeClassName for amd64 in the Pod spec.

Question 15

A company runs a batch job that processes a queue. The job should run to completion exactly once. Which resource should be used?

Accepted Answer

Job. A Kubernetes Job is designed to run a specified number of pods to successful completion. When the pod exits with a zero exit code, the Job is marked as complete and will not be restarted, making it the correct choice for a batch job that must run exactly once.

Answer

DaemonSet

Answer

CronJob

Answer

Deployment