Workloads &amp; Scheduling practice questions

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?

Trap 1: Pod priority and preemption

Pod priority and preemption are mechanisms that influence the scheduling order of pods and allow higher-priority pods to evict lower-priority pods from nodes if resources are scarce. While critical for workload management and ensuring important applications run, these features do not provide a direct mechanism for a pod to express a preference or requirement for specific *types* of nodes based on labels or attributes. They manage *when* a pod gets scheduled, not *where* it specifically targets.

Trap 2: Taints and tolerations

Taints are applied to nodes to repel pods, preventing them from scheduling onto that node unless the pod has a corresponding toleration. This mechanism is primarily used for ensuring nodes are reserved for specific workloads or to keep misbehaving pods off certain nodes. However, taints and tolerations do not actively *attract* pods to particular nodes; they only allow pods to *tolerate* an existing exclusion, making them unsuitable for expressing a preference to land on a specific node type.

Trap 3: Resource quotas

Resource quotas are a mechanism to limit the aggregate resource consumption (like CPU, memory, or number of pods) within a specific Kubernetes namespace. They ensure fair usage among teams or projects and prevent any single namespace from consuming all available cluster resources. However, resource quotas do not provide any functionality to influence *which specific nodes* a pod will be scheduled onto; they only enforce limits on *how much* can be consumed within a defined scope, irrespective of node characteristics.

A
Pod priority and preemption
Why it fails: Pod priority and preemption are mechanisms that influence the scheduling order of pods and allow higher-priority pods to evict lower-priority pods from nodes if resources are scarce. While critical for workload management and ensuring important applications run, these features do not provide a direct mechanism for a pod to express a preference or requirement for specific *types* of nodes based on labels or attributes. They manage *when* a pod gets scheduled, not *where* it specifically targets.
B
Taints and tolerations
Why it fails: Taints are applied to nodes to repel pods, preventing them from scheduling onto that node unless the pod has a corresponding toleration. This mechanism is primarily used for ensuring nodes are reserved for specific workloads or to keep misbehaving pods off certain nodes. However, taints and tolerations do not actively *attract* pods to particular nodes; they only allow pods to *tolerate* an existing exclusion, making them unsuitable for expressing a preference to land on a specific node type.
C
Node affinity
Node affinity is a powerful feature that allows pods to specify rules for which nodes they are eligible to be scheduled on, based on labels attached to the nodes. It supports both `requiredDuringSchedulingIgnoredDuringExecution` rules, which are hard requirements, and `preferredDuringSchedulingIgnoredDuringExecution` rules, which are soft preferences. This enables a devops team to precisely direct critical applications to specific hardware, zones, or other labeled node characteristics, ensuring optimal placement and performance.
D
Resource quotas
Why it fails: Resource quotas are a mechanism to limit the aggregate resource consumption (like CPU, memory, or number of pods) within a specific Kubernetes namespace. They ensure fair usage among teams or projects and prevent any single namespace from consuming all available cluster resources. However, resource quotas do not provide any functionality to influence *which specific nodes* a pod will be scheduled onto; they only enforce limits on *how much* can be consumed within a defined scope, irrespective of node characteristics.

Question 2mediummultiple choice

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?

Trap 1: Taint on non-GPU nodes and toleration on the pod

Taints and tolerations are primarily designed to repel pods from nodes unless the pod explicitly tolerates the taint. Applying a taint to non-GPU nodes would prevent pods without the corresponding toleration from scheduling there. However, this mechanism does not attract pods to GPU nodes or guarantee that a pod must run on a GPU node; it only allows the pod to run on any node it tolerates, including non-GPU nodes if they are untainted. The goal is to require a GPU node, which taints alone cannot achieve.

Trap 2: Pod affinity to prefer GPU nodes

Pod affinity rules are designed to schedule pods on nodes that already have other specified pods running on them, based on labels of those pods. While preferredDuringSchedulingIgnoredDuringExecution could express a preference, it's based on the presence of other pods, not direct node labels or inherent hardware capabilities like a GPU. Therefore, using pod affinity to select nodes based on their intrinsic hardware features is an incorrect application of this feature, as it doesn't directly evaluate node labels.

Trap 3: Node affinity with a requiredDuringSchedulingIgnoredDuringExecution…

Node affinity with `requiredDuringSchedulingIgnoredDuringExecution` fails because the `IgnoredDuringExecution` component means that if a node's `gpu=true` label is removed *after* the pod is scheduled, the pod will continue running on that node, violating the application's continuous GPU requirement. This rule is tempting as `requiredDuringScheduling` ensures initial placement. It is suitable when initial placement is critical, but subsequent label changes during execution are acceptable or not anticipated, preventing unnecessary pod evictions.

A
Taint on non-GPU nodes and toleration on the pod
Why it fails: Taints and tolerations are primarily designed to repel pods from nodes unless the pod explicitly tolerates the taint. Applying a taint to non-GPU nodes would prevent pods without the corresponding toleration from scheduling there. However, this mechanism does not attract pods to GPU nodes or guarantee that a pod must run on a GPU node; it only allows the pod to run on any node it tolerates, including non-GPU nodes if they are untainted. The goal is to require a GPU node, which taints alone cannot achieve.
B
Pod affinity to prefer GPU nodes
Why it fails: Pod affinity rules are designed to schedule pods on nodes that already have other specified pods running on them, based on labels of those pods. While preferredDuringSchedulingIgnoredDuringExecution could express a preference, it's based on the presence of other pods, not direct node labels or inherent hardware capabilities like a GPU. Therefore, using pod affinity to select nodes based on their intrinsic hardware features is an incorrect application of this feature, as it doesn't directly evaluate node labels.
C
Node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule for gpu=true
Why it fails: Node affinity with `requiredDuringSchedulingIgnoredDuringExecution` fails because the `IgnoredDuringExecution` component means that if a node's `gpu=true` label is removed *after* the pod is scheduled, the pod will continue running on that node, violating the application's continuous GPU requirement. This rule is tempting as `requiredDuringScheduling` ensures initial placement. It is suitable when initial placement is critical, but subsequent label changes during execution are acceptable or not anticipated, preventing unnecessary pod evictions.
D
nodeSelector with gpu=true
A nodeSelector is the most straightforward and direct method to ensure a pod is scheduled exclusively on a node with specific labels. By setting nodeSelector: { "gpu": "true" }, the Kubernetes scheduler will strictly only consider nodes that possess the label gpu with the exact value true. This provides a mandatory, hard requirement for pod placement, directly fulfilling the application's need to run exclusively on a GPU-equipped node.

Question 3hardmultiple choice

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?

Trap 1: The pod has resource requests that exceed available capacity

If a pod's CPU or memory requests exceeded the allocatable capacity of the nodes, the scheduler would emit events explicitly stating "Insufficient cpu" or "Insufficient memory". Because the kubectl describe pod output specifically highlights taint-related scheduling failures, resource constraints are not the root cause of this pending state.

Trap 2: The nodes are cordoned

Cordoning a node marks it as unschedulable by applying the Spec.Unschedulable field, which triggers a specific "node(s) were unschedulable" or "node(s) cordoned" event from the scheduler. This is distinct from taint-matching failures, which generate events pointing directly to unmatched taints rather than general unschedulable node status.

Trap 3: The kube-scheduler is not running

If the kube-scheduler control plane component were completely offline, no scheduling cycle would occur for the pending pod. Consequently, the kubectl describe pod output would show a complete absence of scheduling events or decisions, rather than active warning events detailing why scheduling failed.

