CKA Workloads & Scheduling Practice Test 1 — 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

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 3

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 4

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 5

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 6

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 7

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 8

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 9

A Deployment has replicas=3 and uses RollingUpdate with maxSurge=1 and maxUnavailable=1. During an update, one new Pod is created, and one old Pod is terminated. What is the total number of Pods during the update?

Accepted Answer

Between 2 and 4. During a RollingUpdate with replicas=3, maxSurge=1, and maxUnavailable=1, the total number of Pods is bounded by replicas - maxUnavailable = 2 and replicas + maxSurge = 4. The controller may create a new Pod before terminating an old one (resulting in 4 Pods), or terminate an old one before creating a new one (resulting in 2 Pods). At other points it can be 3. Therefore, the total can vary between 2 and 4.

Answer

Between 2 and 3

Answer

Exactly 4

Answer

Always 3

Question 10

Which TWO of the following are valid ways to restrict a Pod to run only on nodes with a specific label? (Select 2)

Accepted Answer

Specifying spec.nodeSelector in the Pod spec.. `spec.nodeSelector` is a simple, direct field in the Pod spec that constrains which nodes a Pod can be scheduled on based on node labels. When you specify a key-value pair in `nodeSelector`, the scheduler will only place the Pod on nodes that have that exact label, making it a valid method for restricting Pod placement.

Answer

Adding a toleration for a taint on the node.

Answer

Setting spec.nodeName to a node's name.

Answer

Using spec.affinity.podAffinity with requiredDuringScheduling.

Question 11

You are managing a production Kubernetes cluster with 10 worker nodes. A critical application runs as a Deployment with 5 replicas. The application requires low latency inter-Pod communication, so you want to ensure that all replicas are scheduled on the same node to avoid network overhead. You have created a podAntiAffinity rule with requiredDuringSchedulingIgnoredDuringExecution for the app label, but the scheduler only places 1 replica per node, resulting in Pods being distributed across multiple nodes. You need to modify the configuration so that all replicas are placed on a single node, if possible. Which action should you take?

Accepted Answer

Replace podAntiAffinity with podAffinity using requiredDuringSchedulingIgnoredDuringExecution for the app label.. PodAffinity with requiredDuringSchedulingIgnoredDuringExecution forces the scheduler to co-locate all Pods with the same app label on the same node. This directly overrides the default anti-affinity behavior that spreads Pods across nodes, ensuring low-latency inter-Pod communication by placing all replicas on a single node if possible.

Answer

Create a ResourceQuota to limit the number of Pods per namespace.

Answer

Add a toleration for a taint that is present on only one node.

Answer

Add a nodeSelector to the Pod spec to select a specific node.

Question 12

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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Add a nodeSelector with disk=ssd to the Pod spec.. A `nodeSelector` is a hard constraint that guarantees a Pod is scheduled only on nodes with the matching label. If Option B is changed to use `preferredDuringSchedulingIgnoredDuringExecution`, it becomes a soft preference and does not guarantee placement if no matching nodes are available. Option A bypasses the scheduler and requires a specific node name rather than a label. Option C (tolerations) only allows a pod to tolerate taints but does not force scheduling on a specific node.

Answer

Set nodeName in the Pod spec to the node name.

Answer

Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution and a matchExpression for disk=ssd.

Answer

Add a toleration for a taint that the node has.

Question 13

Which TWO of the following are valid ways to ensure that a Pod runs on a node that has a GPU? (Choose TWO.)

Accepted Answer

Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution matching a label that identifies GPU nodes.. Option B is correct because `nodeAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` ensures the scheduler only places the Pod on nodes matching the specified label (e.g., `gpu=true`). Option E is correct because requesting an extended resource like `nvidia.com/gpu` in the container's resource requests ensures the Kubernetes scheduler only schedules the Pod on a node that has advertised this resource capacity. Option A is incorrect because 'gpu' is not a valid extended resource name; extended resources must use a fully qualified domain name prefix (e.g., `nvidia.com/gpu`). Option C is incorrect because while `nodeName` bypasses scheduling to run on a specific node, it is not a scalable or standard way to target GPU-capable nodes, and if that specific node is unavailable, the Pod cannot run. Option D is incorrect because a toleration only allows a Pod to schedule onto a tainted node; it does not force the scheduler to choose that node, nor does it guarantee the node has a GPU.

Answer

Set resource requests for 'gpu' in the container spec.

Answer

Set nodeName to the name of a specific GPU node.

Answer

Add a toleration for a taint that GPU nodes have.

Question 14

Which THREE of the following are valid reasons for a Pod to be in Pending state? (Choose THREE.)

Accepted Answer

The node selector does not match any available node.. A Pod enters Pending state when it cannot be scheduled onto a node. Option A is correct because if the Pod's node selector specifies labels that no node in the cluster possesses, the scheduler cannot find a matching node, leaving the Pod unscheduled and in Pending state.

Answer

The Pod has a restartPolicy of OnFailure and the container exits with code 0.

Answer

The container image does not exist.

Question 15

Which TWO of the following statements about Kubernetes DaemonSets are correct?

Accepted Answer

DaemonSets can be updated using a rolling update strategy.. DaemonSets support a rolling update strategy via the `spec.updateStrategy.type: RollingUpdate` field. This allows you to update the Pod template (e.g., image or command) across all nodes in a controlled manner, with `maxUnavailable` and `maxSurge` parameters controlling the pace, ensuring minimal disruption to the daemon workload.

Answer

DaemonSets are used for stateless applications that require multiple replicas.

Answer

DaemonSets ignore taints and tolerations by default.

Answer

DaemonSets have a desired replica count that can be scaled independently.