CKA Workloads and Scheduling Practice Questions

Free CKA Workloads and Scheduling practice test questions

8 questions from this domain with answers and explanations - different from the samples on the main CKA page. A free account includes a fixed set of 20 questions for this exam; paid access unlocks the full bank.

1. Question 1Workloads and Scheduling

   Which kubectl command creates a Deployment named 'web-app' with 3 replicas using the nginx:1.25 image?

   • Akubectl create deployment web-app --image=nginx:1.25 --replicas=3Correct
   • Bkubectl create pod web-app --image=nginx:1.25 --count=3
   • Ckubectl deploy web-app --image=nginx:1.25 --replicas=3
   • Dkubectl run web-app --image=nginx:1.25 --replicas=3
   ✓ Correct answer: A

   kubectl create deployment is the correct imperative command for creating a Deployment object. The --image flag specifies the container image and the --replicas flag sets the desired replica count. This creates a full Deployment resource with a ReplicaSet and pod template, unlike kubectl run which creates a single standalone Pod in modern Kubernetes versions.

   Why the other options are wrong

   • Bkubectl create pod is not a valid kubectl subcommand for creating pods imperatively; the correct command is kubectl run, and pods do not accept a --count flag.
   • Ckubectl deploy is not a valid kubectl subcommand; the correct command group is kubectl create deployment or kubectl apply with a manifest.
   • Dkubectl run web-app --image=nginx:1.25 --replicas=3 is invalid because kubectl run no longer accepts --replicas in modern Kubernetes - it creates a single Pod, not a Deployment with multiple replicas.
2. Question 2Workloads and Scheduling

   Horizon Cloud Services needs to ensure their web application pods are spread across different availability zones. Which feature should they use?

   • ALimit ranges
   • BResource quotas
   • CPod disruption budgets
   • DPod topology spread constraintsCorrect
   ✓ Correct answer: D

   Pod topology spread constraints control how matching pods are distributed across topology domains such as zones, regions or nodes, selected by topologyKey. With topologyKey: topology.kubernetes.io/zone, maxSkew: 1 and whenUnsatisfiable: DoNotSchedule, the scheduler will not place a pod where it would leave one zone more than one pod ahead of the least-loaded zone; with ScheduleAnyway the spread is only preferred. This gives fault isolation across failure domains without custom scheduling logic.

   Why the other options are wrong

   • ALimit ranges define minimum and maximum resource requests and limits (CPU, memory) for individual containers or pods within a namespace. They have no effect on where pods are physically placed across zones or nodes.
   • BResource quotas cap the aggregate resource consumption or object count within a namespace (e.g., total CPU, total memory, number of pods). They control how much is consumed, not where workloads are placed.
   • CPod disruption budgets limit how many pods voluntary disruptions such as node drains may take down at once (Deployment and StatefulSet rolling updates are not limited by them). They do not influence where pods are scheduled across zones.
3. Question 3Workloads and SchedulingSelect all that apply

   Which two taint effects prevent Pods without matching tolerations from being scheduled on a node? (Choose two.)

   • AAlwaysAllow
   • BNoScheduleCorrect
   • CNoExecuteCorrect
   • DPreferNoSchedule
   ✓ Correct answer: B, C

   Both NoSchedule and NoExecute are hard taint effects that strictly block pods lacking a matching toleration. NoSchedule prevents new pods without a matching toleration from being scheduled onto the tainted node. NoExecute does everything NoSchedule does and additionally evicts any already-running pods on the node that do not have a matching toleration, making it the stricter of the two.

   Why the other options are wrong

   • AAlwaysAllow is not a valid Kubernetes taint effect; the three valid effects are NoSchedule, PreferNoSchedule, and NoExecute.
   • DPreferNoSchedule is a soft taint effect - the scheduler tries to avoid placing pods without a matching toleration on the node, but it will do so if no other suitable node is available, meaning it does not strictly prevent scheduling.
4. Question 4Workloads and Scheduling

   Which resource type ensures a copy of a pod runs on every (or selected) node in the cluster?

   • AStatefulSet with anti-affinity
   • BDaemonSetCorrect
   • CDeployment with node affinity
   • DReplicaSet with topology spread
   ✓ Correct answer: B

   A DaemonSet is the Kubernetes workload controller specifically designed to guarantee that one pod replica runs on every node in the cluster (or a subset of nodes selected via nodeSelector or affinity rules). As nodes are added to the cluster, DaemonSet pods are automatically scheduled onto them; as nodes are removed, those pods are garbage collected. Typical DaemonSet use cases include log shippers (Fluentd), monitoring agents (Prometheus node-exporter), and CNI network plugins.

   Why the other options are wrong

   • AStatefulSet with anti-affinity can spread pods across nodes but does not guarantee one pod per node; it manages a fixed replica count and is designed for stateful applications, not node-level infrastructure coverage.
   • CDeployment with node affinity can constrain pods to specific nodes but still manages a fixed replica count; it does not automatically add or remove pods as nodes join or leave the cluster.
   • DReplicaSet with topology spread can distribute pods across topology domains but still targets a fixed replica count and does not guarantee exactly one pod per node as nodes are added or removed.