A
The pod has resource requests that exceed available capacity
Why it fails: If a pod's CPU or memory requests exceeded the allocatable capacity of the nodes, the scheduler would emit events explicitly stating "Insufficient cpu" or "Insufficient memory". Because the kubectl describe pod output specifically highlights taint-related scheduling failures, resource constraints are not the root cause of this pending state.
B
The pod does not have tolerations for the node taints
When nodes are configured with taints, the kube-scheduler will reject scheduling any pod onto them unless the pod specification includes matching tolerations. The kubectl describe pod events in this scenario explicitly state that the pod failed to schedule due to taints that it does not tolerate.
C
The nodes are cordoned
Why it fails: Cordoning a node marks it as unschedulable by applying the Spec.Unschedulable field, which triggers a specific "node(s) were unschedulable" or "node(s) cordoned" event from the scheduler. This is distinct from taint-matching failures, which generate events pointing directly to unmatched taints rather than general unschedulable node status.
D
The kube-scheduler is not running
Why it fails: If the kube-scheduler control plane component were completely offline, no scheduling cycle would occur for the pending pod. Consequently, the kubectl describe pod output would show a complete absence of scheduling events or decisions, rather than active warning events detailing why scheduling failed.

Question 4mediummultiple choice

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?

Trap 1: Define a nodeSelector in the pod spec

A `nodeSelector` matches nodes by static label key-value pairs, but the scenario requires scheduling only onto a node that physically possesses a specific custom resource such as a license dongle. This approach fails because a node label does not dynamically reflect hardware presence; the dongle could be removed without the label changing. It is tempting because `nodeSelector` is the simplest mechanism for directing pods to nodes with particular attributes, and it would be correct if the requirement were merely a static node property like an SSD or GPU, not a removable physical device.

Trap 2: Assign the pod a high priority so it gets scheduled on any node

Assigning a pod a high priority only influences its position in the scheduling queue and its ability to preempt lower-priority pods if resources are scarce. It does not provide any mechanism to direct the pod to a specific node with particular hardware or software resources. A high-priority pod will still be scheduled on *any* available node that meets its resource requests, not necessarily one with the specialized resource needed for the batch job.

Trap 3: Use pod anti-affinity to avoid nodes without the resource

Pod anti-affinity is designed to prevent pods from being scheduled on the same node as other specified pods, primarily for high availability or workload isolation. It focuses on the relationship *between pods* rather than the inherent characteristics of the *node itself*. While it can indirectly influence node choice by excluding nodes already running certain pods, it cannot directly select nodes based on the presence or absence of a specific hardware resource like a license dongle.

A
Use node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule
Node affinity with a `requiredDuringSchedulingIgnoredDuringExecution` rule ensures that a pod will *only* be scheduled on nodes that possess a specific label, indicating the presence of the required resource. The `requiredDuringScheduling` part guarantees strict enforcement during the initial scheduling phase, preventing the pod from ever landing on an unsuitable node. `IgnoredDuringExecution` means that if the node's labels change *after* the pod is running, the pod will not be evicted, which is generally acceptable for a batch job that completes its task.
B
Define a nodeSelector in the pod spec
Why it fails: A `nodeSelector` matches nodes by static label key-value pairs, but the scenario requires scheduling only onto a node that physically possesses a specific custom resource such as a license dongle. This approach fails because a node label does not dynamically reflect hardware presence; the dongle could be removed without the label changing. It is tempting because `nodeSelector` is the simplest mechanism for directing pods to nodes with particular attributes, and it would be correct if the requirement were merely a static node property like an SSD or GPU, not a removable physical device.
C
Assign the pod a high priority so it gets scheduled on any node
Why it fails: Assigning a pod a high priority only influences its position in the scheduling queue and its ability to preempt lower-priority pods if resources are scarce. It does not provide any mechanism to direct the pod to a specific node with particular hardware or software resources. A high-priority pod will still be scheduled on *any* available node that meets its resource requests, not necessarily one with the specialized resource needed for the batch job.
D
Use pod anti-affinity to avoid nodes without the resource
Why it fails: Pod anti-affinity is designed to prevent pods from being scheduled on the same node as other specified pods, primarily for high availability or workload isolation. It focuses on the relationship *between pods* rather than the inherent characteristics of the *node itself*. While it can indirectly influence node choice by excluding nodes already running certain pods, it cannot directly select nodes based on the presence or absence of a specific hardware resource like a license dongle.

Question 5mediummulti select

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

Trap 1: Use a toleration for a taint that exists only on nodes in the zone

Tolerations are not a selection mechanism; they merely allow a pod to be scheduled onto nodes that carry a matching taint. If a zone's nodes are tainted, a toleration lets the pod pass the taint check, but the scheduler is free to place it on any other tainted node anywhere in the cluster. Tolerations only relax restrictions—they never force or even prefer scheduling onto the nodes with the taint, so they cannot guarantee zone selection.

Trap 2: Use pod affinity to attract pods to nodes in that zone

Pod affinity is designed to co-locate pods relative to other pods, not to select nodes based on node labels. It uses label selectors against pods already running in the cluster, meaning it can only influence placement if there is an existing pod with matching labels in that zone, and it is often soft (preferred) rather than required. This indirect, pod-relative mechanism is not a valid way to ensure a pod lands on a node in a specific zone based on node properties.

Trap 3: Set spec.nodeName to the name of a node in the zone

Setting spec.nodeName directly assigns the pod to a specific node by name, completely bypassing the scheduler and all admission checks. This approach requires knowing the exact node hostname, not the zone label, and it cannot react to node health or resource availability—the pod will be stuck if that node fails or is full. It is a hard override for special use cases like system pods, not a zone-based scheduling method.

A
Use nodeSelector with the zone label
nodeSelector is a basic scheduling constraint that matches nodes by exact label key-value pairs. When a pod specifies a nodeSelector with the zone label, the kube-scheduler restricts candidate nodes to only those carrying that label, guaranteeing placement within the desired zone. It is the simplest, hard-enforced method for zone-based selection, though it lacks support for operators like In or NotIn.
B
Use node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule matching the zone label
Node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule is a more expressive label-based constraint than nodeSelector. The required clause is enforced by the scheduler at pod placement time, so the pod will only be scheduled onto nodes whose labels satisfy the matchExpression for the zone. It supports operators such as In, NotIn, Exists, and Gt, making it a valid and flexible way to require a specific zone.
C
Use a toleration for a taint that exists only on nodes in the zone
Why it fails: Tolerations are not a selection mechanism; they merely allow a pod to be scheduled onto nodes that carry a matching taint. If a zone's nodes are tainted, a toleration lets the pod pass the taint check, but the scheduler is free to place it on any other tainted node anywhere in the cluster. Tolerations only relax restrictions—they never force or even prefer scheduling onto the nodes with the taint, so they cannot guarantee zone selection.
D
Use pod affinity to attract pods to nodes in that zone
Why it fails: Pod affinity is designed to co-locate pods relative to other pods, not to select nodes based on node labels. It uses label selectors against pods already running in the cluster, meaning it can only influence placement if there is an existing pod with matching labels in that zone, and it is often soft (preferred) rather than required. This indirect, pod-relative mechanism is not a valid way to ensure a pod lands on a node in a specific zone based on node properties.
E
Set spec.nodeName to the name of a node in the zone
Why it fails: Setting spec.nodeName directly assigns the pod to a specific node by name, completely bypassing the scheduler and all admission checks. This approach requires knowing the exact node hostname, not the zone label, and it cannot react to node health or resource availability—the pod will be stuck if that node fails or is full. It is a hard override for special use cases like system pods, not a zone-based scheduling method.

Question 6hardmulti select

Which THREE of the following are characteristics of DaemonSets?

Trap 1: DaemonSets can be scaled down by reducing the number of replicas

DaemonSets do not have a `replicas` field; therefore, scaling by reducing a replica count is impossible. The number of pods is determined by the set of nodes that match the pod template's nodeSelector and tolerations, not by a desired count. To reduce the number of pods, you must modify the nodeSelector to exclude certain nodes or add taints that prevent scheduling, not adjust a scalar replica field.

Trap 2: A DaemonSet can be used to run a batch job that completes

