Courseiva

CCNA Workloads & Scheduling Questions

39 questions · Workloads & Scheduling · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

You are managing a Kubernetes cluster with three worker nodes. A deployment named 'frontend' is configured with 3 replicas. After a node failure, you notice that only 2 pods are running, and the third pod is stuck in 'Pending' state. The remaining nodes have sufficient CPU and memory. You check the deployment events and find no errors. You also verify that the PersistentVolumeClaims (PVCs) used by the deployment are bound. What is the most likely reason the third pod is not scheduled?

A.The ReplicaSet controller is not creating a new pod because the deployment's progressDeadlineSeconds has expired.
B.The PersistentVolumeClaims are using 'WaitForFirstConsumer' binding mode and the pod is pending because the volume is not yet bound.
C.The kube-scheduler is down or misconfigured.
D.The pod has a nodeSelector that only matches the failed node.
AnswerD

The pod cannot be scheduled on other nodes because it requires a specific label that only the failed node has.

Why this answer

Option D is correct because a nodeSelector that exclusively matches the failed node would prevent the scheduler from placing the pod on any other node, even if those nodes have sufficient resources. Since the failed node is unavailable, the pod remains in 'Pending' state indefinitely, as no other node satisfies the constraint.

Exam trap

The trap here is that candidates assume resource constraints or scheduler failures are the default cause for pending pods, overlooking that a nodeSelector or affinity rule can silently prevent scheduling even when resources are abundant.

How to eliminate wrong answers

Option A is wrong because progressDeadlineSeconds only triggers a deployment rollout failure (marking the deployment as progressing false) but does not prevent the ReplicaSet from creating or scheduling pods; it is a rollout health check, not a scheduling blocker. Option B is wrong because the PVCs are already bound (as stated), so 'WaitForFirstConsumer' would cause the volume to bind only after scheduling, but the pod would still be pending due to volume binding, not because the volume is unbound—the scenario says PVCs are bound, eliminating this. Option C is wrong because if the kube-scheduler were down or misconfigured, all pods would be stuck in 'Pending', not just one; the fact that two pods are running indicates the scheduler is functional.

Practice this question →
2
MCQeasy

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

A.Add a taint to the master node
B.Delete the master node from the cluster
C.Use a resource quota on the master namespace
D.Set nodeSelector on the master node
AnswerA

The master node already has a NoSchedule taint by default.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse `nodeSelector` (a pod scheduling constraint) with node-level restrictions, or think that deleting a node or using resource quotas can control scheduling to a specific node, when only taints (or node affinity with requiredDuringSchedulingIgnoredDuringExecution) provide that node-level control.

How to eliminate wrong answers

Option B is wrong because deleting the master node from the cluster would remove the control plane, making the cluster non-functional; the goal is to prevent pod scheduling, not to remove the node entirely. Option C is wrong because a resource quota on a namespace (e.g., 'master' namespace) limits resource consumption but does not prevent pods from being scheduled onto a specific node; pods could still be placed on the master node from any namespace. Option D is wrong because `nodeSelector` is used to constrain which nodes a pod can be scheduled on, but it is a pod-level attribute, not a node-level restriction; setting it on the master node itself is not a valid operation and does not prevent other pods from being scheduled there.

Practice this question →
3
MCQmedium

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?

A.Pod priority and preemption
B.Taints and tolerations
C.Node affinity
D.Resource quotas
AnswerC

Node affinity allows a pod to express preferences or requirements for node selection based on labels.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse taints and tolerations with node affinity, mistakenly thinking taints can attract pods to specific nodes, when in fact taints repel pods and tolerations only allow them to be scheduled on tainted nodes, not actively direct them there.

How to eliminate wrong answers

Option A is wrong because pod priority and preemption determines the scheduling precedence and can evict lower-priority pods, but it does not constrain pods to specific nodes based on hardware characteristics. Option B is wrong because taints and tolerations prevent pods from being scheduled on nodes unless they tolerate the taint, which is used to repel pods, not to attract them to specific nodes; they work in the opposite direction of node affinity. Option D is wrong because resource quotas limit the total resource consumption per namespace, but they do not influence node-level placement or enforce scheduling on dedicated hardware.

Practice this question →
4
MCQmedium

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

