CKA Workloads and Scheduling Practice Test 3 — 15 Questions

Question 1

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

A StatefulSet named 'web' with spec.replicas=3 uses the default pod management policy (OrderedReady). The StatefulSet has persistent volume claims. You run 'kubectl scale statefulset web --replicas=5'. Which statement is TRUE about the new pods?

Accepted Answer

Pods web-3 and web-4 are created sequentially, each with its own PVC. Option C is correct because a StatefulSet with the default OrderedReady pod management policy creates pods sequentially, strictly in order from the lowest ordinal index to the highest. When scaling from 3 to 5 replicas, pods web-3 and web-4 are created one after another, each with its own dedicated PersistentVolumeClaim (PVC) as defined in the StatefulSet's volumeClaimTemplates.

Answer

Pods web-3 and web-4 are created in parallel, both sharing the same PVC

Answer

The existing pods are recreated with new PVCs

Answer

Only web-3 is created because the StatefulSet cannot exceed 4 replicas

Question 3

Which kubectl command lists all events in the cluster, sorted by timestamp (newest first)?

Accepted Answer

kubectl get events --all-namespaces --sort-by='.lastTimestamp'. Option C is correct because `kubectl get events --all-namespaces --sort-by='.lastTimestamp'` retrieves events from all namespaces and sorts them by the `lastTimestamp` field in ascending order, which effectively displays the newest events last. To show newest first, you would typically add `--sort-by='.lastTimestamp'` and reverse the output, but among the given options, this is the only one that uses the correct field for sorting by time and includes all namespaces, which is necessary for cluster-wide events.

Answer

kubectl get events --sort-by='.metadata.creationTimestamp'

Answer

kubectl get events --watch

Answer

kubectl get events --all-namespaces --sort-by='.firstTimestamp'

Question 4

You have a pod with resource requests: cpu: 500m, memory: 128Mi. The node has 4 CPU cores and 8Gi memory. What is the maximum number of such pods that can be scheduled on this node based on CPU only?

Accepted Answer

8. The node has 4 CPU cores, which equals 4000m (millicores). Each pod requests 500m CPU. Dividing 4000m by 500m gives 8 pods. This is the maximum number that can be scheduled based on CPU alone, assuming no other pods or system overhead. Option D is correct.

Answer

4

Answer

16

Answer

6

Question 5

A pod has tolerations for a taint with key 'dedicated', value 'gpu', and effect 'NoSchedule'. The pod's nodeSelector is {disktype: ssd}. Which node(s) can this pod be scheduled on? (Assume node1 has taint dedicated=gpu:NoSchedule and label disktype=ssd; node2 has taint dedicated=gpu:NoSchedule and label disktype=hdd; node3 has no taint and label disktype=ssd)

Accepted Answer

node1 and node3. The pod has a toleration for the taint dedicated=gpu:NoSchedule, so it can tolerate that taint on any node. However, the pod also has a nodeSelector requiring disktype=ssd. Node1 has both the tolerated taint and the required label, so it qualifies. Node3 has no taint and the required label, so it also qualifies. Node2 has the tolerated taint but its label is disktype=hdd, which does not match the nodeSelector, so it is excluded. Therefore, only node1 and node3 can schedule the pod.

Answer

node1 only

Answer

node2 and node3

Answer

node1, node2, and node3

Question 6

Which of the following creates a ConfigMap named 'my-config' from a file 'app.properties'?

Accepted Answer

kubectl create configmap my-config --from-file=app.properties. Option B is correct because `kubectl create configmap my-config --from-file=app.properties` reads the file `app.properties` and creates a ConfigMap with a single key-value pair, where the key is the filename (app.properties) and the value is the entire file content. This is the standard way to create a ConfigMap from a file in Kubernetes.

Answer

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

Answer

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

Answer

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

Question 7

A DaemonSet is expected to run on all nodes, but a particular node does not have the pod. The node is Ready and has no taints. You run 'kubectl describe daemonset <name>' and see 'MISSING' for that node. What is a likely cause?

Accepted Answer

The DaemonSet has a nodeSelector that the node does not match. When a DaemonSet shows 'MISSING' for a specific node that is Ready and has no taints, the most common cause is that the node does not match the DaemonSet's nodeSelector. The nodeSelector field in the DaemonSet spec defines a set of key-value pairs that must match the node's labels. If the node lacks the required labels, the DaemonSet controller will not schedule the pod on that node, resulting in the 'MISSING' status.