DaemonSet pods are intended for long-running services that should persist on every node, and they are not suited for batch jobs that finish and exit. If a DaemonSet pod completes successfully, the controller will restart it to maintain the desired state of one pod per node. For workloads that run to completion, the appropriate resource is a Job (or CronJob for scheduling), which manages pod lifecycle until all tasks finish.

A
A DaemonSet runs exactly one pod per node
A DaemonSet is a controller that ensures exactly one pod replica runs on every node in the cluster matching the selector. The pod count is implicitly equal to the number of selected nodes, so when nodes are added or removed, the DaemonSet controller automatically creates or deletes pods accordingly. This is fundamentally different from a Deployment, where you explicitly specify a replica count and the scheduler distributes the pods arbitrarily.
B
DaemonSets support rolling updates
DaemonSets support rolling updates through the `updateStrategy` field, with the default strategy set to `RollingUpdate`. This updates pods node-by-node in a controlled sequence, respecting `maxUnavailable` to avoid downtime across the cluster. When you update the pod template or image, the DaemonSet controller gradually replaces pods on each node, similar to how a Deployment performs rolling updates but with node-level granularity.
C
DaemonSets can be scaled down by reducing the number of replicas
Why it fails: DaemonSets do not have a `replicas` field; therefore, scaling by reducing a replica count is impossible. The number of pods is determined by the set of nodes that match the pod template's nodeSelector and tolerations, not by a desired count. To reduce the number of pods, you must modify the nodeSelector to exclude certain nodes or add taints that prevent scheduling, not adjust a scalar replica field.
D
DaemonSets can be scheduled on specific nodes using nodeSelector
By specifying a `nodeSelector` in the pod template, a DaemonSet restricts pod placement to only those nodes carrying the matching labels. For example, you can label a subset of nodes as `gpu: true` and set the same selector in the DaemonSet, causing it to run only on GPU-enabled nodes. This is a common way to deploy node-specific agents like device drivers or monitoring exporters to a targeted set of infrastructure.
E
A DaemonSet can be used to run a batch job that completes
Why it fails: DaemonSet pods are intended for long-running services that should persist on every node, and they are not suited for batch jobs that finish and exit. If a DaemonSet pod completes successfully, the controller will restart it to maintain the desired state of one pod per node. For workloads that run to completion, the appropriate resource is a Job (or CronJob for scheduling), which manages pod lifecycle until all tasks finish.

Question 7easymulti select

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

Trap 1: The application is a batch job that should run to completion

StatefulSet is designed for long-running services that maintain state and continue serving requests; its pods are expected to remain alive. A batch job that runs to completion is exactly the opposite, and Kubernetes provides the Job controller specifically to track successful termination and manage retries. If you used a StatefulSet for a batch workload, the completion would be treated as a failure and the pod would be restarted indefinitely, breaking the desired run-to-completion semantics.

Trap 2: The application needs to run on all nodes in the cluster

Running one pod on every node in the cluster is the purpose of a DaemonSet, not a StatefulSet. DaemonSets are typically used for node-level infrastructure such as kube-proxy, log collectors, and monitoring agents. StatefulSet schedules a specified number of replicas according to desired count and placement constraints; it does not guarantee host coverage, so this requirement points away from StatefulSet.

Trap 3: The application is stateless and can be scaled arbitrarily

A stateless application that can scale arbitrarily is the exact use case for a Deployment, not a StatefulSet. StatefulSets guarantee stable, unique network identities and persistent storage per pod, which is unnecessary and wasteful for stateless workloads. This option is tempting because Deployments and StatefulSets both manage pods, but the choice hinges on whether the application requires ordered startup, sticky identity, or PVC binding — none of which apply here.

A
The application is a batch job that should run to completion
Why it fails: StatefulSet is designed for long-running services that maintain state and continue serving requests; its pods are expected to remain alive. A batch job that runs to completion is exactly the opposite, and Kubernetes provides the Job controller specifically to track successful termination and manage retries. If you used a StatefulSet for a batch workload, the completion would be treated as a failure and the pod would be restarted indefinitely, breaking the desired run-to-completion semantics.
B
The application requires unique network identities (e.g., hostnames)
StatefulSet assigns each pod a stable, ordinal-based hostname such as web-0, web-1, which persists across restarts and rescheduling. This unique network identity, combined with a headless service, gives each workload an individual DNS name like web-0.web-svc.default.svc.cluster.local. No other workload controller (Deployment or DaemonSet) provides guaranteed stable per-pod identities, making StatefulSet the correct choice for stateful applications requiring fixed endpoints.
C
The application needs to run on all nodes in the cluster
Why it fails: Running one pod on every node in the cluster is the purpose of a DaemonSet, not a StatefulSet. DaemonSets are typically used for node-level infrastructure such as kube-proxy, log collectors, and monitoring agents. StatefulSet schedules a specified number of replicas according to desired count and placement constraints; it does not guarantee host coverage, so this requirement points away from StatefulSet.
D
The application is stateless and can be scaled arbitrarily
Why it fails: A stateless application that can scale arbitrarily is the exact use case for a Deployment, not a StatefulSet. StatefulSets guarantee stable, unique network identities and persistent storage per pod, which is unnecessary and wasteful for stateless workloads. This option is tempting because Deployments and StatefulSets both manage pods, but the choice hinges on whether the application requires ordered startup, sticky identity, or PVC binding — none of which apply here.
E
The application requires stable persistent storage that persists across pod rescheduling
StatefulSet integrates with a volumeClaimTemplate, generating a distinct PersistentVolumeClaim for each replica that remains bound to its underlying PersistentVolume even if the pod is deleted and recreated. After a reschedule, the new pod with the same ordinal index reattaches to the same claim, thus retaining its data across node failures or maintenance. This stable PVC-per-replica model is the standard way to give stateful applications persistent storage, whereas Deployments generally use a shared volume that is not tied to pod identity.

Question 8hardmultiple choice

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?

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

Adding a toleration for 'arch=amd64:NoSchedule' to a Pod would only be relevant if amd64 nodes were specifically tainted with `arch=amd64:NoSchedule`. Tolerations allow pods to be scheduled on nodes that possess a matching taint, but they do not actively *force* scheduling onto nodes of a particular architecture. To restrict pods to amd64 nodes, a taint would typically be applied to *non-amd64* nodes, and the pod would *not* tolerate that specific taint, or more directly, `nodeSelector` should be used.

Trap 2: Add a label 'kubernetes.io/arch: amd64' to all amd64 nodes and use…

The `nodeSelector` field in a Pod's specification is the most straightforward and effective method to constrain a Pod to run exclusively on nodes with specific labels. Kubernetes automatically applies the `kubernetes.io/arch: amd64` label to nodes possessing an amd64 architecture. Therefore, utilizing `nodeSelector` with this standard and readily available label precisely targets and ensures the Pods are scheduled solely on amd64 nodes, directly fulfilling the team's requirement.

Trap 3: Use podAntiAffinity to avoid scheduling on arm64 nodes.

Pod anti-affinity rules are specifically designed to prevent pods from being scheduled on the same node as other specified pods, or on nodes that already host certain pods. This mechanism evaluates the labels of *other pods* on a node, not the node's inherent attributes like CPU architecture. Consequently, `podAntiAffinity` cannot be used to directly avoid scheduling on nodes based on their architectural type, such as arm64 nodes, as it operates on a different scheduling dimension.

