CKA Workloads and Scheduling Practice Test 7 — 15 Questions

Question 1

A pod with a resource request of 500m CPU and a limit of 1 CPU is scheduled. The node has a CPU capacity of 2 cores. What does the '500m' represent?

Accepted Answer

500 millicores (0.5 CPU core). In Kubernetes, CPU resources are measured in millicores, where 1000m equals 1 full CPU core (vCPU or hyperthread). The '500m' in a resource request means the pod is guaranteed at least 500 millicores, or 0.5 CPU core, from the node's 2-core capacity. This is a standard unit used by the kubelet for CPU scheduling and the Completely Fair Scheduler (CFS) quota enforcement.

Answer

500 megabytes of memory

Answer

50% of the node's CPU capacity

Answer

A limit of 500,000 CPU seconds per day

Question 2

You have a PriorityClass 'high-priority' with value 1000 and 'low-priority' with value 100. A pod A with 'high-priority' is pending because the node has no resources. A pod B with 'low-priority' is running on that node. What will happen if preemption is enabled?

Accepted Answer

Pod B will be preempted (evicted) to allow pod A to be scheduled on the node. When preemption is enabled, the Kubernetes scheduler can evict lower-priority pods to free resources for pending higher-priority pods. In this scenario, Pod A (priority 1000) is pending due to insufficient resources, while Pod B (priority 100) is running on the node. The scheduler will preempt (evict) Pod B to allow Pod A to be scheduled, as the priority difference is significant and preemption is enabled by default in Kubernetes (via the 'PrioritySort' and 'Preemption' plugins).

Answer

Pod A will be scheduled only after pod B completes its work

Answer

Pod A will remain pending because preemption is not enabled by default

Answer

The cluster administrator must manually delete pod B to allow pod A to schedule

Question 3

Which TWO of the following are valid ways to expose environment variables from a ConfigMap to a pod? (Select TWO.)

Accepted Answer

Using envFrom with configMapRef. `envFrom` with `configMapRef` allows you to inject all key-value pairs from a ConfigMap as environment variables into a pod, which is a concise way to expose ConfigMap data without specifying each key individually. This is a native Kubernetes feature that automatically creates environment variables for each entry in the ConfigMap.

Answer

Using envFrom with secretRef

Answer

Using env field with configMapKeyRef directly

Answer

Mounting the ConfigMap as a volume, which automatically sets environment variables

Question 4

Which THREE of the following are valid ways to restrict or influence pod scheduling using taints and tolerations? (Select THREE.)

Accepted Answer

Adding a taint with effect NoSchedule to a node. Adding a taint with effect NoSchedule (option A) prevents scheduling of pods without matching tolerations onto the node. Adding a taint with effect PreferNoSchedule (option C) is a soft preference that tries to avoid scheduling pods without tolerations onto the node but does not guarantee it. Adding a taint with effect NoExecute (option E) not only prevents scheduling but also evicts any existing pods that do not tolerate the taint. Options B and D are not valid uses of taints and tolerations: tolerations allow pods to be scheduled on tainted nodes, not prevent scheduling, and nodeSelector is a separate mechanism not based on taints and tolerations.

Answer

Adding a toleration to a pod to prevent it from being scheduled on certain nodes

Answer

Applying a nodeSelector to a pod to match node labels

Question 5

You have a DaemonSet that runs a logging agent. You want to ensure it only runs on nodes with GPU. Which field should you set in the DaemonSet's pod template spec?

Accepted Answer

spec.template.spec.nodeSelector. `spec.template.spec.nodeSelector` is a simple, direct field in the Pod template spec that constrains which nodes the DaemonSet's pods can be scheduled on. By setting a key-value pair like `gpu: true`, you ensure the logging agent only runs on nodes that have that label, which is the standard Kubernetes mechanism for node-level selection without complex expressions.

Answer

spec.selector

Answer

spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

Answer

spec.template.spec.nodeName

Question 6

A StatefulSet named 'db' has 3 replicas. You need to update the pod template to change the resource limits. After applying the change, you run 'kubectl rollout status sts db' and it hangs. What is the most likely reason?

Accepted Answer

The StatefulSet's pod management policy is OrderedReady, and the first pod to update (db-2) is not becoming Ready.. StatefulSets with the default OrderedReady pod management policy update pods sequentially in reverse order (from highest ordinal to lowest). When `kubectl rollout status sts db` hangs, it indicates that the update is stuck waiting for the first pod in the update sequence (db-2) to become Ready. If db-2 fails to become Ready due to the new resource limits (e.g., insufficient cluster resources or misconfigured limits), the rollout cannot proceed to update db-1 and db-0, causing the command to hang indefinitely.

Answer

The update strategy is set to OnDelete, and you need to delete pods manually.

Answer

The maxSurge setting is preventing the update from starting.

Answer

The StatefulSet's service name is incorrect, causing DNS resolution failures.

Question 7

A pod with priorityClassName: high is pending. You describe the pod and see the event: '0/3 nodes are available: 3 node(s) didn't match pod affinity/anti-affinity, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod has required anti-affinity to avoid co-location with pods from the same app. How can you get the pod scheduled?

Accepted Answer