A.Use podAffinity to prefer nodes running other Pods.
B.Set spec.nodeName to an SSD node's name.
C.Add a taint to nodes without SSD and add a toleration to the Pod.
D.Label SSD nodes with 'disk=ssd' and use nodeSelector in the Pod spec.
AnswerD

NodeSelector ensures the Pod is scheduled only on nodes with the label.

Why this answer

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

Exam trap

The trap here is that candidates often confuse taints and tolerations with node selection, thinking they can force a Pod onto a specific node type, when in fact taints only repel Pods from nodes and require tolerations to allow scheduling, not to guarantee placement on a desired node.

How to eliminate wrong answers

Option A is wrong because podAffinity is used to schedule Pods relative to other Pods (e.g., co-location), not to select nodes based on hardware characteristics like SSD presence. Option B is wrong because setting spec.nodeName bypasses the scheduler entirely and directly assigns the Pod to a specific node by name, which is inflexible and does not scale; it also requires manual knowledge of the node name and does not use labels or taints for dynamic selection. Option C is wrong because adding a taint to nodes without SSD would repel Pods that do not tolerate that taint, but the Pod would need a toleration to run on those nodes; this approach would prevent the Pod from running on non-SSD nodes but does not actively ensure it runs on an SSD node—it could still be scheduled on any node without the taint, including those without SSD if they are not tainted.

Practice this question →
5
MCQhard

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?

A.Taint all worker nodes with a custom taint and add tolerations to batch Pods.
B.Assign a low priority class to the batch Pods and set a PodDisruptionBudget for critical workloads.
C.Use nodeAffinity to schedule batch Pods on dedicated nodes.
D.Use resource quotas to limit the batch Pods' resource consumption.
AnswerB

Low priority allows preemption, and PDB prevents excessive disruption to critical Pods.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse taints/tolerations or node affinity with preemption and disruption protection, failing to realize that only priority classes enable preemption and PDBs control voluntary disruptions.

How to eliminate wrong answers

Option A is wrong because tainting worker nodes with a custom taint and adding tolerations to batch Pods only prevents other Pods from scheduling on those nodes unless they have the toleration; it does not make batch Pods preemptible or protect critical workloads from disruption. Option C is wrong because using nodeAffinity to schedule batch Pods on dedicated nodes isolates them but does not provide preemption capability or disruption protection for critical workloads; dedicated nodes can still be disrupted by node failures or maintenance. Option D is wrong because resource quotas limit the total resource consumption of batch Pods but do not make them preemptible or prevent disruption to critical workloads; quotas only enforce resource caps, not scheduling priority or availability guarantees.

Practice this question →
6
MCQeasy

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?

A.The deployment has a resource quota that prevents new pods
B.The pod's terminationGracePeriodSeconds is set to 0
C.The node controller has not yet evicted the pod
D.The deployment's replicas field is set to 2
AnswerC

The node controller waits for a default of 5 minutes before evicting pods from a failed node.

Why this answer

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.

Exam trap

The trap here is that candidates assume a deployment immediately reschedules pods after a node failure, but the CKA tests knowledge of the node controller's eviction timeout and the fact that the ReplicaSet controller waits for pod eviction before creating replacements.

How to eliminate wrong answers

Option A is wrong because a resource quota would cause a failure to create a new pod (with an error event), not prevent the deployment from attempting rescheduling; the deployment would still try and fail, but the question states it has not rescheduled the missing pod. Option B is wrong because `terminationGracePeriodSeconds` affects how long a pod is given to shut down gracefully after a deletion request, not the node controller's eviction timeout or the deployment's rescheduling logic. Option D is wrong because if the deployment's `replicas` field were set to 2, the deployment would be satisfied with 2 running pods and would not attempt to reschedule; however, the question states the deployment originally had 3 replicas, so this would be a configuration change, not a transient failure scenario.

Practice this question →
7
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

Exit code 0 indicates success; no restart.

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 →
8
Drag & Dropmedium

Drag and drop the steps to troubleshoot a CrashLoopBackOff pod into the correct order.

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

Steps
Order

Why this order

Start with logs to see application errors, then describe for configuration details, check events for cluster-level issues, review spec, then fix.

Practice this question →
9
Multi-Selecteasy

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