A
Add a toleration for 'arch=amd64:NoSchedule' to the Pod.
Why it fails: Adding a toleration for 'arch=amd64:NoSchedule' to a Pod would only be relevant if amd64 nodes were specifically tainted with `arch=amd64:NoSchedule`. Tolerations allow pods to be scheduled on nodes that possess a matching taint, but they do not actively *force* scheduling onto nodes of a particular architecture. To restrict pods to amd64 nodes, a taint would typically be applied to *non-amd64* nodes, and the pod would *not* tolerate that specific taint, or more directly, `nodeSelector` should be used.
B
Add a label 'kubernetes.io/arch: amd64' to all amd64 nodes and use nodeSelector.
Why it fails: The `nodeSelector` field in a Pod's specification is the most straightforward and effective method to constrain a Pod to run exclusively on nodes with specific labels. Kubernetes automatically applies the `kubernetes.io/arch: amd64` label to nodes possessing an amd64 architecture. Therefore, utilizing `nodeSelector` with this standard and readily available label precisely targets and ensures the Pods are scheduled solely on amd64 nodes, directly fulfilling the team's requirement.
C
Use podAntiAffinity to avoid scheduling on arm64 nodes.
Why it fails: Pod anti-affinity rules are specifically designed to prevent pods from being scheduled on the same node as other specified pods, or on nodes that already host certain pods. This mechanism evaluates the labels of *other pods* on a node, not the node's inherent attributes like CPU architecture. Consequently, `podAntiAffinity` cannot be used to directly avoid scheduling on nodes based on their architectural type, such as arm64 nodes, as it operates on a different scheduling dimension.
D
Set a runtimeClassName for amd64 in the Pod spec.
Why it fails: Setting a `runtimeClassName` in the Pod spec dictates which container runtime (e.g., `runc`, `gVisor`, `Kata Containers`) the Kubelet should use for that particular pod. This choice influences the container's isolation and performance characteristics, but it is entirely independent of the node's underlying CPU architecture (like amd64 or arm64). Therefore, specifying a `runtimeClassName` for 'amd64' would not constrain pod scheduling to amd64 nodes, as it serves a distinct purpose within the Kubernetes ecosystem.

Question 9mediummultiple choice

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?

Trap 1: Between 2 and 3

The range 2–3 ignores the maxSurge field, which permits the Deployment to create extra pods above the desired 3 before terminating old ones. With maxSurge=1, for example, the controller can temporarily run 4 pods total, so the upper bound is 4, not 3. Thus "between 2 and 3" is too restrictive and only part of the valid span.

Trap 2: Exactly 4

Exactly 4 is only the peak if maxSurge equals 1 and is not a constant state. Kubernetes does not force the number of pods to stay at 4; it only enforces the constraint that the total never exceeds replicas plus maxSurge. Depending on maxUnavailable, the count can also be 3 (no surge active) or even 2 (when one pod is taken down), making "exactly 4" an inaccurate fixed target.

Trap 3: Always 3

The Deployment never promises a static pod count during updates; rolling updates are designed to transition between ReplicaSets by creating new pods and removing old ones. If maxSurge=0 and maxUnavailable=1, the count can drop to 2; if maxSurge=1, it can rise to 4. Therefore, "always 3" is only true outside the update window and contradicts the rolling update mechanism itself.

A
Between 2 and 3
Why it fails: The range 2–3 ignores the maxSurge field, which permits the Deployment to create extra pods above the desired 3 before terminating old ones. With maxSurge=1, for example, the controller can temporarily run 4 pods total, so the upper bound is 4, not 3. Thus "between 2 and 3" is too restrictive and only part of the valid span.
B
Exactly 4
Why it fails: Exactly 4 is only the peak if maxSurge equals 1 and is not a constant state. Kubernetes does not force the number of pods to stay at 4; it only enforces the constraint that the total never exceeds replicas plus maxSurge. Depending on maxUnavailable, the count can also be 3 (no surge active) or even 2 (when one pod is taken down), making "exactly 4" an inaccurate fixed target.
C
Between 2 and 4
During a rolling update, the Deployment controller simultaneously respects maxUnavailable (how many pods may be down relative to replicas) and maxSurge (how many extra pods above replicas are allowed). For replicas=3, the total pod count can therefore range from a minimum of 3 - maxUnavailable (e.g., 2 if maxUnavailable=1) to a maximum of 3 + maxSurge (e.g., 4 if maxSurge=1). Since these constraints are configurable, the valid range commonly observed is between 2 and 4 inclusive.
D
Always 3
Why it fails: The Deployment never promises a static pod count during updates; rolling updates are designed to transition between ReplicaSets by creating new pods and removing old ones. If maxSurge=0 and maxUnavailable=1, the count can drop to 2; if maxSurge=1, it can rise to 4. Therefore, "always 3" is only true outside the update window and contradicts the rolling update mechanism itself.

Question 10mediummulti select

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

Trap 1: Adding a toleration for a taint on the node.

A toleration only marks a pod as willing to be scheduled onto nodes that have a matching taint; it does not select or restrict the pod to any particular node based on labels. Without a matching taint, tolerations are ignored entirely, and even with a match, the scheduler still evaluates all nodes for placement. Therefore, it cannot be used as a mechanism to constrain a pod to nodes with specific labels.

Trap 2: Setting spec.nodeName to a node's name.

Setting spec.nodeName directly assigns the pod to a specific node by its name, completely bypassing the scheduler and label-based selection. This is a forced placement, not a restriction based on node labels, and it can cause scheduling failures if that node is unavailable or in a different pool. Since the question asks for ways to restrict a pod using labels, nodeName is an invalid answer.

Trap 3: Using spec.affinity.podAffinity with requiredDuringScheduling.

podAffinity with requiredDuringScheduling constrains a pod's placement relative to other pods, not relative to node labels. It uses pod labels and topology keys to ensure that the pod is scheduled onto nodes where certain other pods are running, which is about co-location or anti-affinity between workloads. This does not restrict a pod based on labels of the node itself, so it is not a correct answer here.

A
Adding a toleration for a taint on the node.
Why it fails: A toleration only marks a pod as willing to be scheduled onto nodes that have a matching taint; it does not select or restrict the pod to any particular node based on labels. Without a matching taint, tolerations are ignored entirely, and even with a match, the scheduler still evaluates all nodes for placement. Therefore, it cannot be used as a mechanism to constrain a pod to nodes with specific labels.
B
Specifying spec.nodeSelector in the Pod spec.
spec.nodeSelector is a map of key-value pairs that acts as a hard constraint during scheduling: the pod can only be placed on nodes whose labels include every entry in the map. It is essentially a simplified form of nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution semantics, suitable for label-based node selection. This is one of the standard, valid ways to restrict a pod to a subset of nodes.
C
Using spec.affinity.nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution.
nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution provides a rule that the scheduler must enforce when placing the pod, meaning the pod will only run on nodes matching the label expression. It supports operators such as In, NotIn, Exists, Gt, and Lt, giving more flexibility than a plain nodeSelector map. Because the requirement is mandatory at scheduling time, this is a valid way to restrict a pod to nodes with specific labels.
D
Setting spec.nodeName to a node's name.
Why it fails: Setting spec.nodeName directly assigns the pod to a specific node by its name, completely bypassing the scheduler and label-based selection. This is a forced placement, not a restriction based on node labels, and it can cause scheduling failures if that node is unavailable or in a different pool. Since the question asks for ways to restrict a pod using labels, nodeName is an invalid answer.
E
Using spec.affinity.podAffinity with requiredDuringScheduling.
Why it fails: podAffinity with requiredDuringScheduling constrains a pod's placement relative to other pods, not relative to node labels. It uses pod labels and topology keys to ensure that the pod is scheduled onto nodes where certain other pods are running, which is about co-location or anti-affinity between workloads. This does not restrict a pod based on labels of the node itself, so it is not a correct answer here.

Question 11hardmultiple choice

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?

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

A ResourceQuota is an administrative tool used to constrain aggregate resource consumption, such as CPU, memory, or total Pod count, within a specific namespace. It does not influence the Kubernetes scheduler's placement decisions or node selection algorithms. Consequently, it cannot force multiple Pod replicas to run on the same physical worker node.

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

Taints and tolerations are designed to allow nodes to repel a set of Pods, not to attract them. While adding a toleration allows a Pod to be scheduled on a tainted node, it does not obligate the scheduler to place it there. The scheduler could still distribute the replicas across any of the other nine untainted worker nodes.

