CKA Timed Practice Test 4 — 10 Questions

Question 1

Match each troubleshooting scenario to its likely cause.

Question 2

Match each security context setting to its effect.

Question 3

Match each storage concept to its definition.

Question 4

Match each scheduling concept to its description.

Question 5

Based on the exhibit, what is the most likely cause of the worker2 node being NotReady?

Accepted Answer

The kubelet on worker2 has stopped reporting to the control plane. The kubelet on worker2 has stopped reporting to the control plane, which is the most likely cause of the node being NotReady. The kubelet is responsible for periodically posting node status updates (including heartbeats) to the API server via the NodeStatus update mechanism. If the kubelet process is down, unresponsive, or cannot communicate with the control plane (e.g., due to network partition or certificate expiry), the node controller marks the node as NotReady after the `node-monitor-grace-period` (default 40 seconds) elapses.

Answer

The node has insufficient memory

Answer

The node is experiencing disk pressure

Answer

The network plugin (Calico) is not running on worker2

Question 6

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

Accepted Answer

The application requires unique network identities (e.g., hostnames). Option B is correct because StatefulSets assign each pod a unique, stable network identity (e.g., a hostname like 'web-0', 'web-1') derived from the StatefulSet's name and an ordinal index. This is essential for applications like databases (e.g., Cassandra, ZooKeeper) that rely on consistent hostnames for cluster membership and discovery. Deployments, in contrast, generate random pod names and do not guarantee stable network identities.

Answer

The application is a batch job that should run to completion

Answer

The application needs to run on all nodes in the cluster

Answer

The application is stateless and can be scaled arbitrarily

Question 7

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?

Accepted Answer

Use node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule. Node affinity with a `requiredDuringSchedulingIgnoredDuringExecution` rule is the correct approach because it allows you to schedule the pod exclusively on nodes that have a specific custom resource (e.g., a license dongle) by matching node labels. This rule is a hard constraint that must be satisfied during scheduling, ensuring the pod only runs on nodes with the required resource. Unlike `nodeSelector`, node affinity supports more expressive matching (e.g., `In`, `NotIn`, `Exists`) and can be combined with other scheduling constraints.

Answer

Define a nodeSelector in the pod spec

Answer

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

Answer

Use pod anti-affinity to avoid nodes without the resource

Question 8

A developer wants to deploy a pod that will run only once to initialize a database schema. Which Kubernetes resource should they use?

Accepted Answer

Job. A Job is the correct Kubernetes resource for a one-time task that runs to completion, such as initializing a database schema. Unlike controllers that maintain a desired number of replicas, a Job creates one or more Pods and ensures they successfully terminate, making it ideal for batch or initialization workloads.

Answer

DaemonSet

Answer

Deployment

Answer

CronJob

Question 9

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?

Accepted Answer

nodeSelector with gpu=true. Option D is correct because `nodeSelector` is the simplest and most direct way to force a pod to run only on nodes that have a specific label, such as `gpu=true`. This ensures the pod is scheduled exclusively on GPU-equipped nodes without requiring taints, tolerations, or complex affinity rules. The `nodeSelector` field in the pod spec matches against node labels at scheduling time, making it ideal for this straightforward requirement.

Answer

Taint on non-GPU nodes and toleration on the pod

Answer

Pod affinity to prefer GPU nodes

Answer

Node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule for gpu=true

Question 10

A cluster administrator wants to ensure that no pods are scheduled on the master node(s). Which approach is the best practice?

Accepted Answer

Add a taint to the master node. Adding a taint to the master node(s) with the `node-role.kubernetes.io/master:NoSchedule` effect is the best practice because it prevents the Kubernetes scheduler from placing any pods on that node unless a pod explicitly tolerates the taint. This ensures that only critical system pods (which include the toleration) can run on the master, keeping it dedicated to cluster control plane operations.

Answer

Delete the master node from the cluster

Answer

Use a resource quota on the master namespace

Answer

Set nodeSelector on the master node