Select 2 answers
A.The application is a batch job that should run to completion
B.The application requires unique network identities (e.g., hostnames)
C.The application needs to run on all nodes in the cluster
D.The application is stateless and can be scaled arbitrarily
E.The application requires stable persistent storage that persists across pod rescheduling
AnswersB, E

StatefulSet provides stable network identities.

Why this answer

Option B is correct because StatefulSets assign each pod a unique, stable network identity (e.g., a hostname like 'web-0', 'web-1') derived from the StatefulSet's name and an ordinal index. This is essential for applications like databases (e.g., Cassandra, ZooKeeper) that rely on consistent hostnames for cluster membership and discovery. Deployments, in contrast, generate random pod names and do not guarantee stable network identities.

Exam trap

The trap here is that candidates often confuse the need for stable storage (Option E) with the need for stable network identities (Option B), or they mistakenly think a StatefulSet is required for any application that uses persistent volumes, when in fact a Deployment with a PersistentVolumeClaim can also provide stable storage if the pod is recreated on the same node; the key differentiator is the unique, ordinal-based network identity and ordered pod management that only a StatefulSet provides.

Practice this question →
10
MCQhard

You are tasked with ensuring that a critical application runs on a specific node that has dedicated hardware. The node is labeled with 'hw=special'. You want to guarantee that only pods from this application are scheduled on that node, and no other pods can use it. Which scheduling feature should you use?

A.Use taints and tolerations
B.Use pod affinity with a requiredDuringSchedulingIgnoredDuringExecution rule
C.Use node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule
D.Use a nodeSelector with a matchExpressions constraint
AnswerC

Node affinity with a required rule forces the pod to nodes matching the label, and combined with taints/tolerations can achieve exclusivity. It is the primary feature for hard scheduling constraints.

Why this answer

Option C is correct because node affinity with a `requiredDuringSchedulingIgnoredDuringExecution` rule ensures that a pod is scheduled only on nodes matching the specified label (e.g., `hw=special`). This is the appropriate feature to guarantee that only pods from this application are scheduled on that specific node, as it restricts scheduling to that node while also preventing other pods from using it if combined with taints and tolerations. However, to fully prevent other pods from using the node, you must also taint the node; node affinity alone only ensures the pod goes to that node, but does not block other pods.

Exam trap

The trap here is that candidates often confuse node affinity with taints and tolerations, thinking that node affinity alone can prevent other pods from using the node, when in fact it only ensures the pod is placed on the node but does not repel other pods; taints and tolerations are needed for that exclusivity.

How to eliminate wrong answers

Option A is wrong because taints and tolerations are used to repel pods from nodes unless they tolerate the taint, but they do not guarantee that a pod will be scheduled on a specific node; they only prevent pods without the toleration from being scheduled there. Option B is wrong because pod affinity is used to co-locate pods relative to each other (e.g., schedule a pod near another pod), not to constrain pods to a specific node based on node labels. Option D is wrong because `nodeSelector` with `matchExpressions` is a simpler form of node affinity that can select nodes based on labels, but it does not provide the full `requiredDuringSchedulingIgnoredDuringExecution` semantics and is less flexible; more importantly, `nodeSelector` alone does not prevent other pods from using the node, just as node affinity alone does not.

Practice this question →
11
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

High priority ensures the scheduler preempts lower-priority Pods to make room for the database Pod, reducing scheduling delay.

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 →
12
MCQmedium

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?

A.Frontend: Deployment, Service (NodePort); Backend: Deployment, Service (ClusterIP); no NetworkPolicy
B.Frontend: Deployment, Service (ClusterIP); Backend: Deployment, Service (ClusterIP); NetworkPolicy to allow ingress from frontend namespace
C.Frontend: Deployment, Service (LoadBalancer); Backend: Deployment, Service (LoadBalancer); NetworkPolicy to allow only frontend to backend
D.Frontend: Deployment, Service (LoadBalancer); Backend: Deployment, Service (ClusterIP); NetworkPolicy to allow ingress from frontend namespace and deny others
AnswerD

LoadBalancer exposes frontend externally, ClusterIP for internal backend, and NetworkPolicy restricts backend access.

Why this answer

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

Exam trap