Trap 3: Add a nodeSelector to the Pod spec to select a specific node.

While a nodeSelector can restrict Pods to a specific node by matching node labels, hardcoding a specific node name or unique label reduces cluster resilience and creates a single point of failure. If that specific node becomes unhealthy, the scheduler cannot reschedule the Pods elsewhere. Furthermore, it does not dynamically colocate replicas on an arbitrarily chosen healthy node.

A
Replace podAntiAffinity with podAffinity using requiredDuringSchedulingIgnoredDuringExecution for the app label.
Using podAffinity with requiredDuringSchedulingIgnoredDuringExecution forces the scheduler to place all matching Pod replicas on the same topological domain, such as a single node. By matching the application's own label, subsequent replicas are attracted to the node where the first replica was scheduled. This guarantees strict colocation across the 10-node cluster.
B
Create a ResourceQuota to limit the number of Pods per namespace.
Why it fails: A ResourceQuota is an administrative tool used to constrain aggregate resource consumption, such as CPU, memory, or total Pod count, within a specific namespace. It does not influence the Kubernetes scheduler's placement decisions or node selection algorithms. Consequently, it cannot force multiple Pod replicas to run on the same physical worker node.
C
Add a toleration for a taint that is present on only one node.
Why it fails: Taints and tolerations are designed to allow nodes to repel a set of Pods, not to attract them. While adding a toleration allows a Pod to be scheduled on a tainted node, it does not obligate the scheduler to place it there. The scheduler could still distribute the replicas across any of the other nine untainted worker nodes.
D
Add a nodeSelector to the Pod spec to select a specific node.
Why it fails: While a nodeSelector can restrict Pods to a specific node by matching node labels, hardcoding a specific node name or unique label reduces cluster resilience and creates a single point of failure. If that specific node becomes unhealthy, the scheduler cannot reschedule the Pods elsewhere. Furthermore, it does not dynamically colocate replicas on an arbitrarily chosen healthy node.

Question 12mediummultiple choice

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?

Trap 1: Set nodeName in the Pod spec to the node name.

Setting nodeName in the Pod spec directly binds the Pod to a specific node by its hostname. While this guarantees initial placement, it completely bypasses the scheduler and offers no resilience; if that particular node fails or is removed, the Pod will remain unschedulable until the node is restored, rather than being moved to another suitable node. This approach is too rigid for a critical application requiring flexibility and high availability.

Trap 2: Use nodeAffinity with…

A `requiredDuringSchedulingIgnoredDuringExecution` nodeAffinity enforces placement only at pod creation time, but if the labelled node becomes unavailable later, the scheduler will not move the pod to another node with `disk=ssd` — it merely keeps the pod on its current node. This approach is tempting because it guarantees initial scheduling on the correct node, which would be sufficient if the cluster never experienced node failures or maintenance.

Trap 3: Add a toleration for a taint that the node has.

Adding a toleration for a taint only allows a Pod to be scheduled onto a node that possesses that specific taint; it does not actively *select* or *force* the Pod onto any node, nor does it consider node labels like `disk=ssd`. Tolerations merely remove an exclusion barrier, permitting scheduling on tainted nodes, but they do not guarantee placement or specify desired node characteristics beyond the absence of blocking taints. Therefore, this mechanism cannot ensure the Pod runs on an SSD-equipped node.

A
Set nodeName in the Pod spec to the node name.
Why it fails: Setting nodeName in the Pod spec directly binds the Pod to a specific node by its hostname. While this guarantees initial placement, it completely bypasses the scheduler and offers no resilience; if that particular node fails or is removed, the Pod will remain unschedulable until the node is restored, rather than being moved to another suitable node. This approach is too rigid for a critical application requiring flexibility and high availability.
B
Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution and a matchExpression for disk=ssd.
Why it fails: A `requiredDuringSchedulingIgnoredDuringExecution` nodeAffinity enforces placement only at pod creation time, but if the labelled node becomes unavailable later, the scheduler will not move the pod to another node with `disk=ssd` — it merely keeps the pod on its current node. This approach is tempting because it guarantees initial scheduling on the correct node, which would be sufficient if the cluster never experienced node failures or maintenance.
C
Add a toleration for a taint that the node has.
Why it fails: Adding a toleration for a taint only allows a Pod to be scheduled onto a node that possesses that specific taint; it does not actively *select* or *force* the Pod onto any node, nor does it consider node labels like `disk=ssd`. Tolerations merely remove an exclusion barrier, permitting scheduling on tainted nodes, but they do not guarantee placement or specify desired node characteristics beyond the absence of blocking taints. Therefore, this mechanism cannot ensure the Pod runs on an SSD-equipped node.
D
Add a nodeSelector with disk=ssd to the Pod spec.
A `nodeSelector` is the most straightforward and effective method to ensure a Pod is scheduled exclusively on nodes possessing a specific label, such as `disk=ssd`. By adding `nodeSelector: {disk: ssd}` to the Pod spec, the Kubernetes scheduler will only place this Pod on nodes that have been explicitly labeled with `disk=ssd`. This approach provides a clear, mandatory constraint, fulfilling the requirement for the critical application to run on SSD-backed storage.

Question 13hardmulti select

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

Trap 1: Set resource requests for 'gpu' in the container spec.

Requesting 'gpu' as a resource name is invalid because Kubernetes only recognizes standard resources like `cpu` and `memory`, or extended resources with a fully qualified domain name prefix, such as `nvidia.com/gpu`. The scheduler will not understand a generic 'gpu' request, leading to the pod remaining in a pending state as no node will be found that provides a resource named simply 'gpu'. This method fails to correctly specify the desired hardware.

Trap 2: Set nodeName to the name of a specific GPU node.

Using `nodeName` directly binds a pod to a particular node, bypassing the scheduler's intelligence. This approach is highly rigid and problematic because it does not verify if the specified node actually exists, is healthy, or possesses the required GPU resource. Furthermore, it prevents the scheduler from making optimal placement decisions, reduces fault tolerance, and does not check for GPU availability, potentially leading to scheduling failures or resource contention.

Trap 3: Add a toleration for a taint that GPU nodes have.

A toleration only allows a pod to be scheduled on a node that has a matching taint; it does not actively attract or select such a node. While GPU nodes might be tainted to prevent non-GPU workloads, a toleration alone does not guarantee that the pod will be scheduled on a GPU node, nor does it ensure the node actually has a GPU. The pod could still be scheduled on any other untainted node or a tainted node without a GPU, if other scheduling constraints permit.

A
Set resource requests for 'gpu' in the container spec.
Why it fails: Requesting 'gpu' as a resource name is invalid because Kubernetes only recognizes standard resources like `cpu` and `memory`, or extended resources with a fully qualified domain name prefix, such as `nvidia.com/gpu`. The scheduler will not understand a generic 'gpu' request, leading to the pod remaining in a pending state as no node will be found that provides a resource named simply 'gpu'. This method fails to correctly specify the desired hardware.
B
Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution matching a label that identifies GPU nodes.
Node affinity, specifically `requiredDuringSchedulingIgnoredDuringExecution`, is a robust method to ensure a pod is scheduled exclusively on nodes possessing a specific label, such as `gpu=true`. This hard requirement forces the Kubernetes scheduler to only consider nodes that are explicitly identified as GPU-equipped, effectively filtering the available nodes to those with the desired hardware capability. While it doesn't allocate the GPU resource itself, it guarantees placement on a suitable node.
C
Set nodeName to the name of a specific GPU node.
Why it fails: Using `nodeName` directly binds a pod to a particular node, bypassing the scheduler's intelligence. This approach is highly rigid and problematic because it does not verify if the specified node actually exists, is healthy, or possesses the required GPU resource. Furthermore, it prevents the scheduler from making optimal placement decisions, reduces fault tolerance, and does not check for GPU availability, potentially leading to scheduling failures or resource contention.
D
Add a toleration for a taint that GPU nodes have.
Why it fails: A toleration only allows a pod to be scheduled on a node that has a matching taint; it does not actively attract or select such a node. While GPU nodes might be tainted to prevent non-GPU workloads, a toleration alone does not guarantee that the pod will be scheduled on a GPU node, nor does it ensure the node actually has a GPU. The pod could still be scheduled on any other untainted node or a tainted node without a GPU, if other scheduling constraints permit.
E
Set resource requests for 'nvidia.com/gpu' in the container spec and ensure the node has that resource.
This is the standard and most direct method for requesting GPU resources. By specifying an extended resource like `nvidia.com/gpu` in the container's resource requests, the Kubernetes scheduler will only place the pod on a node that has advertised this specific resource and has sufficient available capacity. This approach leverages the device plugin mechanism, ensuring both that the node has the GPU and that the resource is allocated to the pod.

