CKA Workloads & Scheduling Practice Test 2 — 15 Questions

Question 1

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?

Accepted Answer

Add a label 'kubernetes.io/arch: amd64' to all amd64 nodes and use nodeSelector.. Option B is correct because the recommended way to constrain Pods to nodes with a specific architecture is to label those nodes (e.g., with `kubernetes.io/arch: amd64`) and then use `nodeSelector` in the Pod spec. This ensures the scheduler only places Pods on nodes matching the label, which is a simple, declarative, and Kubernetes-native approach. The Deployment does not specify any scheduling constraints, so adding `nodeSelector` is the best practice to enforce architecture-specific placement.

Answer

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

Answer

Use podAntiAffinity to avoid scheduling on arm64 nodes.

Answer

Set a runtimeClassName for amd64 in the Pod spec.

Question 2

A Pod with a restartPolicy of 'OnFailure' exits with code 0. What will happen?

Accepted Answer

The container will not restart, and the Pod will be in Succeeded phase.. When a Pod has a restartPolicy of 'OnFailure' and its container exits with code 0 (indicating successful completion), the container will not be restarted. Instead, the Pod transitions to the Succeeded phase, as defined by Kubernetes Pod lifecycle semantics. This is because 'OnFailure' only triggers a restart on a non-zero exit code, which signifies a failure.

Answer

The container will restart immediately.

Answer

The Pod will be terminated.

Answer

The Pod will remain in Running state.

Question 3

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

Question 4

A Kubernetes cluster has a node pool with GPU nodes labeled 'accelerator=nvidia-tesla'. A Pod requires a GPU. Which configuration is necessary?

Accepted Answer

Set nodeSelector to 'accelerator=nvidia-tesla' and request 'nvidia.com/gpu' in resources.. Option C is correct because a Pod that requires a GPU must both be scheduled onto a node with the appropriate GPU label and explicitly request the GPU resource. The `nodeSelector` ensures the Pod lands on a node labeled `accelerator=nvidia-tesla`, and requesting `nvidia.com/gpu` in `resources.requests` or `resources.limits` (typically limits) tells the kubelet to allocate a GPU device to the container. Without the resource request, the scheduler has no way to account for GPU capacity, and without the nodeSelector, the Pod might be scheduled on a non-GPU node.

Answer

Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for the GPU label.

Answer

Set resources.limits for 'nvidia.com/gpu' only.

Answer

Add a toleration for GPU node taints.

Question 5

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, the total number of Pods can vary between the desired replicas (3) and the desired replicas plus maxSurge (1), i.e., up to 4. With maxUnavailable=1, at least 2 Pods must be available. The update creates one new Pod before terminating one old Pod, so the total Pod count can be 3 (if the old Pod is terminated before the new one is ready) or 4 (if the new Pod is created before the old one is terminated). Thus, the range is between 2 and 4.

Answer

Between 2 and 3

Answer

Exactly 4

Answer

Always 3

Question 6

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

Which THREE of the following are valid considerations when using resource requests and limits? (Select 3)

Accepted Answer

Requests are used by the scheduler to decide which node can accommodate the Pod.. Option B is correct because the Kubernetes scheduler uses resource requests (CPU and memory) to determine node suitability for a Pod. The scheduler checks if the sum of requests for all Pods on a node, plus the new Pod's requests, is less than or equal to the node's allocatable capacity. Limits are not used for scheduling decisions.

Answer

Limits must be equal to requests for a Pod to be scheduled.

Answer

CPU limits guarantee the Pod will get that amount of CPU.

Question 8

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

A DevOps team wants to ensure that a critical application Pod is always scheduled on a node that has SSD storage. They have labeled one node with 'disk=ssd'. Which scheduling approach should they use to guarantee this placement?

Accepted Answer

Add a nodeSelector with disk=ssd to the Pod spec.. Option D is correct because a `nodeSelector` is the simplest and most direct way to guarantee that a Pod is scheduled only on nodes that have a specific label. By adding `nodeSelector: disk: ssd` to the Pod spec, Kubernetes will ensure the Pod is placed exclusively on nodes with the `disk=ssd` label, which matches the labeled node. This approach is straightforward and meets the requirement without additional complexity.

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 10

A Pod is in Pending state for a long time. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate'. What is the most likely issue?

Accepted Answer

The Pod does not have tolerations for the taints on the nodes.. The event '0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate' directly indicates that all nodes in the cluster have taints applied, and the Pod's spec does not include corresponding tolerations. Taints and tolerations work together to ensure that Pods are only scheduled onto nodes whose taints they tolerate; without matching tolerations, the scheduler will skip those nodes entirely, leaving the Pod in a Pending state.

Answer

The nodes do not have enough CPU or memory to run the Pod.

Answer

The nodes are not tainted, but the Pod has tolerations.

Answer

The scheduler is not running.

Question 11

A cluster administrator wants to ensure that a set of batch processing Pods are preemptible and should not cause disruption to other critical workloads. Which combination of scheduling features should be used?

Accepted Answer

Assign a low priority class to the batch Pods and set a PodDisruptionBudget for critical workloads.. Option B is correct because assigning a low priority class to batch Pods ensures they are preempted by higher-priority critical workloads when resources are scarce, while a PodDisruptionBudget (PDB) for critical workloads guarantees that a minimum number of those Pods remain available during voluntary disruptions (e.g., node drains). This combination allows batch Pods to be preemptible without causing disruption to critical workloads, aligning with the requirement.

Answer

Taint all worker nodes with a custom taint and add tolerations to batch Pods.

Answer

Use nodeAffinity to schedule batch Pods on dedicated nodes.

Answer

Use resource quotas to limit the batch Pods' resource consumption.

Question 12

A user creates a Deployment with replicas=3. Two Pods are running, but the third is stuck in ContainerCreating. 'kubectl describe pod' shows 'Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create containerd task: OCI runtime create failed: container_linux.go:349: starting container process caused: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

Accepted Answer

The container image does not have the /app executable at the specified path.. The error message 'exec: "/app": stat /app: no such file or directory' indicates that the container runtime (containerd) successfully created the sandbox and started the container process, but the command specified in the container's entrypoint or command tried to execute '/app', which does not exist inside the container image. This is a classic misconfiguration where the image lacks the expected binary or script at the given path, causing the container to fail immediately after creation.

Answer

The container image is not pulled due to authentication failure.

Answer

The container exceeds its memory limit and is killed.

Answer

The node is not schedulable due to taints.

Question 13

A Pod in a Deployment is CrashLoopBackOff. 'kubectl logs' shows the application exits with code 1 after printing one line. The Pod has a liveness probe that checks an HTTP endpoint. What should be checked first?

Accepted Answer

Check the application logs and configuration that causes the exit code 1.. The application exits with code 1 after printing one line, which indicates a runtime error in the application itself. The liveness probe only restarts the container after the application has already failed; it does not prevent the initial crash. Therefore, the first step is to examine the application logs and configuration to understand why the process exits with code 1, as this is the root cause of the CrashLoopBackOff.

Answer

Check if the liveness probe's initialDelaySeconds is too short.

Answer

Check if the liveness probe endpoint is correctly configured.

Answer

Check if the container has insufficient memory limits.

Question 14

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 allows you to schedule a Pod only onto nodes that match specific labels, such as a label like 'gpu=true' that identifies GPU-equipped nodes. This ensures the Pod is placed on a node with a GPU without relying on resource requests or taints.

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 15

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.