The trap here is that candidates often forget that a ClusterIP Service cannot be accessed from outside the cluster, and they may incorrectly choose a LoadBalancer or NodePort for the backend, or omit the NetworkPolicy needed to enforce isolation.

How to eliminate wrong answers

Option A is wrong because it uses a NodePort Service for the frontend, which exposes the frontend on a high port on every node but does not provide a stable external endpoint like a LoadBalancer, and it lacks a NetworkPolicy to isolate the backend. Option B is wrong because it uses a ClusterIP Service for the frontend, which does not make the frontend accessible from outside the cluster, violating the requirement. Option C is wrong because it uses a LoadBalancer Service for the backend, which exposes the backend externally, contradicting the requirement that the backend should only be accessible from within the cluster.

Practice this question →
13
Matchingmedium

Match each troubleshooting scenario to its likely cause.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Insufficient resources or unschedulable Node

Application crashes repeatedly

Missing or incorrect Endpoint selector labels

Kubelet not reporting or network issue

Invalid image name or registry authentication failure

Why these pairings

Common cluster issues require systematic debugging.

Practice this question →
14
MCQeasy

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?

A.The nodes do not have enough CPU or memory to run the Pod.
B.The Pod does not have tolerations for the taints on the nodes.
C.The nodes are not tainted, but the Pod has tolerations.
D.The scheduler is not running.
AnswerB

The error message directly indicates that the Pod cannot tolerate the node taints.

Why this answer

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.

Exam trap

CNCF often tests the distinction between taints/tolerations and resource constraints, so candidates may incorrectly assume the error is about resource exhaustion when the event message explicitly mentions taints.

How to eliminate wrong answers

Option A is wrong because insufficient CPU or memory would produce a different event, such as 'Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option C is wrong because if nodes are not tainted, the Pod would be scheduled normally regardless of tolerations; the event explicitly states nodes had taints, so this scenario contradicts the observed error. Option D is wrong because if the scheduler were not running, the Pod would remain in Pending state without any scheduling events at all, and 'kubectl describe pod' would not show taint-related messages.

Practice this question →
15
Multi-Selectmedium

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

Select 2 answers
A.Adding a toleration for a taint on the node.
B.Specifying spec.nodeSelector in the Pod spec.
C.Using spec.affinity.nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution.
D.Setting spec.nodeName to a node's name.
E.Using spec.affinity.podAffinity with requiredDuringScheduling.
AnswersB, C

NodeSelector constrains Pods to nodes with matching labels.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse tolerations (which allow scheduling on tainted nodes) with node selectors or node affinity (which restrict scheduling to labeled nodes), leading them to incorrectly select option A as a valid restriction method.

Practice this question →
16
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

High priority ensures that 'payment-processor' pods are scheduled before lower priority pods and can preempt them if necessary.

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 →
17
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

Why this order

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

Practice this question →
18
Multi-Selecthard

Which THREE of the following are characteristics of DaemonSets?

Select 3 answers
A.A DaemonSet runs exactly one pod per node
B.DaemonSets support rolling updates
C.DaemonSets can be scaled down by reducing the number of replicas
D.DaemonSets can be scheduled on specific nodes using nodeSelector
E.A DaemonSet can be used to run a batch job that completes
AnswersA, B, D

DaemonSet ensures one pod per node.

Why this answer

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.

Exam trap

CNCF often tests the misconception that DaemonSets can be scaled by adjusting a replica count, similar to Deployments, but the correct behavior is that DaemonSets are node-driven, not replica-driven.

Practice this question →
19
Multi-Selectmedium

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

Select 3 answers
A.The node selector does not match any available node.
B.The PersistentVolumeClaim used by the Pod is not bound.
C.The cluster does not have enough resources to schedule the Pod.
D.The Pod has a restartPolicy of OnFailure and the container exits with code 0.
E.The container image does not exist.
AnswersA, B, C

If no node matches the nodeSelector, the Pod remains unscheduled.

Why this answer

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.

Exam trap

CNCF often tests the distinction between scheduling failures (Pending) and runtime failures (ImagePullBackOff, CrashLoopBackOff), so candidates may mistakenly think a missing image causes Pending instead of the correct ImagePullBackOff state.

Practice this question →
20
Multi-Selectmedium

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