Question 14mediummulti select

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

Trap 1: The Pod has a restartPolicy of OnFailure and the container exits…

This is not a reason for a Pod to be Pending because a container that exits with code 0 is considered successful, not failed; under restartPolicy=OnFailure, the kubelet performs no restart, and the Pod transitions to the Succeeded/Completed phase. Pending is a scheduling-phase state that occurs before any container starts, so a completed container cannot produce Pending. The exit code 0 scenario is about a finished Pod, not an unscheduled one.

Trap 2: The container image does not exist.

A missing container image does not cause a Pod to be Pending; the scheduler can still place the Pod on a node, and then the kubelet attempts to pull the image. When the pull fails, the container is stuck in a waiting state with reason ImagePullBackOff or ErrImagePull, and the Pod's phase becomes Running with a failing, waiting container—not Pending. Pending indicates the scheduler has not yet assigned the Pod to a node, whereas image problems occur only after scheduling has succeeded.

A
The node selector does not match any available node.
A Pod remains in Pending when its nodeSelector is a hard affinity constraint that no existing node satisfies. The scheduler evaluates nodeSelector as a requiredDuringScheduling predicate, and if every node fails that label-match check, the scheduler records an unschedulable event and leaves the Pod queued. The Pod will stay Pending indefinitely until a node with the matching labels is added to the cluster or the nodeSelector is changed.
B
The PersistentVolumeClaim used by the Pod is not bound.
Before a Pod can be scheduled, any PersistentVolumeClaim it references must be successfully bound to a PersistentVolume; the scheduler treats this as a prerequisite check. A PVC in a Pending or Unbound state means the cluster cannot determine where to place the Pod, so the Pod itself remains Pending. This commonly occurs when no matching PV exists, the StorageClass cannot dynamically provision, or the PVC request exceeds available capacity.
C
The cluster does not have enough resources to schedule the Pod.
The scheduler's feasibility phase checks whether a node has enough allocatable resources to satisfy the sum of the Pod's container CPU and memory requests plus the node's existing workload. If no node has sufficient unallocated resources, the Pod is left in Pending and the scheduler marks it as Unschedulable with reasons like Insufficient cpu or Insufficient memory. It stays in that state until resources are freed by other Pods completing, or until the cluster is scaled out with additional nodes.
D
The Pod has a restartPolicy of OnFailure and the container exits with code 0.
Why it fails: This is not a reason for a Pod to be Pending because a container that exits with code 0 is considered successful, not failed; under restartPolicy=OnFailure, the kubelet performs no restart, and the Pod transitions to the Succeeded/Completed phase. Pending is a scheduling-phase state that occurs before any container starts, so a completed container cannot produce Pending. The exit code 0 scenario is about a finished Pod, not an unscheduled one.
E
The container image does not exist.
Why it fails: A missing container image does not cause a Pod to be Pending; the scheduler can still place the Pod on a node, and then the kubelet attempts to pull the image. When the pull fails, the container is stuck in a waiting state with reason ImagePullBackOff or ErrImagePull, and the Pod's phase becomes Running with a failing, waiting container—not Pending. Pending indicates the scheduler has not yet assigned the Pod to a node, whereas image problems occur only after scheduling has succeeded.

Question 15mediummulti select

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

Trap 1: DaemonSets are used for stateless applications that require…

Unlike Deployments or ReplicaSets, which manage an arbitrary number of stateless replicas across a cluster, a DaemonSet is designed to run exactly one instance of a Pod per Node. They are typically used for node-level infrastructure agents, such as log collectors or monitoring daemons, rather than general-purpose, multi-replica stateless applications.

Trap 2: DaemonSets ignore taints and tolerations by default.

DaemonSet Pods strictly respect node taints and tolerations like any other Kubernetes Pod. By default, a DaemonSet Pod will not be scheduled on a tainted node unless the Pod template explicitly defines a matching toleration, though the DaemonSet controller does automatically add certain default tolerations (such as for unschedulable or disk-pressure states).

Trap 3: DaemonSets have a desired replica count that can be scaled…

DaemonSets do not feature a `spec.replicas` field and cannot be scaled manually or via a HorizontalPodAutoscaler. Instead, the number of running Pods is dynamically determined by the cluster topology, automatically scaling up or down as nodes are added to or removed from the cluster.

A
DaemonSets are used for stateless applications that require multiple replicas.
Why it fails: Unlike Deployments or ReplicaSets, which manage an arbitrary number of stateless replicas across a cluster, a DaemonSet is designed to run exactly one instance of a Pod per Node. They are typically used for node-level infrastructure agents, such as log collectors or monitoring daemons, rather than general-purpose, multi-replica stateless applications.
B
DaemonSets can be updated using a rolling update strategy.
Kubernetes supports the `RollingUpdate` update strategy for DaemonSets as the default behavior. When a DaemonSet template is modified, the controller automatically replaces old DaemonSet Pods with new ones in a controlled, rolling fashion, ensuring minimal disruption to node-level services.
C
DaemonSets ignore taints and tolerations by default.
Why it fails: DaemonSet Pods strictly respect node taints and tolerations like any other Kubernetes Pod. By default, a DaemonSet Pod will not be scheduled on a tainted node unless the Pod template explicitly defines a matching toleration, though the DaemonSet controller does automatically add certain default tolerations (such as for unschedulable or disk-pressure states).
D
DaemonSets have a desired replica count that can be scaled independently.
Why it fails: DaemonSets do not feature a `spec.replicas` field and cannot be scaled manually or via a HorizontalPodAutoscaler. Instead, the number of running Pods is dynamically determined by the cluster topology, automatically scaling up or down as nodes are added to or removed from the cluster.
E
DaemonSets ensure that a copy of a Pod runs on all or a subset of Nodes.
The primary purpose of a DaemonSet is to guarantee that a single instance of a designated Pod runs on every eligible node in the cluster. By utilizing node selectors, affinity rules, or tolerations, administrators can target either the entire cluster or restrict the DaemonSet to run on a specific subset of nodes.

Question 16hardmultiple choice

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?

Trap 1: Use pod affinity with a…

Pod affinity rules are used to schedule pods relative to *other pods*, based on their labels, typically for co-location or anti-co-location purposes. This mechanism focuses entirely on inter-pod relationships within a cluster, not on selecting specific nodes based on the node's own attributes or labels. Therefore, it cannot be used to directly force a pod onto a particular node.

Trap 2: Use node affinity with a…

Node affinity, specifically with a `requiredDuringSchedulingIgnoredDuringExecution` rule, is the robust and flexible method for hard-constraining a pod to schedule only on nodes that possess specific, matching labels. This ensures the critical application's pod is exclusively placed on designated infrastructure. When combined with taints on those same nodes and corresponding tolerations on the critical pod, it effectively achieves dedicated node allocation and prevents other pods from scheduling there.

Trap 3: Use a nodeSelector with a matchExpressions constraint

A `nodeSelector` provides a straightforward, hard requirement for scheduling a pod onto nodes that have a precise set of matching labels. While it successfully ensures the critical pod lands on a suitable node, a `nodeSelector` alone does not prevent *other* pods, which might have different or no `nodeSelector` rules, from also being scheduled onto those very same nodes. This means the designated nodes might still be shared, potentially impacting the critical application's isolation or performance.