5. Question 5Workloads and Scheduling

   What happens when a container tries to use more memory than its resource limit?

   • AThe container is OOMKilled (terminated)Correct
   • BThe extra memory request is queued
   • CNothing; memory limits are advisory only
   • DMemory usage is throttled
   ✓ Correct answer: A

   Memory is enforced differently from CPU. A container's memory limit is applied through cgroups, and when the container uses more than that limit the kernel may terminate it with the Out-Of-Memory (OOM) killer. The kill happens when the kernel detects memory pressure, so a container that over-allocates is not always killed at the exact moment it crosses the limit. Kubernetes records the reason as OOMKilled in the container status, and the kubelet may restart the container according to the Pod's restartPolicy.

   Why the other options are wrong

   • BThe extra memory request is queued is incorrect; the kernel does not hold memory allocations in a queue for later. When a container reaches its limit the kernel tries to reclaim memory from it, and if that fails the OOM killer can terminate it.
   • CNothing; memory limits are advisory only is incorrect; memory limits are enforced by the kernel through cgroups, and a container over its limit can be terminated by the OOM killer.
   • DMemory usage is throttled describes how CPU limits are enforced; for memory the standard outcome of exceeding the limit is an OOM kill. The optional MemoryQoS feature can add memory throttling near the limit, but it does not replace OOM termination as the enforcement of the limit.
6. Question 6Workloads and Scheduling

   Which probe field defines the number of consecutive failures before the probe is considered failed?

   • AfailureThresholdCorrect
   • BmaxFailures
   • Cretries
   • DconsecutiveFailures
   ✓ Correct answer: A

   The failureThreshold field in a probe sets how many consecutive failures are needed before Kubernetes considers the check failed, and it defaults to 3. For a livenessProbe the kubelet then restarts the container. For a readinessProbe the Pod is marked not ready and removed from Service endpoints until the probe succeeds again.

   Why the other options are wrong

   • BmaxFailures is not a Kubernetes probe field; with kubectl's default strict field validation the request is rejected as an unknown field, and with validation set to warn or ignore the field is simply dropped.
   • Cretries is not a Kubernetes probe field, and a Job has no retries field either; a Job limits its retries with backoffLimit, while a probe counts consecutive failures with failureThreshold.
   • DconsecutiveFailures is not a valid Kubernetes probe field name; it does not appear in the Kubernetes API specification for probe configuration.
7. Question 7Workloads and Scheduling

   You run the command below and it fails. ``` kubectl apply -f deployment.yaml ``` The error output ends with: ``` strict decoding error: unknown field "spec.apiVersion" ``` What is wrong with the manifest?

   • AThe Kubernetes API version specified in the manifest is not supported
   • BThe YAML file contains invalid syntax that the parser cannot read
   • CThe deployment metadata.name value violates naming rules
   • DAn indentation error nests apiVersion under spec instead of the top levelCorrect
   ✓ Correct answer: D

   YAML nesting is set by indentation. kubectl found the top-level apiVersion and kind, so the request reached the API server, but an apiVersion line is also indented inside the spec block, so the parser reads it as a child of spec. With strict field validation, which kubectl uses by default, the API server rejects the request because a DeploymentSpec has no apiVersion field. The fix is to take that line out of spec so that apiVersion appears once, at the top level alongside kind, metadata and spec.

   Why the other options are wrong

   • AThe error reports an unknown field under spec, not an unsupported value in the top-level apiVersion.
   • BThe YAML parsed successfully; the API server could name the misplaced field spec.apiVersion, which it cannot do for a file it fails to read.
   • CThe message names an unknown spec.apiVersion field, not an invalid metadata.name value.
8. Question 8Workloads and Scheduling

   A DaemonSet must update its Pods one node at a time, and during the update at most one DaemonSet Pod may be unavailable across the cluster. Which updateStrategy configuration is correct?

   • Atype: RollingUpdate with rollingUpdate.maxUnavailable: 1Correct
   • Btype: RollingUpdate with rollingUpdate.maxSurge: 1
   • Ctype: OnDelete
   • Dtype: Recreate with replicas: 1
   ✓ Correct answer: A

   DaemonSet updates default to RollingUpdate, where maxUnavailable controls how many Pods can be down simultaneously during the update. Setting maxUnavailable: 1 ensures exactly one node's Pod is replaced at a time, limiting disruption. While newer Kubernetes supports maxSurge for DaemonSets too, maxSurge creates an extra Pod rather than limiting unavailability, which does not match the 'at most one unavailable' requirement.

   Why the other options are wrong

   • BmaxSurge temporarily runs an additional Pod on a node; it does not cap how many Pods are unavailable and changes resource usage rather than meeting the stated constraint.
   • COnDelete updates Pods only when you manually delete them, giving no automatic one-at-a-time rollout.
   • DDaemonSets have no Recreate strategy and no replicas field; the strategy types are RollingUpdate and OnDelete.

How Workloads and Scheduling is tested

This domain holds 173 of the 793 questions in the CKA bank, about 22%. The mix is 192 single-answer multiple choice and 15 multiple-response, so it is worth practising the formats as well as the content.

Once you have a few attempts recorded, CertGrid scores every domain separately and points you at the weakest one, so you can drill Workloads and Scheduling on its own rather than re-running full-length mocks.

Other CKA exam domains

• Cluster Architecture Installation and Configuration167 questions
• Services and Networking152 questions
• Storage145 questions
• Troubleshooting156 questions
• All CKA practice questions793 total
• Workloads and Scheduling study notesKey concepts
• Cloud Native practice examsAll Cloud Native

CKA Workloads and Scheduling FAQ