Select 2 answers
A.DaemonSets are used for stateless applications that require multiple replicas.
B.DaemonSets can be updated using a rolling update strategy.
C.DaemonSets ignore taints and tolerations by default.
D.DaemonSets have a desired replica count that can be scaled independently.
E.DaemonSets ensure that a copy of a Pod runs on all or a subset of Nodes.
AnswersB, E

DaemonSets support RollingUpdate and OnDelete update strategies.

Why this answer

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

Exam trap

The trap here is that candidates confuse DaemonSets with Deployments or StatefulSets, assuming they can be scaled manually via `replicas`, or they forget that DaemonSets respect taints and tolerations like any other Pod, leading them to incorrectly select options C or D.

Practice this question →
21
MCQhard

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?

A.Add a toleration for 'arch=amd64:NoSchedule' to the Pod.
B.Add a label 'kubernetes.io/arch: amd64' to all amd64 nodes and use nodeSelector.
C.Use podAntiAffinity to avoid scheduling on arm64 nodes.
D.Set a runtimeClassName for amd64 in the Pod spec.
AnswerB

Nodes already have the kubernetes.io/arch label; using nodeSelector with that label is correct.

Why this answer

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.

Exam trap

The trap here is that candidates confuse tolerations (which handle taints) with node selection (which uses labels and nodeSelector), leading them to pick Option A, even though tolerations alone do not restrict scheduling to specific architectures.

How to eliminate wrong answers

Option A is wrong because tolerations are used to allow Pods to be scheduled on nodes with taints, not to select nodes based on labels or architecture; a toleration for 'arch=amd64:NoSchedule' would only permit scheduling on nodes tainted with that effect, but it does not prevent scheduling on arm64 nodes. Option C is wrong because podAntiAffinity controls Pod placement relative to other Pods (e.g., spreading or co-locating), not node-level attributes like architecture; it cannot directly exclude arm64 nodes. Option D is wrong because `runtimeClassName` specifies a container runtime (e.g., gVisor, runc) and has no relation to node CPU architecture; it does not influence scheduling decisions.

Practice this question →
22
Multi-Selectmedium

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').

Select 2 answers
A.Use nodeSelector with the zone label
B.Use node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule matching the zone label
C.Use a toleration for a taint that exists only on nodes in the zone
D.Use pod affinity to attract pods to nodes in that zone
E.Set spec.nodeName to the name of a node in the zone
AnswersA, B

nodeSelector directly selects nodes with the matching label.

Why this answer

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.

Exam trap

The trap here is that candidates confuse tolerations (which only allow scheduling on tainted nodes) with node selectors or affinity (which actively constrain scheduling), or they mistakenly think pod affinity can target node labels instead of pod labels.

Practice this question →
23
MCQmedium

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

A.Job
B.DaemonSet
C.CronJob
D.Deployment
AnswerA

A Job runs until completion and is suitable for batch processing.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse a CronJob with a Job, thinking that a CronJob can also run a one-time task, but CronJob is specifically for scheduled, recurring execution, not a single run-to-completion workload.

How to eliminate wrong answers

Option B (DaemonSet) is wrong because it ensures that a copy of a pod runs on every node (or a subset of nodes) in the cluster, continuously, not for a one-time batch job. Option C (CronJob) is wrong because it creates Jobs on a recurring schedule; while it could run a batch job, it is intended for periodic execution, not a single run-to-completion task. Option D (Deployment) is wrong because it manages a set of identical pods with a desired replica count, ensuring they are always running and self-healing, which is the opposite of a run-to-completion workload.

Practice this question →
24
MCQmedium

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?

A.Set nodeName in the Pod spec to the node name.
B.Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution and a matchExpression for disk=ssd.
C.Add a toleration for a taint that the node has.
D.Add a nodeSelector with disk=ssd to the Pod spec.
AnswerD

nodeSelector is the simplest way to enforce scheduling on nodes with a specific label.

Why this answer

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.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing `nodeAffinity` (option B) because it is more powerful, but the question asks for the simplest approach to guarantee placement, and `nodeSelector` is the correct and sufficient answer for a single label match.

How to eliminate wrong answers