A
Use taints and tolerations
Taints are primarily designed to repel pods from nodes unless those pods explicitly tolerate the taint. While applying a taint to a node can prevent other, non-tolerating pods from being scheduled there, taints alone do not provide a mechanism to *attract* or *force* a specific critical application's pod to that particular node. The scheduler would still consider all untainted nodes as potential targets for the critical pod.
B
Use pod affinity with a requiredDuringSchedulingIgnoredDuringExecution rule
Why it fails: Pod affinity rules are used to schedule pods relative to *other pods*, based on their labels, typically for co-location or anti-co-location purposes. This mechanism focuses entirely on inter-pod relationships within a cluster, not on selecting specific nodes based on the node's own attributes or labels. Therefore, it cannot be used to directly force a pod onto a particular node.
C
Use node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule
Why it fails: Node affinity, specifically with a `requiredDuringSchedulingIgnoredDuringExecution` rule, is the robust and flexible method for hard-constraining a pod to schedule only on nodes that possess specific, matching labels. This ensures the critical application's pod is exclusively placed on designated infrastructure. When combined with taints on those same nodes and corresponding tolerations on the critical pod, it effectively achieves dedicated node allocation and prevents other pods from scheduling there.
D
Use a nodeSelector with a matchExpressions constraint
Why it fails: A `nodeSelector` provides a straightforward, hard requirement for scheduling a pod onto nodes that have a precise set of matching labels. While it successfully ensures the critical pod lands on a suitable node, a `nodeSelector` alone does not prevent *other* pods, which might have different or no `nodeSelector` rules, from also being scheduled onto those very same nodes. This means the designated nodes might still be shared, potentially impacting the critical application's isolation or performance.

Question 17mediummulti select

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

Trap 1: A pod with a nodeSelector that does not match any node will be…

A pod whose nodeSelector matches no node is never placed: the kube-scheduler marks it unschedulable and leaves it in the Pending state indefinitely. This is not an eviction, because eviction is an active termination of an already-running pod, typically triggered by the kubelet or the Eviction API. The pod simply stays Pending until a matching node appears, the nodeSelector is changed, or an administrator deletes it.

Trap 2: If a pod with higher priority is pending and there are no…

Priority preemption in the scheduler will evict only pods with strictly lower priority than the pending pod; pods with equal or higher priority are never preempted. If all existing pods have equal or greater priority, the higher-priority pod cannot free resources and will remain Pending. Preemption also requires the pending pod to have a priorityClassName whose priority value is greater than the target pods, and the evicted lower-priority pods are subsequently rescheduled by the scheduler.

Trap 3: Static pods are created by the API server based on a manifest file…

Static pods are created directly by the kubelet, not by the API server. The kubelet watches a local manifest directory (such as /etc/kubernetes/manifests) and starts pods from the YAML/JSON files it finds, completely bypassing the scheduler and API server admission. The API server only later records a mirror pod object to represent that static pod, but it does not orchestrate or manage its creation.

A
Init containers always run before app containers and must complete successfully for the pod to start.
In a Kubernetes pod, init containers run in a strictly sequential order, and each must exit with code 0 before the next one starts. Until all init containers have completed successfully, no regular app container is launched; if any init container fails, Kubernetes restarts it according to the pod's restartPolicy instead of starting the application containers. Once they succeed, init containers are terminated and do not run again unless the pod itself is restarted, making them a gate for app-container startup.
B
A pod with a nodeSelector that does not match any node will be evicted from the cluster.
Why it fails: A pod whose nodeSelector matches no node is never placed: the kube-scheduler marks it unschedulable and leaves it in the Pending state indefinitely. This is not an eviction, because eviction is an active termination of an already-running pod, typically triggered by the kubelet or the Eviction API. The pod simply stays Pending until a matching node appears, the nodeSelector is changed, or an administrator deletes it.
C
If a pod with higher priority is pending and there are no resources, it will preempt pods with equal or lower priority.
Why it fails: Priority preemption in the scheduler will evict only pods with strictly lower priority than the pending pod; pods with equal or higher priority are never preempted. If all existing pods have equal or greater priority, the higher-priority pod cannot free resources and will remain Pending. Preemption also requires the pending pod to have a priorityClassName whose priority value is greater than the target pods, and the evicted lower-priority pods are subsequently rescheduled by the scheduler.
D
Static pods are created by the API server based on a manifest file in the kubelet's manifest directory.
Why it fails: Static pods are created directly by the kubelet, not by the API server. The kubelet watches a local manifest directory (such as /etc/kubernetes/manifests) and starts pods from the YAML/JSON files it finds, completely bypassing the scheduler and API server admission. The API server only later records a mirror pod object to represent that static pod, but it does not orchestrate or manage its creation.
E
DaemonSet pods are scheduled on all nodes, including nodes that are tainted, as long as the pod tolerates the taint.
DaemonSet pods are scheduled by the DaemonSet controller onto every node that matches the DaemonSet's nodeSelector or affinity, regardless of whether the node is tainted, as long as the pod contains tolerations for those taints. If a node has a taint that the DaemonSet pod does not tolerate, the pod will not be started there, so toleration rules still govern final placement. This lets DaemonSets like log collectors or node metrics agents run on all nodes while respecting taint-based exclusion.

Question 18mediumdrag order

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

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Describe pod, then check pod logs, then check pod events, then…

This sequence is suboptimal because executing 'kubectl describe' first focuses on the Kubernetes API object metadata and status rather than the actual application execution environment. Since a CrashLoopBackOff indicates that the container successfully scheduled and started but subsequently failed, the root cause is almost always an application-level crash. Checking the container's stdout/stderr logs first is the most direct way to diagnose these internal runtime errors without wading through verbose cluster-level metadata.

Trap 2: Check pod events, then check pod logs, then describe pod, then…

Prioritizing cluster events over container logs is inefficient for troubleshooting a CrashLoopBackOff status. Events typically highlight infrastructure-level issues, such as image pull failures, node scheduling constraints, or liveness probe failures, rather than internal application logic crashes. Since the pod has already progressed to a running state before crashing, the critical diagnostic data resides in the application logs, making event inspection a secondary step.

Trap 3: Review pod spec, then check pod logs, then describe pod, then check…

Starting the troubleshooting workflow by reviewing the raw pod specification is highly inefficient and prone to guesswork. Without runtime diagnostic data from the container's logs or exit codes, you cannot determine whether the crash is due to a code bug, a missing environment variable, or an incorrect volume mount. You must gather empirical evidence from the active container logs first to narrow down which part of the complex pod specification requires modification.

A
Check pod logs, then describe pod, then check pod events, then review pod spec, then fix the issue
Checking container logs via 'kubectl logs' is the most efficient first step for a CrashLoopBackOff because it directly reveals application-level exit codes, unhandled exceptions, or missing startup dependencies. If logs are unavailable, running 'kubectl describe' exposes container state transitions and exit codes, followed by checking events for cluster-level scheduling or volume mounting issues. Finally, comparing these findings against the pod specification allows you to pinpoint the root misconfiguration and apply the correct fix.
B
Describe pod, then check pod logs, then check pod events, then review pod spec, then fix the issue
Why it fails: This sequence is suboptimal because executing 'kubectl describe' first focuses on the Kubernetes API object metadata and status rather than the actual application execution environment. Since a CrashLoopBackOff indicates that the container successfully scheduled and started but subsequently failed, the root cause is almost always an application-level crash. Checking the container's stdout/stderr logs first is the most direct way to diagnose these internal runtime errors without wading through verbose cluster-level metadata.
C
Check pod events, then check pod logs, then describe pod, then review pod spec, then fix the issue
Why it fails: Prioritizing cluster events over container logs is inefficient for troubleshooting a CrashLoopBackOff status. Events typically highlight infrastructure-level issues, such as image pull failures, node scheduling constraints, or liveness probe failures, rather than internal application logic crashes. Since the pod has already progressed to a running state before crashing, the critical diagnostic data resides in the application logs, making event inspection a secondary step.
D
Review pod spec, then check pod logs, then describe pod, then check pod events, then fix the issue
Why it fails: Starting the troubleshooting workflow by reviewing the raw pod specification is highly inefficient and prone to guesswork. Without runtime diagnostic data from the container's logs or exit codes, you cannot determine whether the crash is due to a code bug, a missing environment variable, or an incorrect volume mount. You must gather empirical evidence from the active container logs first to narrow down which part of the complex pod specification requires modification.