Change the anti-affinity rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution.. The pod is pending because its required anti-affinity rule cannot be satisfied on any node: all 3 nodes either have a control-plane taint (which the pod doesn't tolerate) or already host pods from the same app, violating the anti-affinity. Changing the rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a soft constraint, allowing the scheduler to place the pod on a node even if it means co-locating with same-app pods, thus resolving the scheduling conflict.

Answer

Add a toleration for the control-plane taint.

Answer

Increase the number of replicas of the app to spread the pods.

Answer

Delete the existing pods of the same app to free up nodes.

Question 8

What is the default pod phase when a pod is first created but not yet running?

Accepted Answer

Pending. When a Pod is first created, it enters the Pending phase before it is scheduled onto a node and its containers are started. The Pending phase indicates that the Pod has been accepted by the Kubernetes API server but one or more containers are not yet running, often because the image is being pulled or the node is not ready. This is the default initial phase as defined in the Kubernetes Pod lifecycle.

Answer

Running

Answer

Succeeded

Answer

Unknown

Question 9

A Deployment named 'app' has 3 replicas. The rolling update strategy is set with maxSurge=1 and maxUnavailable=1. During an update, a new ReplicaSet is created. How many pods will be in terminating state at the moment when the new ReplicaSet has 2 pods ready?

Accepted Answer

1. With maxSurge=1 and maxUnavailable=1, the Deployment controller ensures that during a rolling update, the total number of pods across old and new ReplicaSets does not exceed desiredReplicas + maxSurge (3+1=4). When the new ReplicaSet has 2 pods ready, the controller will begin terminating old pods to bring the total down. At that exact moment, exactly 1 old pod will be in Terminating state, as the controller scales down the old ReplicaSet by 1 to maintain the surge limit.

Answer

3

Answer

0

Answer

2

Question 10

You create a PriorityClass named 'high-priority' with value 1000000 (one million). A pod uses this PriorityClass. The cluster has limited resources. What scheduling behavior is most likely?

Accepted Answer

The pod may preempt lower-priority pods to be scheduled. PriorityClass with value 1000000 is extremely high (the default max is 1 billion). When a pod with this PriorityClass is submitted and the cluster has limited resources, the Kubernetes scheduler may preempt (evict) lower-priority pods to free resources and schedule this high-priority pod. This is the core behavior of PriorityClass and preemption in Kubernetes.

Answer

The pod will never be preempted by other pods

Answer

The pod will be scheduled only after all lower-priority pods have been scheduled

Answer

The pod will be assigned a higher CPU priority in the kernel

Question 11

A pod is in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 1 node(s) had taint that the pod didn't tolerate, 2 node(s) didn't match pod's node affinity/selector, 1 node(s) had insufficient memory'. What does this indicate?

Accepted Answer

The pod is unschedulable due to multiple constraints. The 'Pending' state combined with the scheduler's message '0/4 nodes are available' and the listed reasons (taints, node affinity/selector mismatches, insufficient memory) indicates that the pod cannot be placed on any node due to multiple constraints. The scheduler evaluates all nodes and finds none that satisfy the pod's requirements, making the pod unschedulable. This is not a transient resource issue but a combination of scheduling constraints that must be resolved manually.

Answer

The pod's image pull failed on all nodes

Answer

The pod will eventually be scheduled when resources free up

Answer

The pod has a resource limit that prevents it from running

Question 12

A DaemonSet named 'fluentd' is configured to run on all nodes. After adding a new node to the cluster, you notice that the DaemonSet pod is not running on the new node. What could be the cause?

Accepted Answer

The new node has a taint that the DaemonSet pod does not tolerate. A DaemonSet ensures that a copy of a pod runs on all (or a subset of) nodes. When a new node is added, the DaemonSet controller automatically schedules a pod on it unless the node has a taint that the pod does not tolerate. By default, the new node may have a taint (e.g., `node.kubernetes.io/unschedulable` or a custom taint) that prevents the DaemonSet pod from being scheduled unless the pod's spec includes a matching toleration.

Answer

The new node does not have enough resources to run the DaemonSet pod

Answer

The DaemonSet has a nodeSelector that does not match the new node's labels

Answer

The DaemonSet's update strategy is set to OnDelete

Question 13

A StatefulSet named 'web' has 3 replicas. You need to update the container image from 'nginx:1.19' to 'nginx:1.20' using a rolling update with ordered pod management. What must you ensure in the StatefulSet spec?

Accepted Answer

Set spec.podManagementPolicy to OrderedReady (default). For a StatefulSet to perform a rolling update with ordered pod management (pods updated one at a time in reverse ordinal order), the podManagementPolicy must be set to OrderedReady. This is the default policy and ensures that pods are created, deleted, and updated in a strict sequential order, maintaining the stable identity and startup ordering required by stateful applications.

Answer

Set spec.updateStrategy.rollingUpdate.maxSurge to 1

Answer

Set spec.updateStrategy.rollingUpdate.partition to 0

Answer

Set spec.podManagementPolicy to Parallel

Question 14

Which command creates a ConfigMap named 'app-config' from the file 'config.properties'?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the content of the file 'config.properties'. The `--from-file` flag reads the file and stores its entire content as a single key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content. This is the standard syntax for creating a ConfigMap from a file in Kubernetes.

Answer

kubectl create configmap app-config --file=config.properties

Answer

kubectl create configmap app-config --from-env-file=config.properties

Answer

kubectl create configmap app-config --from-literal=config.properties

Question 15

Which annotation is commonly used to trigger a rollout restart of a Deployment when a ConfigMap is updated?

Accepted Answer

kubectl.kubernetes.io/restartedAt. The annotation `kubectl.kubernetes.io/restartedAt` is commonly used with `kubectl rollout restart` to trigger a rolling restart of a Deployment. When a ConfigMap is updated, Pods using it via `envFrom` or `volumes` are not automatically updated; adding or updating this annotation on the Deployment's pod template forces a new ReplicaSet to be created, picking up the latest ConfigMap data.

Answer

configmap.kubernetes.io/update-trigger

Answer

field.cattle.io/updateStrategy

Answer

kubectl.kubernetes.io/last-applied-configuration