Option A is wrong because `nodeName` bypasses the scheduler entirely and directly assigns the Pod to a specific node by name, which is inflexible and does not leverage the label-based selection; it also fails if the node name changes or is unknown. Option B is wrong because `nodeAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` can also guarantee placement on labeled nodes, but it is more complex than necessary for this simple label match and is not the simplest approach; the question asks for the approach to 'guarantee this placement,' and while it works, `nodeSelector` is the canonical and simpler method. Option C is wrong because tolerations are used to allow Pods to be scheduled on tainted nodes, not to enforce placement on nodes with specific labels; they do not guarantee placement on a labeled node unless combined with other mechanisms like node affinity or nodeSelector.

Practice this question →
25
MCQmedium

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?

A.Taint on non-GPU nodes and toleration on the pod
B.Pod affinity to prefer GPU nodes
C.Node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule for gpu=true
D.nodeSelector with gpu=true
AnswerD

nodeSelector directly matches the label gpu=true.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse taints/tolerations (which repel pods) with node affinity or nodeSelector (which attract pods to specific nodes), leading them to pick Option A when the requirement is to ensure a pod runs on a GPU node, not to prevent it from running on non-GPU nodes.

How to eliminate wrong answers

Option A is wrong because taints and tolerations are used to repel pods from nodes (or allow them to be scheduled on tainted nodes), not to attract pods to nodes with a specific label; they would prevent pods without the toleration from running on non-GPU nodes but do not actively ensure the pod lands on a GPU node. Option B is wrong because pod affinity is used to co-locate pods relative to each other (e.g., schedule this pod near another pod), not to match node labels like GPU availability. Option C is wrong because while node affinity with `requiredDuringSchedulingIgnoredDuringExecution` can achieve the same goal as `nodeSelector`, it is more complex and verbose for a simple label match; `nodeSelector` is the recommended approach for this exact use case per Kubernetes documentation.

Practice this question →
26
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

Job runs a pod to successful completion.

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 →
27
MCQmedium

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?

A.Check the application logs and configuration that causes the exit code 1.
B.Check if the liveness probe's initialDelaySeconds is too short.
C.Check if the liveness probe endpoint is correctly configured.
D.Check if the container has insufficient memory limits.
AnswerA

The application is crashing due to its own logic; logs should indicate the error.

Why this answer

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.

Exam trap

The trap here is that candidates often focus on the liveness probe configuration (options B and C) because the question mentions it, but the immediate cause is the application crash itself, which must be diagnosed first via logs.

How to eliminate wrong answers

Option B is wrong because adjusting initialDelaySeconds would only delay the start of liveness checks; it does not address the application exiting with code 1. Option C is wrong because the liveness probe endpoint configuration is irrelevant when the application crashes before the probe can even be evaluated. Option D is wrong because insufficient memory limits typically cause OOMKilled (exit code 137) or resource pressure, not a clean exit code 1 after printing one line.

Practice this question →
28
MCQmedium

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?

A.Between 2 and 3
B.Exactly 4
C.Between 2 and 4
D.Always 3
AnswerC

Correct range due to surge and unavailable.

Why this answer

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.

Exam trap

The trap here is that candidates often assume the total Pod count remains constant at the desired replicas, ignoring that maxSurge allows temporary overshoot, leading them to pick 'Always 3' or 'Exactly 4' instead of the correct range.

How to eliminate wrong answers

Option A is wrong because the total number of Pods can be 4, not just between 2 and 3. Option B is wrong because the total number of Pods is not always exactly 4; it can be 3 or 4 depending on the order of creation and termination. Option D is wrong because the total number of Pods is not always 3; it can temporarily be 4 due to maxSurge=1.

Practice this question →
29
MCQmedium

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?

A.Use node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule
B.Define a nodeSelector in the pod spec
C.Assign the pod a high priority so it gets scheduled on any node
D.Use pod anti-affinity to avoid nodes without the resource
AnswerA

This guarantees the pod is scheduled only on nodes matching the label.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with node affinity, thinking both are equally capable for custom resource matching, but `nodeSelector` cannot handle existence-based checks (e.g., label presence without a value) which is common for custom resources like license dongles.

How to eliminate wrong answers