Question 19mediummatching

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

Trap 1: kubectl get: Show detailed info

Classifying kubectl get as showing detailed info is incorrect because get summarizes resources to a minimal set of fields relevant for quick scanning; any detail beyond that requires -o flags to dump raw manifests. Even with JSON/YAML output, get does not include the event stream or human-oriented status summaries, which are the hallmark of detailed info that kubectl describe provides. Thus, get is a listing/summarizing command, not a detail-inspecting one.

Trap 2: kubectl describe: List resources

kubectl describe is not suited for listing resources because it focuses on a single resource and renders verbose, human-textual blocks plus an Events log, making it unwieldy for inventory purposes. Listing is meant to quickly enumerate multiple objects with concise columns, which is exactly what kubectl get does by default. Consequently, describing describe as a 'list' command conflates the two distinct operational modes.

Trap 3: kubectl exec: Print logs

kubectl exec does not print logs; it executes a command or an interactive shell inside a container's filesystem and process namespace, which is used for debugging by inspecting state or registering a process. Log retrieval is a separate capability that kubectl logs provides from the container's stdout/stderr buffers. Confusing exec with logs would lead to trying to 'exec' when you need to read log output, an important distinction in practical incident troubleshooting.

A
kubectl get: List resources
kubectl get is the primary command for listing resources in a Kubernetes cluster, querying the API server to return a collection of objects such as Pods, Deployments, or Services. It presents results in a concise tabular format optimized for scanning and supports flags like --selector, -l, and -o to filter or change the output format. Because it only retrieves resource state, it is the correct answer for the 'list resources' purpose.
B
kubectl describe: Show detailed info
kubectl describe offers a comprehensive, human-readable view of a resource's configuration, status, and lifecycle events, unlike get's bare listing. It aggregates data such as container resource requests/limits, labels, selectors, node assignments, and a trailing Events section that records scheduler and kubelet actions. This depth makes describe the canonical command for 'show detailed info' when diagnosing why a resource is not behaving as expected.
C
kubectl logs: Print container logs
kubectl logs fetches the standard output and standard error streams produced by a container within a Pod, providing a window into the application's runtime behavior. It is the dedicated command for inspecting container logs, with options like --follow to stream new output and --previous to retrieve the logs of a terminated container before a crash. Therefore, it directly fulfills the 'print container logs' purpose.
D
kubectl get: Show detailed info
Why it fails: Classifying kubectl get as showing detailed info is incorrect because get summarizes resources to a minimal set of fields relevant for quick scanning; any detail beyond that requires -o flags to dump raw manifests. Even with JSON/YAML output, get does not include the event stream or human-oriented status summaries, which are the hallmark of detailed info that kubectl describe provides. Thus, get is a listing/summarizing command, not a detail-inspecting one.
E
kubectl describe: List resources
Why it fails: kubectl describe is not suited for listing resources because it focuses on a single resource and renders verbose, human-textual blocks plus an Events log, making it unwieldy for inventory purposes. Listing is meant to quickly enumerate multiple objects with concise columns, which is exactly what kubectl get does by default. Consequently, describing describe as a 'list' command conflates the two distinct operational modes.
F
kubectl exec: Print logs
Why it fails: kubectl exec does not print logs; it executes a command or an interactive shell inside a container's filesystem and process namespace, which is used for debugging by inspecting state or registering a process. Log retrieval is a separate capability that kubectl logs provides from the container's stdout/stderr buffers. Confusing exec with logs would lead to trying to 'exec' when you need to read log output, an important distinction in practical incident troubleshooting.

Question 20mediummatching

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

Trap 1: Pod stuck in Pending: Node down or network partition

Attributing Pod Pending to a node being down or a network partition is a category error: a down node surfaces as a NotReady condition on the Node object and, if the node was already running the pod, may trigger eviction and rescheduling onto another node. A new pod does not stay Pending simply because one node is unreachable, because the scheduler simply excludes that node and can still place the pod on any other healthy node that satisfies its constraints. Pending is a per-pod scheduling outcome, not a node-level health signal.

Trap 2: CrashLoopBackOff: Misconfigured service selector or endpoints

CrashLoopBackOff does not result from a misconfigured Service selector or missing endpoints, because those conditions affect how traffic is routed to a pod, not whether the container can start and stay running. A pod whose container is alive and healthy will not be in CrashLoopBackOff even if its Service has empty Endpoints; at worst, clients cannot reach it, but the container runs normally. If the container does crash immediately after startup, the crash itself is the diagnostic signal, and you would inspect logs and exit codes rather than the Service definition.

A
Pod stuck in Pending: Insufficient resources or unscheduled pod
A pod in the Pending phase means the scheduler has not yet bound it to a node, typically because the cluster lacks nodes with enough allocatable CPU or memory to satisfy the pod's resource requests, or because node selectors, affinity/anti-affinity rules, or taints and tolerations prevent placement. The pod remains unscheduled until resources become available or the constraints are relaxed, and `kubectl describe pod` will show FailedScheduling events with the precise reason.
B
Node NotReady: Node down or network partition
A Node becomes NotReady when the node controller has not received a kubelet heartbeat for longer than the node-monitor-grace-period, which commonly happens when the machine is powered off, the kubelet has crashed, or a network partition isolates the node from the API server. The Ready condition is updated by the kubelet's periodic status reports; when those pause, the node controller flips the condition and may later evict pods if the node remains unreachable past the pod-eviction-timeout.
C
CrashLoopBackOff: Application error causing container to repeatedly crash
CrashLoopBackOff is shown by the kubelet when a container starts, exits with a non-zero exit code, and is automatically restarted, with each attempt delayed by an exponentially increasing backoff. The immediate cause is almost always an application-level failure such as a panic at startup, a missing configuration file, or an unreachable database, not a Kubernetes configuration issue.
D
Service not accessible: Misconfigured service selector or endpoints
A Service is backed by Endpoints that are populated only when the Service's selector matches the labels on at least one live pod. If the selector has a typo, or no pods carry the expected labels, the Endpoints object is empty, and clients see connection timeouts or connection refused because the ClusterIP has no backend. Also verify the targetPort matches the actual containerPort, since a mismatch produces the same connectivity failure even with healthy pods.
E
Pod stuck in Pending: Node down or network partition
Why it fails: Attributing Pod Pending to a node being down or a network partition is a category error: a down node surfaces as a NotReady condition on the Node object and, if the node was already running the pod, may trigger eviction and rescheduling onto another node. A new pod does not stay Pending simply because one node is unreachable, because the scheduler simply excludes that node and can still place the pod on any other healthy node that satisfies its constraints. Pending is a per-pod scheduling outcome, not a node-level health signal.
F
CrashLoopBackOff: Misconfigured service selector or endpoints
Why it fails: CrashLoopBackOff does not result from a misconfigured Service selector or missing endpoints, because those conditions affect how traffic is routed to a pod, not whether the container can start and stay running. A pod whose container is alive and healthy will not be in CrashLoopBackOff even if its Service has empty Endpoints; at worst, clients cannot reach it, but the container runs normally. If the container does crash immediately after startup, the crash itself is the diagnostic signal, and you would inspect logs and exit codes rather than the Service definition.