CCNA Workloads & Scheduling Questions

MCQeasy

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

A.The container will restart immediately.

B.The Pod will be terminated.

C.The Pod will remain in Running state.

D.The container will not restart, and the Pod will be in Succeeded phase.

AnswerD

With restartPolicy: OnFailure, an exit code of 0 means the container completed its workload successfully, so the kubelet deliberately avoids restarting it. Because all containers have exited with code 0 and no restart is warranted, the Pod's phase is set to Succeeded, which is the terminal state for successful Pod completion. This matches the expected behavior for batch or job-style workloads that should run to completion exactly once.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse 'OnFailure' with 'Always', assuming any exit triggers a restart, or they mistakenly think a Pod is 'terminated' (deleted) when it actually enters a terminal phase like Succeeded.

How to eliminate wrong answers

Option A is wrong because the container will restart only if the exit code is non-zero; exit code 0 indicates success, so no restart occurs. Option B is wrong because the Pod is not terminated; it enters the Succeeded phase, which is a terminal phase but not a termination of the Pod object itself. Option C is wrong because the Pod cannot remain in the Running state after the container exits; it must transition to a terminal phase (Succeeded or Failed) based on the exit code and restartPolicy.

Practice this question →

MCQmedium

You are a platform engineer managing a Kubernetes cluster with 5 worker nodes (node1-node5). The cluster runs a mix of stateless web services and stateful databases. Users report that a critical database Pod (part of a StatefulSet) is frequently evicted during node maintenance. The StatefulSet has a single replica. You need to improve the availability of this database Pod. The current configuration: the Pod has resource requests (2 CPU, 4Gi memory) and limits (4 CPU, 8Gi memory). The cluster uses the default scheduler with no custom policies. Nodes have varying capacities: node1 and node2 have 8 CPU/32Gi memory, node3-node5 have 4 CPU/16Gi memory. During rolling node reboots, the database Pod gets evicted and takes a long time to reschedule because no node has enough resources. What should you do to minimize downtime and ensure the Pod is rescheduled promptly after eviction?

A.Add nodeAffinity to prefer node1 and node2.

B.Create a PodDisruptionBudget with minAvailable: 1.

C.Assign a high priority class to the database Pod.

D.Increase the resource requests to match the limits.

AnswerC

Assigning a high priority class to the database Pod is the most effective solution for ensuring critical workloads are scheduled promptly. When the scheduler attempts to place a high-priority Pod and cannot find a node with sufficient resources, it will actively preempt (evict) lower-priority Pods from existing nodes to free up the necessary capacity. This mechanism directly addresses resource contention, significantly reducing the scheduling delay for essential applications like a database.

Why this answer

Assigning a high priority class (Option C) ensures that when the database Pod is evicted during node maintenance, the scheduler treats it as a higher-priority workload than other Pods. This allows it to preempt lower-priority Pods on nodes with sufficient capacity (e.g., node1 or node2), even if those nodes appear fully allocated, thereby minimizing downtime and ensuring prompt rescheduling.

Exam trap

CNCF often tests the distinction between disruption budgets (which prevent eviction) and priority/preemption (which ensure rescheduling after eviction), leading candidates to mistakenly choose PDB when the real issue is resource contention after eviction.

How to eliminate wrong answers

Option A is wrong because nodeAffinity with a 'prefer' rule is a soft scheduling preference, not a guarantee; during eviction, the scheduler may still place the Pod on a smaller node if node1/node2 are full, leading to scheduling failures. Option B is wrong because a PodDisruptionBudget (PDB) with minAvailable: 1 only protects against voluntary disruptions (e.g., node drains) by preventing eviction if it would violate the budget, but it does not help with resource availability after eviction; the Pod still cannot be scheduled if no node has enough free resources. Option D is wrong because increasing resource requests to match limits (4 CPU, 8Gi memory) would make the Pod even harder to schedule, as it would require more resources than the smaller nodes (node3-node5) can provide, worsening the problem.

Practice this question →

MCQhard

You are managing a Kubernetes cluster that hosts a microservices application. One of the services, 'payment-processor', is critical and must always be available. It has a Deployment with 3 replicas, each requesting 1 CPU and 2Gi memory. Recently, the team added a new service 'data-analyzer' that runs as a DaemonSet on all nodes, consuming significant CPU and memory. After the addition, you notice that 'payment-processor' pods are occasionally being evicted, and new pods are slow to be scheduled. You check node resource usage and find that some nodes are overcommitted. You want to ensure that 'payment-processor' pods are never evicted and are scheduled before less critical workloads. Which action should you take?

A.Add a taint to nodes that have low resources and add tolerations only to 'payment-processor' pods

B.Increase the resource requests for 'payment-processor' pods to guarantee resources

C.Create a PriorityClass with a high value and assign it to the 'payment-processor' Deployment

D.Use node affinity to ensure 'payment-processor' pods run on dedicated nodes

AnswerC

Creating a PriorityClass with a high integer value and assigning it to the 'payment-processor' Deployment is the most effective solution. Pods with higher priority are preferentially scheduled by the kube-scheduler. Crucially, if a high-priority 'payment-processor' pod cannot be scheduled due to insufficient resources on any node, the scheduler will attempt to preempt (evict) lower-priority pods on suitable nodes to free up the necessary resources, thereby ensuring the critical workload runs.