Answer

The DaemonSet is configured to run only on control plane nodes

Answer

The node has insufficient resources for the DaemonSet pod

Answer

The node has a taint that is not tolerated

Question 8

You have a Deployment with spec.replicas=3. You update the container image. The rollout gets stuck because the new ReplicaSet cannot create pods due to an image pull error. Which command would you use to roll back to the previous revision?

Accepted Answer

kubectl rollout undo deployment/. Option A is correct because `kubectl rollout undo deployment/` reverts the Deployment to the previous revision by default. This command uses the rollout history stored in the Deployment's annotations (specifically `deployment.kubernetes.io/revision`) to restore the prior ReplicaSet's pod template, effectively undoing the failed image update.

Answer

kubectl rollout undo deployment/<name> --to-revision=1

Answer

kubectl rollout revert deployment/<name>

Answer

kubectl rollout rollback deployment/<name>

Question 9

A Job named 'pi' runs a container that computes pi to 2000 digits. The Job's spec has completions=3 and parallelism=2. After some time, you observe that two pods completed successfully, and the third pod is still running. What is the expected behavior when the third pod completes?

Accepted Answer

The Job will be marked as Complete. Option A is correct because a Job with `completions=3` and `parallelism=2` is considered complete when the required number of successful pod completions (3) is reached. Since two pods have already completed and the third is still running, once it finishes successfully, the total successful completions will equal the `completions` value, and the Job controller will mark the Job as Complete. The Job does not require all pods to run concurrently or finish simultaneously.

Answer

The Job will restart the completed pods

Answer

The Job will continue to run new pods indefinitely

Answer

The Job will be marked as Failed because parallelism is not fully utilized

Question 10

Which CronJob schedule expression runs a job every day at midnight (00:00)?

Accepted Answer

0 0 * * *. Option C is correct because the CronJob schedule expression '0 0 * * *' specifies minute 0, hour 0 (midnight), every day of the month, every month, and every day of the week. This matches the requirement to run a job daily at 00:00.

Answer

0 * * * *

Answer

0 0 1 * *

Answer

* 0 * * *

Question 11

A pod has an init container that downloads a large file. The init container uses the 'busybox' image and runs the command 'wget http://example.com/data.zip'. The pod's status shows 'Init:0/1' and then 'PodInitializing'. After a few minutes, the pod enters 'Init:Error'. What is the most likely cause?

Accepted Answer

The init container's command failed. The init container runs a `wget` command to download a file. The pod transitions from `Init:0/1` to `PodInitializing` (indicating the init container started) and then to `Init:Error`, which means the init container exited with a non-zero exit code. Since the image is `busybox` (which includes `wget`), the most likely cause is that the `wget` command itself failed — e.g., due to a network issue, a bad URL, or a timeout — not an image pull failure or resource limit.

Answer

The init container image was not found

Answer

The pod's main container failed to start

Answer

The init container exceeded a resource limit

Question 12

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 13

You have a HorizontalPodAutoscaler targeting a Deployment with minReplicas=2 and maxReplicas=10. currentReplicas is 2. The HPA uses average CPU utilization across pods, targetting 80% of the requested CPU. Pod CPU request is 500m. The current average CPU utilization is 90%. What will the HPA do?

Accepted Answer

Scale up to 3 replicas. Option B is correct. HPA scales up when current utilization exceeds target. Current = 90% > target 80%, so it will increase replicas. It calculates desired replicas = ceil(currentUtilization/target * currentReplicas) = ceil(90/80 * 2) = ceil(2.25) = 3, so it scales to 3.

Answer

Do nothing; wait for stabilization

Answer

Scale up to 4 replicas

Answer

Scale down to 1 replica because utilization is too high

Question 14

Which of the following is a valid way to mount a Secret as a volume in a pod?

Accepted Answer

spec.containers[0].volumeMounts[0].name: secret-volume; spec.volumes[0].secret.secretName: my-secret. Option A is correct because it defines a volume of type `secret` with the `secretName` field set to `my-secret`, and then mounts that volume into the container using a `volumeMount` with the same name. This is the standard YAML syntax for mounting a Kubernetes Secret as a volume in a pod.

Answer

spec.containers[0].envFrom[0].secretRef.name: my-secret

Answer

spec.containers[0].volumeMounts[0].name: config-volume; spec.volumes[0].configMap.name: my-secret

Question 15

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