Option B is wrong because `nodeSelector` is a simpler, less expressive mechanism that only supports exact label matching (e.g., `key=value`), and it cannot handle complex conditions like checking for the existence of a label without a specific value, which is often needed for custom resources. Option C is wrong because assigning a high priority only affects the pod's scheduling order and preemption behavior, but it does not constrain the pod to nodes with the specific resource; the pod could still be scheduled on any node that meets other requirements. Option D is wrong because pod anti-affinity is used to prevent pods from being scheduled on the same node (or topology) as other pods, not to enforce placement on nodes with a specific resource; it addresses co-location constraints, not node-level resource availability.

Practice this question →
30
MCQhard

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?

A.The pod has resource requests that exceed available capacity
B.The pod does not have tolerations for the node taints
C.The nodes are cordoned
D.The kube-scheduler is not running
AnswerB

The events explicitly mention taints, indicating missing tolerations.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse taint-based scheduling failures with resource insufficiency or node cordoning, but the specific taint names in the event message directly point to node health issues rather than capacity or manual unschedulability.

How to eliminate wrong answers

Option A is wrong because resource requests exceeding capacity would produce events like 'Insufficient cpu' or 'Insufficient memory', not taint-based messages. Option C is wrong because cordoned nodes show 'node.kubernetes.io/unschedulable:NoSchedule' taint, not 'unreachable' or 'not-ready'. Option D is wrong because if the kube-scheduler were not running, the pod would remain in 'Pending' with no scheduling events at all, not specific taint-related messages.

Practice this question →
31
MCQeasy

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?

A.The container image is not pulled due to authentication failure.
B.The container exceeds its memory limit and is killed.
C.The node is not schedulable due to taints.
D.The container image does not have the /app executable at the specified path.
AnswerD

The error clearly states the executable /app is not found, indicating a misconfigured command or missing binary.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse a 'ContainerCreating' status with image pull issues or resource limits, but the specific OCI runtime exec error points directly to a missing executable in the container image, not to infrastructure or scheduling problems.

How to eliminate wrong answers

Option A is wrong because an authentication failure would produce an 'ImagePullBackOff' or 'ErrImagePull' status, not a 'ContainerCreating' state with an OCI runtime exec error. Option B is wrong because exceeding the memory limit results in an OOMKilled container (status 'OOMKilled'), not a failure to start the container process with a 'no such file or directory' error. Option C is wrong because taints cause the pod to remain in 'Pending' state (not 'ContainerCreating'), and the error message is about container runtime execution, not scheduling.

Practice this question →
32
Multi-Selectmedium

Which TWO statements about Kubernetes pod lifecycle and scheduling are correct? (Select two.)

Select 2 answers
A.Init containers always run before app containers and must complete successfully for the pod to start.
B.A pod with a nodeSelector that does not match any node will be evicted from the cluster.
C.If a pod with higher priority is pending and there are no resources, it will preempt pods with equal or lower priority.
D.Static pods are created by the API server based on a manifest file in the kubelet's manifest directory.
E.DaemonSet pods are scheduled on all nodes, including nodes that are tainted, as long as the pod tolerates the taint.
AnswersA, E

Init containers run sequentially and must finish before app containers start.

Why this answer

Init containers are specialized containers that run before any app containers in a pod. They must complete successfully (exit with code 0) before the pod's app containers are started. If an init container fails, Kubernetes restarts it until it succeeds, and the pod will not enter the Running phase until all init containers have succeeded.

This is defined in the pod spec under `initContainers` and is a core mechanism for setup tasks like waiting for a service or database to be ready.

Exam trap

CNCF often tests the distinction between static pods (kubelet-created) and regular pods (API server-created), and the trap here is that candidates confuse the kubelet's manifest directory with the API server's pod creation mechanism.

Practice this question →
33
MCQhard

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?

A.Replace podAntiAffinity with podAffinity using requiredDuringSchedulingIgnoredDuringExecution for the app label.
B.Create a ResourceQuota to limit the number of Pods per namespace.
C.Add a toleration for a taint that is present on only one node.
D.Add a nodeSelector to the Pod spec to select a specific node.
AnswerA

PodAffinity attracts Pods to nodes that already have Pods with matching labels, ensuring all replicas on the same node.

Why this answer

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.

Exam trap

The trap here is that candidates confuse podAntiAffinity (which spreads Pods) with podAffinity (which co-locates Pods), and mistakenly think modifying the anti-affinity rule or using nodeSelector will achieve co-location, when only podAffinity with requiredDuringSchedulingIgnoredDuringExecution enforces the desired behavior.

