CKA Workloads & Scheduling — Timed 10 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 the dedicated set of nodes.

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. Option D is correct because `nodeSelector` is the simplest and most direct way to force a pod to run only on nodes that have a specific label, such as `gpu=true`. This ensures the pod is scheduled exclusively on GPU-equipped nodes without requiring taints, tolerations, or complex affinity rules. The `nodeSelector` field in the pod spec matches against node labels at scheduling time, making it ideal for this straightforward requirement.

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 `requiredDuringSchedulingIgnoredDuringExecution` rule is the correct approach because it allows you to schedule the pod exclusively on nodes that have a specific custom resource (e.g., a license dongle) by matching node labels. This rule is a hard constraint that must be satisfied during scheduling, ensuring the pod only runs on nodes with the required resource. Unlike `nodeSelector`, node affinity supports more expressive matching (e.g., `In`, `NotIn`, `Exists`) and can be combined with other scheduling constraints.

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

A developer wants to deploy a pod that will run only once to initialize a database schema. Which Kubernetes resource should they use?

Accepted Answer

Job. A Job is the correct Kubernetes resource for a one-time task that runs to completion, such as initializing a database schema. Unlike controllers that maintain a desired number of replicas, a Job creates one or more Pods and ensures they successfully terminate, making it ideal for batch or initialization workloads.

Answer

DaemonSet

Answer

Deployment

Answer

CronJob

Question 9

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. Option A is correct because `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 10

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