Why this answer

PriorityClass with a high value ensures that 'payment-processor' pods are considered higher priority than other pods during scheduling and eviction. When nodes are overcommitted, the Kubernetes scheduler will preempt lower-priority pods to make room for higher-priority pods, and the kubelet will evict lower-priority pods first when resources are scarce. This directly addresses the requirement that 'payment-processor' pods are never evicted and are scheduled before less critical workloads.

Exam trap

The trap here is that candidates often confuse taints/tolerations or node affinity with priority and preemption, but those features only affect scheduling placement, not eviction ordering or preemption behavior.

How to eliminate wrong answers

Option A is wrong because taints and tolerations control which pods can be scheduled on a node, but they do not provide a mechanism for eviction priority or guarantee that 'payment-processor' pods will be scheduled before other pods on the same node; taints only repel pods without tolerations, and adding tolerations to 'payment-processor' would allow them to schedule on tainted nodes but not prevent eviction. Option B is wrong because increasing resource requests for 'payment-processor' pods would require more resources to schedule them, potentially making scheduling harder, and it does not affect eviction ordering; requests only affect scheduling decisions, not eviction priority. Option D is wrong because node affinity only influences scheduling placement, not eviction behavior; it can ensure pods run on specific nodes but does not prevent eviction when those nodes are overcommitted, nor does it prioritize scheduling over other workloads.

Practice this question →

Drag & Dropmedium

Drag and drop the steps to troubleshoot a Node that is in NotReady state into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Start with kubectl to identify the node, then SSH, check kubelet and runtime, review logs, then restart.

Practice this question →

MCQeasy

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

A.DaemonSet

B.Job

C.Deployment

D.CronJob

AnswerB

A Job controller creates one or more pods and tracks them until a specified number successfully terminate. For a one-time task, a simple Job with default completions=1 runs once to completion, and the workload is not recreated if it exits with code 0. It is the native Kubernetes API for exactly-once batch processing.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse a Job with a CronJob, thinking they need scheduling, or with a Deployment, assuming all workloads must be continuously running, when the key differentiator is the 'run to completion' lifecycle.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, which is designed for continuous daemon processes like logging or monitoring, not a one-time initialization task. Option C is wrong because a Deployment manages a set of Pods to maintain a desired state with rolling updates and self-healing, intended for long-running stateless applications, not a single run-to-completion job. Option D is wrong because a CronJob is used for scheduling Jobs to run at specific times or intervals, which is overkill and incorrect for a task that should run only once immediately.

Practice this question →

Multi-Selecthard

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

Select 3 answers

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

B.Requests are used by the scheduler to decide which node can accommodate the Pod.

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

D.The QoS class is determined based on requests and limits.

E.Memory limits can cause the Pod to be OOMKilled if exceeded.

AnswersB, D, E

During scheduling, kube-scheduler evaluates each candidate node by subtracting the sum of container requests for CPU and memory from the node's allocatable capacity. A node is deemed feasible only if it can satisfy all requested quantities, because requests represent the minimum resource reservation needed to run the Pod. Limits are deliberately ignored in this admission calculation, making requests the primary input for node fit decisions.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse CPU limits as a guarantee of CPU allocation, when in fact CPU is compressible and limits only throttle usage, while memory limits are hard and can cause OOM kills.

Practice this question →

MCQhard

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

A.Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for the GPU label.

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

C.Set nodeSelector to 'accelerator=nvidia-tesla' and request 'nvidia.com/gpu' in resources.

D.Add a toleration for GPU node taints.

AnswerC

This is the correct and comprehensive approach because it addresses both the placement of the Pod and the allocation of the specialized hardware resource. The `nodeSelector` ensures the Pod is scheduled exclusively onto nodes labeled `accelerator=nvidia-tesla`, which are the GPU-equipped nodes in this scenario. Simultaneously, requesting `nvidia.com/gpu` in the Pod's `resources` section (either `requests` or `limits`) informs the Kubernetes device plugin for NVIDIA GPUs to allocate a specific GPU device to the container, making it available inside the Pod. Both mechanisms are crucial for successful GPU workload deployment.

Why this answer

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.

Exam trap

The trap here is that candidates often think either node selection (nodeSelector/affinity) or resource requests alone is sufficient, but the CKA exam requires both to be present for a GPU workload to function correctly.

How to eliminate wrong answers

Option A is wrong because `nodeAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` is a valid way to select GPU nodes, but it is not sufficient on its own — the Pod must also request the `nvidia.com/gpu` resource to actually get a GPU assigned. Option B is wrong because setting `resources.limits` for `nvidia.com/gpu` alone does not guarantee the Pod lands on a GPU node; without a nodeSelector or affinity, the scheduler may place the Pod on a non-GPU node where the resource is unavailable. Option D is wrong because GPU nodes do not inherently have taints; while administrators may add taints to GPU nodes, a toleration is only needed if a taint is present, and it is not a required configuration for GPU access.

Practice this question →