How to eliminate wrong answers

Option B is wrong because a ResourceQuota limits the total number of Pods in a namespace but does not influence scheduling placement or co-location of Pods on a single node. Option C is wrong because adding a toleration for a taint on only one node would allow Pods to be scheduled there, but it does not prevent the scheduler from placing Pods on other nodes; it also does not enforce co-location of all replicas on that single node. Option D is wrong because a nodeSelector pins Pods to a specific node, but it does not ensure all replicas are scheduled on the same node if the selected node cannot accommodate all replicas; it also lacks the flexibility of affinity rules to handle node failures or resource constraints.

Practice this question →
34
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

Scheduler uses requests to calculate node capacity.

Why this answer

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.

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 →
35
Matchingmedium

Match each kubectl command to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Create or update resources from a file

Create a Service for a resource

Manage deployment rollouts

Safely evict Pods from a Node

Display resource usage metrics

Why these pairings

These commands are essential for daily cluster management.

Practice this question →
36
MCQhard

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?

A.Random pods
B.Pods with the highest ordinals (4 and 3)
C.Pods with the lowest ordinals (0 and 1)
D.Pods with the highest resource usage
AnswerB

StatefulSet deletes pods in reverse ordinal order when scaling down.

Why this answer

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.

Exam trap

The trap here is that candidates may assume pods are terminated randomly or based on resource usage, but the CKA exam tests the specific deterministic behavior of StatefulSet scaling, which always removes pods with the highest ordinals first.

How to eliminate wrong answers

Option A is wrong because StatefulSet does not terminate pods randomly; it follows a deterministic ordinal-based termination order. Option C is wrong because pods with the lowest ordinals (0 and 1) are the last to be terminated, not the first, as the scaling-down process removes pods from the highest ordinal downward. Option D is wrong because StatefulSet termination is based on ordinal index, not resource usage; resource-aware termination is not a feature of StatefulSet scaling.

Practice this question →
37
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

Both are required: nodeSelector for placement and resource request for GPU allocation.

Why this answer

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.

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 →
38
Multi-Selecthard

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

Select 2 answers
A.Set resource requests for 'gpu' in the container spec.
B.Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution matching a label that identifies GPU nodes.
C.Set nodeName to the name of a specific GPU node.
D.Add a toleration for a taint that GPU nodes have.
E.Set resource requests for 'nvidia.com/gpu' in the container spec and ensure the node has that resource.
AnswersB, E

Node affinity can force scheduling on nodes with a specific label, such as 'gpu=true'.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse resource requests for custom resources (like 'gpu') with the correct extended resource name (e.g., 'nvidia.com/gpu'), or they think a toleration alone is sufficient to guarantee a node has a GPU, when it only allows scheduling onto tainted nodes without ensuring the required hardware is present.

Practice this question →
39
MCQeasy

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?

A.The Pod was evicted due to resource pressure.
B.The Pod requests more CPU than available on the node.
C.The scheduler failed to communicate with the API server.
D.The node has a taint that the Pod does not tolerate.
AnswerD

The Pod lacks toleration for the disk-pressure taint.

Why this answer

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.

Exam trap

CNCF often tests the distinction between taints/tolerations and resource constraints, so the trap here is that candidates may confuse a taint-based scheduling block with a resource shortage, especially when the taint name includes 'disk-pressure' which sounds like a resource issue.

How to eliminate wrong answers

Option A is wrong because eviction occurs when a Pod is already running and the node experiences resource pressure, not when a Pod is stuck in Pending; eviction would move the Pod to a different state (e.g., Failed or Evicted). Option B is wrong because insufficient CPU would cause the scheduler to report a '0/1 nodes are available: insufficient cpu' event, but the question explicitly states the node has a disk-pressure taint, and the Pod has no tolerations, making the taint the primary blocking factor. Option C is wrong because scheduler-to-API-server communication failures typically result in scheduler errors or 'no persistent volumes available' messages, not a simple Pending state; the scheduler communicates via the API server to list nodes and bind Pods, and a failure would produce different symptoms.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Workloads & Scheduling questions.

Start 20-question session