CKA Workloads and Scheduling Practice Test 3 — 15 Questions

Question 1

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. It defines a volume of type `secret` with the `secretName` field set to `my-secret` in the standard Kubernetes YAML syntax. Option B also represents a valid secret volume definition but is less commonly used; in the context of this single-answer question, only A is considered the canonical format.

Answer

spec.containers[0].volumeMounts[0].name: secret-volume; spec.volumes[0].secret: {secretName: my-secret}

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 2

Which TWO of the following will cause a pod to be rescheduled to a different node? (Select TWO.)

Accepted Answer

Node has a taint with effect NoExecute. A taint with effect NoExecute evicts existing pods that do not tolerate the taint, causing them to be rescheduled to a different node. Additionally, if a higher-priority pod preempts the current pod, the current pod is evicted and rescheduled to a different node. Both scenarios cause the pod to be rescheduled to a different node.

Answer

The pod's resource requests are increased

Answer

The pod's node affinity is updated

Answer

Node has a taint with effect NoSchedule

Question 3

Which THREE of the following are valid fields in a Deployment's rolling update strategy? (Select THREE.)

Accepted Answer

maxSurge. `maxSurge` and `maxUnavailable` are the only two valid fields defined in a Deployment's rolling update strategy (`spec.strategy.rollingUpdate`). The `type` field belongs to the parent `spec.strategy` block, while `minReadySeconds` and `progressDeadlineSeconds` belong directly to the Deployment's `spec` block.

Answer

progressDeadlineSeconds

Answer

minReadySeconds

Answer

type

Question 4

Which TWO of the following are valid ways to inject configuration data into a pod? (Select TWO.)

Accepted Answer

Mounting a ConfigMap as a volume. A ConfigMap can be mounted as a volume in a Pod, allowing files to be injected into the container's filesystem. This is a standard Kubernetes mechanism for providing configuration data, where the ConfigMap's data keys become filenames and values become file contents.

Answer

Editing the pod's spec directly via kubectl edit

Answer

Using a Sidecar container to fetch config from a remote API

Answer

Storing config in a PersistentVolume

Question 5

You need to update a Deployment's container image to 'nginx:1.21' and ensure the rollout performs a rolling update with 2 extra pods allowed above the desired count during the update. Which command should you use?

Accepted Answer

kubectl edit deployment/nginx-deployment --patch '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.21"}]}}}}'. To update both the container image and the deployment's rolling update strategy (specifically `maxSurge`) in a single command, you should use `kubectl patch` with a strategic merge patch. The patch updates the `spec.strategy.rollingUpdate.maxSurge` to `2` and updates the container image for the container named `nginx` to `nginx:1.21` under `spec.template.spec.containers`.

Answer

kubectl update deployment/nginx-deployment --image=nginx:1.21 --strategy=rolling

Answer

kubectl rollout set image deployment/nginx-deployment nginx=nginx:1.21 --max-surge=2

Answer

kubectl set image deployment/nginx-deployment nginx=nginx:1.21

Question 6

You create a Job named 'pi-job' that runs a single pod to compute pi to 2000 decimal places. After creation, the pod runs and completes successfully. Which command would you use to view the pod's logs after completion?

Accepted Answer

kubectl logs job/pi-job. `kubectl logs` is the standard command to retrieve logs from a pod, and it can reference a Job directly by using the syntax `kubectl logs job/<job-name>`. This retrieves the logs from the pod that was created by the Job after it has completed, without needing to know the pod's name.

Answer

kubectl describe job/pi-job

Answer

kubectl exec job/pi-job -- cat /var/log/pi.log

Answer

kubectl log job/pi-job

Question 7

A pod is in Pending state. You run 'kubectl describe pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 3 node(s) had taint {node.kubernetes.io/not-ready: }.'. What is the most likely reason?

Accepted Answer

The pod does not have tolerations for the taints on the available nodes. The pod is in Pending state because the scheduler cannot find a node that meets all scheduling constraints. The event explicitly states that 1 node has a taint `node-role.kubernetes.io/master` and 3 nodes have a taint `node.kubernetes.io/not-ready`, and the pod does not have corresponding tolerations. Without tolerations, the pod is not allowed to schedule on any of these nodes, leaving no available node.

Answer

The pod's container image pull failed

Answer

The cluster is out of CPU capacity

Answer

The pod's resource requests are too high for any node

Question 8

You have a Deployment with 4 replicas. During a rolling update, you want to ensure that only 2 pods are unavailable at any given time. Which field should you set in the Deployment spec?

Accepted Answer

spec.strategy.rollingUpdate.maxUnavailable. The `spec.strategy.rollingUpdate.maxUnavailable` field specifies the maximum number of Pods that can be unavailable during a rolling update. Setting it to 2 ensures that at most 2 replicas are unavailable at any given time, which aligns with the requirement of having 4 replicas and allowing only 2 unavailable pods.

