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. Sign up free to practice the full set.
-
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: Akubectl 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.
-
Why might a default DaemonSet skip the control plane nodes?
- ADaemonSets ignore any control plane node
- BThe scheduler caps DaemonSets to workers
- CThose nodes carry a taint its pods lackCorrect
- DControl plane nodes reject all pod specs
✓ Correct answer: CControl plane nodes are typically tainted with node-role.kubernetes.io/control-plane:NoSchedule. A DaemonSet only lands on a node when its pods tolerate that node's taints, so without an added toleration it skips the control plane. Adding the matching toleration lets the DaemonSet run there too.
Why the other options are wrong- ADaemonSets can run on control plane nodes if the pods tolerate the taint.
- BThere is no such cap; placement depends on taints and selectors.
- DControl plane nodes accept pods that tolerate their taints, including static ones.
-
A Deployment has 3 replicas and you set maxUnavailable to 1 and maxSurge to 1 during a rolling update. What is the maximum number of Pods that can exist during the update?
- A4Correct
- B5
- C2
- D3
✓ Correct answer: ADuring a RollingUpdate, the maximum number of pods that can exist simultaneously equals the desired replica count plus maxSurge. With 3 desired replicas and maxSurge of 1, Kubernetes may create up to 3 + 1 = 4 pods at once. The maxUnavailable value of 1 means at least 2 pods must remain available at all times, but that constraint does not reduce the upper bound set by maxSurge.
Why the other options are wrong- B5 would require a maxSurge of 2 above the 3 desired replicas; with maxSurge set to 1 the ceiling is 4, not 5.
- C2 confuses maxUnavailable with the maximum total pod count; maxUnavailable of 1 means the minimum available is 2, but pods can still be created above the desired count up to the maxSurge limit.
- D3 would mean no additional pods are ever created above the desired count, which would be the case only if maxSurge were 0; with maxSurge of 1, one extra pod is permitted.
-
A ReplicaSet is not creating new pods. You suspect the label selector does not match the pod template labels. Which field in the ReplicaSet spec must match the pod template labels?
- Aspec.matchLabels
- Bspec.template.selector
- Cspec.podSelector.labels
- Dspec.selector.matchLabelsCorrect
✓ Correct answer: DIn a ReplicaSet (and Deployment), spec.selector.matchLabels defines the label query used by the controller to identify which pods it owns and should count toward its desired replica count. This selector must match the labels declared in spec.template.metadata.labels exactly. If they differ, the ReplicaSet controller cannot find its pods, leading to no new pods being created or unintended adoption of existing pods.
Why the other options are wrong- Aspec.matchLabels is not a direct field path in a ReplicaSet; the label selector is nested under spec.selector, making the correct path spec.selector.matchLabels.
- Bspec.template.selector is not a valid field in the pod template section; the selector that governs pod ownership lives in spec.selector, not inside spec.template.
- Cspec.podSelector.labels is not a valid ReplicaSet field path; the field controlling which pods belong to the ReplicaSet is spec.selector.matchLabels.
-
Which command creates a ConfigMap named "app-config" with a literal key-value pair database_host=mysql.default.svc?
- Akubectl create configmap app-config --set database_host=mysql.default.svc
- Bkubectl create configmap app-config --key=database_host --value=mysql.default.svc
- Ckubectl create configmap app-config --data=database_host=mysql.default.svc
- Dkubectl create configmap app-config --from-literal=database_host=mysql.default.svcCorrect
✓ Correct answer: DThe --from-literal=<key>=<value> flag is the standard way to imperatively add individual key-value pairs to a ConfigMap when creating it with kubectl create configmap. Multiple --from-literal flags can be chained in the same command to add several entries at once. The resulting ConfigMap stores each pair in its data field and can be consumed by pods as environment variables or mounted as files.
Why the other options are wrong- Akubectl create configmap app-config --set database_host=mysql.default.svc is incorrect because --set is not a valid flag for kubectl create configmap; --set is used with helm commands to override chart values.
- Bkubectl create configmap app-config --key=database_host --value=mysql.default.svc is incorrect because neither --key nor --value are valid flags for kubectl create configmap; the correct flag is --from-literal=key=value as a single argument.
- Ckubectl create configmap app-config --data=database_host=mysql.default.svc is incorrect because --data is not a valid flag for kubectl create configmap; the correct flag for inline key-value pairs is --from-literal.
-
In a Pod spec, which field defines init containers that run before the main application containers?
- Aspec.setupContainers
- Bspec.beforeContainers
- Cspec.initContainersCorrect
- Dspec.preContainers
✓ Correct answer: CThe spec.initContainers field defines a list of containers that run to completion sequentially before any container in spec.containers starts. Init containers are commonly used for setup tasks such as waiting for a dependency, populating shared volumes, or performing database migrations before the main application starts.
Why the other options are wrong- Aspec.setupContainers is not a valid Kubernetes pod spec field; there is no such field - pre-start containers are defined using spec.initContainers.
- Bspec.beforeContainers is not a valid Kubernetes pod spec field; the correct field for containers that run before the main application containers is spec.initContainers.
- Dspec.preContainers is not a valid Kubernetes pod spec field; Kubernetes uses spec.initContainers for containers that must complete before the main containers start.
-
Which annotation records the change description that appears in kubectl rollout history?
- Akubernetes.io/change-causeCorrect
- Bkubectl.kubernetes.io/command
- Ckubectl.kubernetes.io/last-applied-configuration
- Ddeployment.kubernetes.io/revision
✓ Correct answer: AThe kubernetes.io/change-cause annotation is read by kubectl rollout history to populate the CHANGE-CAUSE column in the revision history output. It can be set manually with kubectl annotate after applying a change, or it was historically set automatically when using the now-deprecated --record flag with kubectl apply or kubectl set. Recording meaningful change causes helps operators understand what triggered each deployment revision.
Why the other options are wrong- Bkubectl.kubernetes.io/command is not a standard Kubernetes annotation used for rollout history change causes; it is not recognized by kubectl rollout history.
- Ckubectl.kubernetes.io/last-applied-configuration is the annotation that stores the last configuration applied via kubectl apply for three-way merge purposes; it is not the annotation displayed in rollout history change causes.
- Ddeployment.kubernetes.io/revision is a system-managed annotation that tracks the current revision number of the deployment; it is set automatically by the deployment controller and does not store a human-readable change description.
-
You need to temporarily prevent new pods from being scheduled to a node for maintenance, without evicting existing pods. Which command?
- Akubectl drain node01
- Bkubectl cordon node01Correct
- Ckubectl delete node node01
- Dkubectl taint node01 maintenance=true:NoExecute
✓ Correct answer: Bkubectl cordon sets the node's spec.unschedulable field to true, which causes the scheduler to skip the node for all new pod placements. Existing pods on the node are not affected and continue running normally. This is the correct first step when preparing a node for maintenance because it prevents new workloads from landing on the node while allowing current workloads to finish gracefully.
Why the other options are wrong- Akubectl drain node01 both cordons the node and evicts all running pods, which removes existing workloads; the question explicitly requires that existing pods not be evicted.
- Ckubectl delete node node01 removes the node object from the Kubernetes API entirely; this does not gracefully stop scheduling and causes all pods on the node to be immediately terminated without eviction handling.
- Dkubectl taint node01 maintenance=true:NoExecute adds a NoExecute taint that evicts existing pods lacking a matching toleration, which violates the requirement to leave existing pods running.
How Workloads and Scheduling is tested
This domain holds 187 of the 903 questions in the CKA bank, about 21%. The mix is 175 single-answer multiple choice and 12 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 Configuration197 questions
- Services and Networking168 questions
- Storage168 questions
- Troubleshooting183 questions
- All CKA practice questions903 total
- Workloads and Scheduling study notesKey concepts
- Cloud Native practice examsAll Cloud Native
CKA Workloads and Scheduling FAQ
How many CKA practice questions are there on Workloads and Scheduling?
CertGrid has 187 CKA practice questions mapped to Workloads and Scheduling, which is about 21% of the 903-question CKA bank. Every one carries a full explanation covering why the right answer is right and why each wrong option is wrong.
Can I practice only the Workloads and Scheduling domain?
Yes. Inside CertGrid you can run a focused drill on a single exam objective rather than the whole bank, and the app picks your weakest domain automatically once you have attempts to measure. The button on this page starts a Workloads and Scheduling drill directly.
How is Workloads and Scheduling tested on the CKA exam?
In this bank the domain is made up of 175 single-answer multiple choice and 12 multiple-response questions, and it accounts for roughly 21% of the practice pool. Mapping follows the current published exam objectives; CertGrid is an independent practice platform and these are not official exam questions.
What CertGrid is (and is not)
CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.
Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by the Cloud Native Computing Foundation. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.