CKA Workloads and Scheduling Practice Test 2 — 15 Questions

Question 1

You have a Deployment with 3 replicas. You run 'kubectl rollout history deployment web-app' and see revision 2 is current. You want to roll back to revision 1. Which command should you use?

Accepted Answer

kubectl rollout undo deployment/web-app --to-revision=1. `kubectl rollout undo deployment/web-app --to-revision=1` explicitly rolls back the Deployment to revision 1, which is the desired state. The `--to-revision` flag targets a specific revision from the rollout history, ensuring the Deployment's Pod template is reverted to the exact configuration of revision 1.

Answer

kubectl set image deployment/web-app web-app=image:v1

Answer

kubectl rollout history deployment/web-app --revision=1

Answer

kubectl rollout undo deployment/web-app

Question 2

Which TWO statements about Kubernetes resource requests and limits are correct? (Select 2)

Accepted Answer

Limits can be set independently for CPU and memory.. Kubernetes allows CPU and memory limits to be set independently via the `resources.limits` field in a container spec. CPU limits are defined in millicores (e.g., 500m) and memory limits in bytes (e.g., 256Mi), and they are not coupled — you can set a CPU limit without a memory limit and vice versa. This independence gives administrators fine-grained control over resource allocation per container.

Answer

Memory requests and limits are both compressible.

Answer

If a container exceeds its memory limit, it is throttled.

Answer

If no limits are specified, the pod can use unlimited resources.

Question 3

Which THREE of the following are valid taint effects that can be applied to a node? (Select 3)

Accepted Answer

NoSchedule. Taint effects in Kubernetes control pod scheduling onto nodes. `NoSchedule` (C) prevents pods that do not tolerate the taint from being scheduled on the node, making it a valid taint effect.

Answer

NeverSchedule

Answer

PreferSchedule

Question 4

Which TWO statements about DaemonSets are correct? (Select 2)

Accepted Answer

DaemonSets are often used for cluster daemons like log collectors or monitoring agents.. DaemonSets are specifically designed to run cluster-wide services such as log collectors (e.g., Fluentd) or monitoring agents (e.g., Prometheus Node Exporter). They automatically deploy a pod on every node (or a subset of nodes based on node selectors), ensuring that each node has a copy of the daemon pod for tasks like log aggregation or metrics collection.

Answer

DaemonSets are typically managed by a parent Deployment.

Answer

DaemonSets do not support rolling updates.

Answer

DaemonSets have a desired number of replicas that the scheduler tries to maintain.

Question 5

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. 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 6

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

Accepted Answer

kubectl get events --sort-by='.metadata.creationTimestamp'. To list all events across the entire cluster, you must use the `--all-namespaces` (or `-A`) flag. To sort them by their creation timestamp, you use the `--sort-by='.metadata.creationTimestamp'` option. This is the standard command recommended in the official Kubernetes Cheat Sheet.

Answer

kubectl get events --watch

Answer

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

Answer

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

Question 7

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 8

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 9

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. `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 10

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 11

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/. `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 12

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. 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 13

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

Accepted Answer

0 0 * * *. 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 14

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 `Init:Error`, which means the init container started but 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 15

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. The HPA calculates the desired number of replicas as ceil(currentReplicas * (currentUtilization / targetUtilization)). Here, currentUtilization is 90% and targetUtilization is 80%, so desiredReplicas = ceil(2 * (90/80)) = ceil(2.25) = 3. Since 3 is within the min/max range (2–10) and differs from currentReplicas (2), the HPA will scale up to 3 replicas immediately (no stabilization window for scale-up by default).

Answer

Do nothing; wait for stabilization

Answer

Scale up to 4 replicas

Answer

Scale down to 1 replica because utilization is too high