Answer

spec.updateStrategy.rollingUpdate.maxUnavailable

Answer

spec.replicas.maxUnavailable

Answer

spec.strategy.rollingUpdate.maxSurge

Question 9

A pod is scheduled on a node with a taint 'dedicated=prod:NoSchedule'. The pod has a toleration for this taint. However, you want to prevent the pod from being evicted if the node becomes unreachable. Which toleration effect should you add?

Accepted Answer

NoExecute. The `NoExecute` toleration effect allows a pod to remain on a node even if the node becomes unreachable or experiences other conditions that would normally cause pod eviction. Unlike `NoSchedule` (which only prevents new pods from being scheduled) and `PreferNoSchedule` (a soft preference), `NoExecute` actively tolerates the taint and prevents eviction. By default, a `NoExecute` toleration with no `tolerationSeconds` means the pod tolerates the taint indefinitely, so it will not be evicted when the node becomes unreachable.

Answer

PreferNoSchedule

Answer

NoSchedule

Answer

NoExecute with tolerationSeconds: 300

Question 10

Which command can be used to scale a Deployment named 'webapp' to 5 replicas?

Accepted Answer

kubectl scale deployment webapp --replicas=5. `kubectl scale` is the dedicated Kubernetes command for adjusting the replica count of a Deployment, StatefulSet, ReplicaSet, or ReplicationController. It directly modifies the `spec.replicas` field of the resource and triggers a rolling update to achieve the desired number of Pods.

Answer

kubectl patch deployment webapp -p '{"spec":{"replicas":5}}'

Answer

kubectl edit deployment webapp --replicas=5

Answer

kubectl update deployment webapp --replicas=5

Question 11

A PriorityClass named 'high-priority' has a value of 1000. A pod using this PriorityClass is pending because no node has enough resources. A lower-priority pod is running on a node. What will happen?

Accepted Answer

The scheduler will preempt the lower-priority pod to schedule the high-priority pod. Kubernetes, by default, enables the PodPriority feature gate and the non-preempting default for PriorityClasses is false. When a high-priority pod (value 1000) cannot be scheduled due to insufficient resources, the scheduler triggers preemption. It identifies nodes where lower-priority pods are running and evicts them to free resources for the pending high-priority pod, as governed by the Priority and Preemption mechanism.

Answer

The high-priority pod will remain pending until the lower-priority pod finishes

Answer

The high-priority pod will be scheduled on a node by overcommitting resources

Answer

The scheduler will ignore the PriorityClass because the cluster does not have preemption enabled

Question 12

Which TWO of the following are valid ways to inject a ConfigMap into a pod as environment variables? (Select 2)

Accepted Answer

Using env with valueFrom.configMapKeyRef. Options C and D are correct. Option C uses `env.valueFrom.configMapKeyRef` to inject a specific key from a ConfigMap as an environment variable. Option D uses `envFrom` with `configMapRef` to inject all keys from a ConfigMap as environment variables. Both are valid methods to expose ConfigMap data as environment variables in a pod.

Answer

Using volumeMounts with configMapKeyRef

Answer

Using env with configMapRef

Answer

Using volumes with configMap

Question 13

Which THREE of the following are characteristics of a StatefulSet? (Select 3)

Accepted Answer

Pods are started and terminated in a controlled order (sequentially). StatefulSets guarantee ordered, graceful deployment and scaling. Pods are created sequentially from index 0 to N-1, and terminated in reverse order (N-1 to 0). This ensures that each pod's startup and shutdown respects the ordinal index, which is critical for applications like databases that require leader election or quorum.

Answer

Pods are automatically distributed across all nodes in the cluster

Answer

StatefulSets require a ClusterIP service for stable network identities

Question 14

A Deployment 'web' has replicas=3 and update strategy RollingUpdate with maxSurge=50% and maxUnavailable=0. You update the container image. During the rollout, what is the maximum number of pods that can be running simultaneously?

Accepted Answer

5. With maxSurge=50% and maxUnavailable=0, the Deployment can create up to ceil(50% of 3) = ceil(1.5) = 2 extra pods above the desired 3 during a rolling update. Therefore, the maximum number of pods running simultaneously is 3 + 2 = 5.

Answer

4

Answer

3

Answer

6

Question 15

Which command rolls back a Deployment named 'web' to the previous revision?

Accepted Answer

kubectl rollout undo deployment web. The correct command to roll back a Deployment to the previous revision is `kubectl rollout undo deployment web`. This command reverts the Deployment to the last known stable revision by decrementing the revision number in the rollout history, effectively undoing the most recent change. It is the standard Kubernetes mechanism for rollback operations on Deployments, DaemonSets, and StatefulSets.

Answer

kubectl rollout restart deployment web

Answer

kubectl rollout history deployment web --revision=previous

Answer

kubectl rollout revert deployment web