Knowledge + Practice

CCNA Cka Workloads Scheduling Questions

75 of 126 questions · Page 1/2 · Cka Workloads Scheduling topic · Answers revealed

Practice these questions Exam hub All questions

1

MCQmedium

A Deployment named 'web-app' is configured with rolling update strategy. You run 'kubectl describe deployment web-app' and see 'RollingUpdateStrategy: 25% max unavailable, 25% max surge'. You have 4 replicas. You update the image. How many pods will be unavailable during the rollout at most?

A.0

B.4

C.2

D.1

AnswerD

25% of 4 is 1, so at most 1 pod can be unavailable.

Why this answer

With a rolling update strategy of 25% max unavailable and 25% max surge on a Deployment with 4 replicas, the maximum number of pods that can be unavailable during the rollout is 1. This is because 25% of 4 replicas equals 1, and Kubernetes rounds down for max unavailable, ensuring at least 3 pods remain available throughout the update.

Exam trap

The trap here is that candidates often mistakenly round up the max unavailable value (e.g., 25% of 4 = 1, but some think it could be 2 due to misinterpreting rounding rules), or they confuse max unavailable with max surge, leading to incorrect counts of unavailable pods.

How to eliminate wrong answers

Option A is wrong because 0 unavailable pods would only be possible if max unavailable were set to 0% or 0, but here it is 25%, allowing some pods to be taken down during the update. Option B is wrong because 4 unavailable pods would mean all replicas are down, which violates the rolling update strategy that guarantees a minimum available count (75% of 4 = 3 pods). Option C is wrong because 2 unavailable pods would exceed the 25% max unavailable limit (25% of 4 = 1), and Kubernetes enforces this limit by rounding down to the nearest integer, not up.

Practice this question →

2

Multi-Selectmedium

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

Select 3 answers

A.Pods are created and terminated in a predictable order (ordinal index)

B.Each pod gets its own PersistentVolumeClaim (PVC) that persists across rescheduling

C.Pods are created in random order

D.Each pod gets a unique, stable network identity (hostname)

E.All pods in the StatefulSet are interchangeable

AnswersA, B, D

StatefulSets use ordered, graceful deployment and scaling.

Why this answer

Options A, B, and D are correct. StatefulSets provide stable network identities (each pod gets a unique hostname), ordered pod management (pods are created and terminated in order), and each pod gets its own PersistentVolumeClaim (stable storage). Option C is incorrect because StatefulSet pods are not interchangeable; each has a unique identity.

Option E is incorrect because StatefulSets use ordered deployment, not random.

Practice this question →

3

MCQmedium

A CronJob is configured to run every hour. You notice that the job did not run at the scheduled time. What is the most likely reason?

A.The concurrency policy is set to 'Forbid' and a previous job was still running

B.The concurrency policy is set to 'Allow'

C.The previous job run succeeded and the CronJob is configured to not rerun after success

D.The concurrency policy is set to 'Replace'

AnswerA

If concurrency policy is 'Forbid', the CronJob controller will skip the next run if the previous job has not completed.

Why this answer

Option B is correct. If the CronJob's concurrency policy is set to 'Forbid', it will skip the new job if a previous job is still running. Option A is incorrect because a successful job does not prevent future runs.

Option C is incorrect because a 'Replace' policy would terminate the old job and start a new one. Option D is incorrect because a 'Allow' policy would allow concurrent runs, not skip.

Practice this question →

4

MCQeasy

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?

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

B.kubectl edit deployment/nginx-deployment --patch '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.21"}]}}}}'

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

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

AnswerD

This updates the container image. The default strategy is RollingUpdate with maxSurge=25%, which allows at least 2 extra pods for a desired count of 8 or more.

Why this answer

Option C is correct. The 'kubectl set image' command updates the container image, and the '--record' flag is not needed in v1.29+ (but still works). The '--rollout' flag does not exist; 'kubectl rollout' is a separate command.

To set maxSurge, you need to edit the Deployment or use 'kubectl patch'. However, the question asks for the command to update the image and ensure rolling update; the default strategy is RollingUpdate with default maxSurge=25%, which satisfies the requirement. Option A uses incorrect flags.

Practice this question →

5

MCQhard

You are debugging a Pod that is in 'Pending' state. The output of 'kubectl describe pod' shows: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 2m default-scheduler 0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate. What does this indicate?

A.The pod requires more memory than any node can provide

B.The pod cannot be scheduled due to a combination of insufficient CPU and untolerated taints on different nodes

C.All nodes have taints that the pod does not tolerate

D.All nodes have insufficient CPU resources for the pod

AnswerB

The message clearly states both issues.

Why this answer

Option D is correct. The message indicates two different issues: one node has insufficient CPU, and two nodes have a taint that the pod does not tolerate. So there are multiple reasons preventing scheduling.

Option A is incorrect because insufficient memory is not mentioned. Option B is incorrect because only one node lacks CPU, and taints are also present. Option C is incorrect because taints are on multiple nodes, not all.

Practice this question →

6

MCQeasy

Which of the following creates a ConfigMap named 'my-config' from a file 'app.properties'?

A.kubectl create configmap my-config --from-literal=app.properties

B.kubectl create configmap my-config --from-file=app.properties

C.kubectl create configmap my-config --from-file=app.properties --from-env-file=app.properties

D.kubectl create configmap my-config --from-env-file=app.properties

AnswerB

Correct. This creates a ConfigMap with a key 'app.properties' and content from the file.

Why this answer

Option B is correct because `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.

Exam trap

The trap here is that candidates confuse `--from-file` (which imports a file as a single key-value pair) with `--from-env-file` (which imports a file as multiple key-value pairs, one per line), leading them to choose option D when the file is not in env-file format.

How to eliminate wrong answers

Option A is wrong because `--from-literal` expects a key=value pair (e.g., `--from-literal=key=value`), not a filename; using `--from-literal=app.properties` would create a ConfigMap with a key named 'app.properties' and an empty value, not the file content. Option C is wrong because combining `--from-file` and `--from-env-file` with the same file would cause a conflict or duplicate key error, as both flags attempt to read the same file in different formats (key-value vs. env-file parsing), and the command would fail or produce unexpected results. Option D is wrong because `--from-env-file` parses the file as a list of key=value lines (one per line) and creates separate keys for each line; if `app.properties` is not in that format (e.g., contains JSON or plain text), it will either fail or produce incorrect keys.

Practice this question →

7

MCQeasy

You want to run a batch job that processes a queue and then terminates. The job should be run only once. Which Kubernetes resource should you use?

A.CronJob

B.DaemonSet

C.Job

D.Deployment

AnswerC

A Job runs a task to completion.

Why this answer

Option A is correct. A Job resource runs a specified number of pods to completion. Once the pod finishes, the Job completes.

Option B (CronJob) is for scheduled jobs. Option C (Deployment) is for long-running services. Option D (DaemonSet) runs on every node.

Practice this question →

8

MCQeasy

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

A.kubectl rollout restart deployment web

B.kubectl rollout undo deployment web

C.kubectl rollout history deployment web --revision=previous

D.kubectl rollout revert deployment web

AnswerB

This undoes the last rollout.

Why this answer

The correct command is 'kubectl rollout undo deployment web'. Option A is correct.

Practice this question →

9

MCQmedium

You have a DaemonSet that runs a logging agent on all nodes. You want to update the agent's image to a new version. Which update strategy allows you to control the rollout by manually updating each node's DaemonSet pod?

A.BlueGreen

B.Recreate

C.RollingUpdate with maxUnavailable: 0

D.OnDelete

AnswerD

OnDelete requires manual deletion of pods to trigger update, providing node-by-node control.

Why this answer

Option D is correct because the DaemonSet's OnDelete update strategy requires you to manually delete each DaemonSet pod to trigger its recreation with the new image. This gives you explicit, per-node control over the rollout, which matches the requirement of manually updating each node's pod.

Exam trap

The trap here is that candidates often confuse DaemonSet update strategies with Deployment strategies, assuming RollingUpdate or Recreate are available for DaemonSets, while the OnDelete strategy is unique to DaemonSets and StatefulSets for manual control.

How to eliminate wrong answers

Option A is wrong because BlueGreen is not a valid DaemonSet update strategy; it is a Deployment strategy that involves running two versions simultaneously and switching traffic, which does not apply to DaemonSets. Option B is wrong because Recreate is not a supported update strategy for DaemonSets; it is a Deployment strategy that terminates all pods before creating new ones, offering no per-node manual control. Option C is wrong because RollingUpdate with maxUnavailable: 0 is a valid DaemonSet strategy but it automates the rollout by ensuring at most one pod is updated at a time without manual intervention, contradicting the requirement for manual per-node updates.

Practice this question →

10

MCQeasy

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

A.0 * * * *

B.0 0 1 * *

C.0 0 * * *

D.* 0 * * *

AnswerC

Correct. Exactly midnight daily.

Why this answer

Option C is correct because 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.

Exam trap

The trap here is confusing the minute and hour fields: candidates often pick Option A ('0 * * * *') thinking it means 'once per day' because they misread the first zero as 'daily', but it actually runs every hour at minute 0.

How to eliminate wrong answers

Option A is wrong because '0 * * * *' runs at minute 0 of every hour, i.e., hourly, not daily at midnight. Option B is wrong because '0 0 1 * *' runs at midnight on the first day of every month, not every day. Option D is wrong because '* 0 * * *' runs every minute during hour 0 (from 00:00 to 00:59), which would execute 60 times, not once at midnight.

Practice this question →

11

MCQeasy

What is the default pod phase when a pod is first created but not yet running?

A.Running

B.Pending

C.Succeeded

D.Unknown

AnswerB

Pending is the initial phase before scheduling and container startup.

Why this answer

When a Pod is first created, it enters the Pending phase before it is scheduled onto a node and its containers are started. The Pending phase indicates that the Pod has been accepted by the Kubernetes API server but one or more containers are not yet running, often because the image is being pulled or the node is not ready. This is the default initial phase as defined in the Kubernetes Pod lifecycle.

Exam trap

CNCF often tests the misconception that a newly created Pod immediately enters the Running phase, but the correct initial phase is always Pending until the scheduler assigns a node and the kubelet starts the containers.

How to eliminate wrong answers

Option A is wrong because Running is the phase assigned only after at least one container in the Pod has started and is running, not at creation time. Option C is wrong because Succeeded indicates that all containers in the Pod have terminated successfully, which cannot happen before the Pod runs. Option D is wrong because Unknown is a phase used when the state of the Pod cannot be obtained, typically due to a communication failure with the node, not at creation.

Practice this question →

12

MCQmedium

A CronJob runs every hour. The job takes 45 minutes to complete. What is the default behavior if the next scheduled time occurs while the previous job is still running?

A.The next job is queued and starts after the previous finishes

B.The next job is skipped

C.The next job starts immediately, running concurrently

D.The CronJob is suspended

AnswerC

Default concurrencyPolicy is Allow, so concurrent runs are permitted.

Why this answer

By default, CronJobs in Kubernetes do not allow concurrent executions. If a new job is scheduled while the previous one is still running, the new job is skipped (i.e., not created) because the `concurrencyPolicy` defaults to `Forbid`. However, the question states the correct answer is C, which implies the CronJob has been configured with `concurrencyPolicy: Allow`.

In that case, the next job starts immediately, running concurrently with the previous one.

Exam trap

The trap here is that candidates often assume CronJobs always queue or skip overlapping jobs, but the CKA tests whether you know that `concurrencyPolicy` defaults to `Forbid` and that `Allow` must be explicitly set for concurrent runs—so the 'default behavior' is actually to skip, not to allow concurrency.

How to eliminate wrong answers

Option A is wrong because the default `concurrencyPolicy` is `Forbid`, not `Queue`; Kubernetes does not queue jobs—it either allows, forbids, or replaces them. Option B is wrong because while `Forbid` is the default, the question explicitly marks C as correct, meaning the scenario assumes `Allow` is set; skipping is the behavior of `Forbid`, not the default behavior when `Allow` is configured. Option D is wrong because suspending a CronJob is controlled by the `suspend` field (set to `true`), which is independent of concurrency handling and does not occur automatically when a job overlaps.

Practice this question →

13

MCQhard

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?

A.PreferNoSchedule

B.NoExecute

C.NoSchedule

D.NoExecute with tolerationSeconds: 300

AnswerB

NoExecute causes eviction of pods that do not tolerate the taint. Adding a toleration for the unreachable taint with NoExecute effect prevents eviction.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse `NoSchedule` (which only affects scheduling) with `NoExecute` (which affects both scheduling and eviction), or they assume `tolerationSeconds` is always required for `NoExecute`, when omitting it means indefinite toleration.

How to eliminate wrong answers

Option A is wrong because `PreferNoSchedule` is a soft preference that does not prevent eviction; it only discourages scheduling new pods on tainted nodes. Option C is wrong because `NoSchedule` only prevents new pods from being scheduled on the node but does not protect existing pods from eviction if the node becomes unreachable. Option D is wrong because `NoExecute` with `tolerationSeconds: 300` would cause the pod to be evicted after 300 seconds if the node remains unreachable, which contradicts the goal of preventing eviction.

Practice this question →

14

MCQeasy

Which annotation is commonly used to trigger a rollout restart of a Deployment when a ConfigMap is updated?

A.configmap.kubernetes.io/update-trigger

B.field.cattle.io/updateStrategy

C.kubectl.kubernetes.io/last-applied-configuration

D.kubectl.kubernetes.io/restartedAt

AnswerD

'kubectl rollout restart' uses this annotation to force a new rollout, which causes the pods to restart and pick up the new ConfigMap.

Why this answer

Option D is correct because the annotation `kubectl.kubernetes.io/restartedAt` is commonly used with `kubectl rollout restart` to trigger a rolling restart of a Deployment. When a ConfigMap is updated, Pods using it via `envFrom` or `volumes` are not automatically updated; adding or updating this annotation on the Deployment's pod template forces a new ReplicaSet to be created, picking up the latest ConfigMap data.

Exam trap

The trap here is that candidates often confuse the annotation used for rollout restarts with non-existent or vendor-specific annotations, or they mistakenly think that updating a ConfigMap automatically triggers a Pod restart without any additional action.

How to eliminate wrong answers

Option A is wrong because `configmap.kubernetes.io/update-trigger` is not a standard Kubernetes annotation; the correct mechanism for triggering updates on ConfigMap changes is through checksum annotations or `kubectl rollout restart`. Option B is wrong because `field.cattle.io/updateStrategy` is a Rancher-specific annotation used for cattle-style update strategies, not a standard Kubernetes annotation for rollout restarts. Option C is wrong because `kubectl.kubernetes.io/last-applied-configuration` is used by `kubectl apply` to store the previous configuration for diff and merge purposes, not to trigger a rollout restart.

Practice this question →

15

MCQhard

A HorizontalPodAutoscaler (HPA) is configured for a Deployment with 5 replicas. The HPA is using average CPU utilization, target 50%. You observe that the actual CPU usage is 40% and the HPA does not scale down. What is the most likely reason?

A.The HPA is using the wrong metric.

B.The Deployment's rolling update is in progress.

C.The HPA's minReplicas is set to 5.

D.The HPA's downscale stabilization window is preventing immediate scale down.

AnswerD

The default stabilization window is 5 minutes, which prevents scaling down too quickly.

Why this answer

The HPA's default behavior includes a downscale stabilization window (specified by the `--horizontal-pod-autoscaler-downscale-stabilization` flag, defaulting to 5 minutes). This window prevents rapid flapping by requiring the desired replica count to remain stable for the duration of the window before a scale-down is executed. Since the actual CPU usage (40%) is below the target (50%), the HPA would normally calculate a lower desired replica count, but the stabilization window delays the actual scale-down action.

Exam trap

CNCF often tests the concept that the HPA's downscale stabilization window (default 5 minutes) can delay or prevent immediate scale-down, even when metrics clearly indicate a lower replica count is needed, confusing candidates who assume scaling is instantaneous.

How to eliminate wrong answers

Option A is wrong because the HPA is correctly using average CPU utilization, and the metric (40%) is valid and below the target (50%), so the metric itself is not the issue. Option B is wrong because a rolling update in progress does not prevent the HPA from scaling down; the HPA works independently of update strategies and would still adjust replicas based on metrics. Option C is wrong because if minReplicas were set to 5, the HPA would not scale below 5, but the current replica count is already 5, so scaling down would reduce below 5 — which minReplicas would block, but the question states the HPA 'does not scale down' despite being at 5 replicas, implying the block is due to the stabilization window, not minReplicas (which would prevent scaling below 5, not prevent scaling down from 5 to a lower number).

Practice this question →

16

Multi-Selecthard

Which TWO of the following are true about a HorizontalPodAutoscaler (HPA) using average CPU utilization? (Select TWO)

Select 2 answers

A.The HPA calculates utilization as the average CPU usage across all pods divided by the CPU request per pod

B.If a pod does not have a CPU request, the HPA cannot calculate its CPU utilization

C.The HPA target is an absolute CPU value, not a percentage

D.If the average CPU utilization exceeds the target, the HPA will scale down

E.The HPA uses CPU limits in its calculation of average utilization

AnswersA, B

Utilization = average usage / request.

Why this answer

Options A and B are correct. The HPA uses the request value to calculate utilization (actual usage / request). If a pod has no resource requests, the HPA cannot calculate CPU utilization.

Option C is incorrect because the HPA target utilization is a percentage of the request, not an absolute value. Option D is incorrect because scaling down occurs when average utilization is below the target. Option E is incorrect because the HPA does not use limits for average utilization calculation; it uses requests.

Practice this question →

17

MCQmedium

A Deployment named 'web-app' has 5 replicas. You want to perform a rolling update with a maximum of 3 pods unavailable during the update and a maximum of 2 extra pods above the desired count. Which YAML snippet correctly sets the rolling update strategy?

A.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 3

B.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 2

C.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 3

D.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 2

AnswerD

Correctly sets maxUnavailable to 3 and maxSurge to 2.

Why this answer

The rolling update strategy is configured under spec.strategy.rollingUpdate with maxUnavailable and maxSurge fields. Option B correctly sets maxUnavailable to 3 and maxSurge to 2.

Practice this question →

18

Multi-Selecthard

Which THREE are valid ways to inject configuration data into a pod?

Select 3 answers

A.Use a Secret as a ConfigMap data source.

B.Mount a ConfigMap as a volume.

C.Use 'kubectl inject configmap' to inject data at runtime.

D.Set environment variables from a ConfigMap using envFrom or valueFrom.

E.Set environment variables from a Secret using envFrom or valueFrom.

AnswersB, D, E

ConfigMaps can be mounted as volumes to provide files to containers.

Why this answer

Options A, C, and D are correct. ConfigMaps can be mounted as volumes or injected as environment variables. Secrets can also be injected as environment variables.

Option B is incorrect because there is no such thing as 'kubectl inject configmap'; injection is done via pod spec. Option E is incorrect because Secrets cannot be used as ConfigMap data; they are separate resources.

Practice this question →

19

MCQhard

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?

A.The scheduler will preempt the lower-priority pod to schedule the high-priority pod

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

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

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

AnswerA

If a pod cannot be scheduled due to resource constraints, the scheduler can preempt lower-priority pods to free resources.

Why this answer

Option A is correct. Priority-based preemption allows a higher-priority pod to preempt lower-priority pods to free up resources. The scheduler will evict the lower-priority pod to make room.

Option B is incorrect because preemption does not happen until scheduling. Option C is incorrect because preemption is enabled by default. Option D is incorrect because the higher-priority pod will be scheduled after preemption.

Practice this question →

20

MCQmedium

You create a ConfigMap named 'app-config' with key 'database.url'. Which command correctly creates a pod that injects this ConfigMap value as an environment variable named 'DB_URL'?

A.kubectl run my-pod --image=nginx --envFrom=configmap/app-config

B.Create a pod YAML with env.valueFrom.configMapKeyRef

C.kubectl run my-pod --image=nginx --env="DB_URL=configmap:app-config:database.url"

D.kubectl run my-pod --image=nginx --from-configmap=app-config

AnswerB

This is the correct Kubernetes-native way to inject a specific key from a ConfigMap as an environment variable.

Why this answer

The correct command uses kubectl run with --env and references the ConfigMap value: --env=DB_URL=$(kubectl get configmap app-config -o jsonpath='{.data.database\.url}'). However, this is complex; typically you'd use a pod spec. But among options, the one that uses --from-configmap is not valid for kubectl run.

The correct approach in a pod spec is to use valueFrom.configMapKeyRef. For command-line, we need to create a pod with inline env. Option C is closest by using envFrom with a configMapRef.

Note: kubectl run does not support envFrom directly; you'd use a YAML. But for the sake of question, choose the best answer.

Practice this question →

21

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' from a file 'config.properties'?

A.kubectl apply configmap app-config config.properties

B.kubectl create configmap app-config --from-literal=config.properties

C.kubectl create configmap app-config --from-env-file=config.properties

D.kubectl create configmap app-config --from-file=config.properties

AnswerD

Correct syntax to create ConfigMap from a file.

Why this answer

Option D is correct because `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the contents of the file 'config.properties'. The `--from-file` flag reads the file as-is and stores its content under a key that defaults to the filename (config.properties). This is the standard method for creating a ConfigMap from a single file.

Exam trap

The trap here is confusing `--from-file` with `--from-env-file` or `--from-literal`, where candidates mistakenly think `--from-env-file` is the correct way to import a properties file, but `--from-env-file` parses the file line by line for KEY=VALUE pairs and does not preserve the raw file content.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` is used to apply a configuration to a resource from a file (typically YAML/JSON), not to create a ConfigMap from a properties file; the syntax is invalid. Option B is wrong because `--from-literal` expects key=value pairs directly in the command, not a filename; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal key without a value, not read the file. Option C is wrong because `--from-env-file` is used to import key-value pairs from a file formatted as environment variables (e.g., KEY=VALUE per line), but it does not preserve the raw file content; it parses the file and creates separate keys, which is not the same as storing the entire file under a single key.

Practice this question →

22

MCQmedium

You have a DaemonSet that runs on all nodes. You need to ensure it does NOT run on a node labeled 'disk=ssd'. Which field in the DaemonSet spec should you use?

A.spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution with NotIn operator

B.spec.template.spec.nodeSelector with disk: ssd

C.spec.template.spec.tolerations with key disk value ssd

D.spec.updateStrategy.rollingUpdate.maxUnavailable

AnswerA

This anti-affinity rule ensures pods are not scheduled on nodes with disk=ssd.

Why this answer

Option A is correct because `nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution` with the `NotIn` operator allows you to specify that the DaemonSet pod must not be scheduled on nodes with the label `disk=ssd`. This is the proper way to express an anti-affinity rule that excludes nodes based on a label value, ensuring the DaemonSet runs on all nodes except those with `disk=ssd`.

Exam trap

The trap here is that candidates often confuse `nodeSelector` (which selects nodes to include) with the need to exclude nodes, and they may incorrectly choose `nodeSelector` with a negative label value, not realizing that `nodeSelector` only supports equality-based inclusion, not exclusion.

How to eliminate wrong answers

Option B is wrong because `nodeSelector` with `disk: ssd` would require the pod to run only on nodes with that label, which is the opposite of the desired behavior (it would restrict the DaemonSet to SSD nodes instead of excluding them). Option C is wrong because `tolerations` are used to allow pods to be scheduled on nodes with taints, not to control scheduling based on node labels; tolerations do not prevent scheduling on nodes with a specific label. Option D is wrong because `spec.updateStrategy.rollingUpdate.maxUnavailable` controls the number of pods that can be unavailable during a rolling update of the DaemonSet, not the scheduling constraints for which nodes the DaemonSet runs on.

Practice this question →

23

MCQeasy

Which command creates a ConfigMap named 'app-config' from a file 'config.properties'?

A.kubectl create cm app-config --file=config.properties

B.kubectl create configmap app-config --from-literal=config.properties

C.kubectl create configmap app-config --from-env-file=config.properties

D.kubectl create configmap app-config --from-file=config.properties

AnswerD

Correct.

Why this answer

Option D is correct because `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the contents of the specified file. The `--from-file` flag reads the file and stores its entire content as a key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content.

Exam trap

The trap here is confusing `--from-file` (which imports a file's content as a ConfigMap entry) with `--from-env-file` (which imports environment variables from a file), or using the non-existent `--file` flag, leading candidates to select options that either use the wrong flag or misinterpret the file's purpose.

How to eliminate wrong answers

Option A is wrong because `kubectl create cm` is a valid alias for `kubectl create configmap`, but the flag `--file=config.properties` does not exist; the correct flag is `--from-file`. Option B is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to read from a file; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal value, not a file path. Option C is wrong because `--from-env-file` is used to import environment variables from a file formatted as key=value lines (like a .env file), but it expects the file to contain multiple lines of environment variables, not a single file's content as a ConfigMap entry.

Practice this question →

24

MCQhard

You create a Pod with an init container and a main container. The init container runs a script that writes to a shared volume. The main container reads from that volume. However, the Pod is stuck in 'Init:CrashLoopBackOff'. What is the most likely cause?

A.The init container is waiting for the main container to start

B.The init container's command is failing due to an error in the script

C.The main container has a resource limit that is too low

D.The shared volume is not mounted with the correct permissions

AnswerB

Init container crash loops usually indicate a failing command.

Why this answer

Option C is correct. If the init container is in CrashLoopBackOff, it means it is failing repeatedly. The most common cause is that the init container's command is failing (e.g., script error, missing dependencies).

Option A is incorrect because resource limits on the main container do not affect init containers. Option B is incorrect because volume permissions would cause runtime issues, but the init container would still run. Option D is incorrect because init containers run sequentially; if one fails, the next does not start.

Practice this question →

25

Multi-Selecteasy

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

Select 2 answers

A.Editing the pod's spec directly via kubectl edit

B.Using a Sidecar container to fetch config from a remote API

C.Mounting a ConfigMap as a volume

D.Injecting a ConfigMap as environment variables

E.Storing config in a PersistentVolume

AnswersC, D

Correct. ConfigMap can be mounted as a volume.

Why this answer

Correct options: A and D. ConfigMaps can be mounted as volumes or injected as environment variables. Secrets can also be used similarly.

Option B is not a method; direct editing is not injection. Option C is not standard. Option E is for storing raw data, not injecting.

Practice this question →

26

MCQmedium

A Deployment has been updated with a new image, but the rollout is stuck. You run 'kubectl rollout status deployment/my-app' and see 'Waiting for rollout to finish: 2 out of 5 new replicas have been updated...'. The deployment's strategy is RollingUpdate with maxSurge: 25% and maxUnavailable: 25%. What is the most likely cause?

A.The rollout is complete; the status message is misleading.

B.The new pods are unable to start due to resource constraints on nodes.

C.The deployment has a missing selector label.

D.The old ReplicaSet is not scaling down because the new ReplicaSet has not met the minReadySeconds.

AnswerB

If new pods fail to become Ready, the rollout cannot proceed because maxUnavailable prevents scaling down old pods beyond 25%.

Why this answer

The rollout status shows that only 2 out of 5 new replicas have been updated, indicating that the new Pods are failing to become Ready. Given the RollingUpdate strategy with maxSurge: 25% and maxUnavailable: 25%, the controller can create up to 1 extra Pod (25% of 5 = 1.25, rounded up) and can terminate up to 1 old Pod at a time. If new Pods cannot start due to resource constraints (e.g., insufficient CPU/memory), they will remain in a Pending or CrashLoopBackOff state, preventing the ReplicaSet from reaching the desired count and stalling the rollout.

Exam trap

The trap here is that candidates may confuse a stuck rollout with a missing selector or minReadySeconds issue, but the partial progress (2 out of 5) strongly points to Pod startup failures, not configuration mismatches or timing delays.

How to eliminate wrong answers

Option A is wrong because the rollout is explicitly not complete; the status message indicates 2 out of 5 new replicas have been updated, and the command is still waiting, meaning the rollout is in progress or stuck. Option C is wrong because a missing selector label would cause the Deployment to fail to match any Pods entirely, resulting in zero replicas being created, not a partial update of 2 out of 5. Option D is wrong because minReadySeconds affects how long a Pod must be Ready before the controller considers it available, but the issue here is that new Pods are not becoming Ready at all, not that they are waiting for a stabilization period.

Practice this question →

27

MCQmedium

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?

A.4

B.16

C.6

D.8

AnswerD

4000m / 500m = 8 pods based on CPU requests.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse CPU cores with millicores (e.g., thinking 4 cores means 4 pods at 500m each, or miscomputing 500m as half a core leading to 8 pods but then incorrectly dividing by memory limits).

How to eliminate wrong answers

Option A is wrong because 4 pods would only use 2000m CPU, leaving half the node's CPU unused, which is not the maximum. Option B is wrong because 16 pods would require 8000m CPU, exceeding the node's 4000m capacity. Option C is wrong because 6 pods would use 3000m CPU, still leaving 1000m unused, so it is not the maximum.

Practice this question →

28

MCQmedium

You have a CronJob that runs a backup job every 5 minutes. The job takes about 2 minutes to complete. You notice that sometimes two job pods are running simultaneously. What is the most likely cause?

A.The backup takes longer than expected due to data volume.

B.The concurrencyPolicy is set to 'Allow' (default) which permits overlapping executions.

C.The job's parallelism is set to 2.

D.The CronJob's startingDeadlineSeconds is set too low.

AnswerB

Default concurrencyPolicy is Allow, so new jobs can start before old ones finish.

Why this answer

Option B is correct because the default `concurrencyPolicy` for a CronJob is `Allow`, which permits new Job pods to start even if a previous Job is still running. Since the backup takes 2 minutes and the CronJob runs every 5 minutes, overlapping executions should not normally occur unless the Job duration exceeds the interval. However, if the `concurrencyPolicy` is set to `Allow`, the CronJob controller will create a new Job pod regardless of whether the previous one is still running, leading to simultaneous pods.

The most likely cause is that the `concurrencyPolicy` is explicitly or implicitly set to `Allow`, allowing overlapping executions.

Exam trap

The trap here is that candidates often assume the default `concurrencyPolicy` is `Forbid` or that CronJobs inherently prevent overlapping executions, but the default is actually `Allow`, which permits concurrent runs unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because the backup taking longer than expected due to data volume would cause the Job to run longer, but it does not explain why two pods are running simultaneously; with the default `Forbid` concurrency policy, a new pod would not be created until the previous one completes. Option C is wrong because `parallelism` is a property of a Job, not a CronJob; it controls how many Pods run in parallel for a single Job execution, not whether multiple Job executions can overlap. Option D is wrong because `startingDeadlineSeconds` controls how long the CronJob controller will try to start a missed Job after its scheduled time; it does not affect whether concurrent executions are allowed.

Practice this question →

29

Multi-Selecteasy

Which TWO of the following are valid methods to expose ConfigMap data to pods?

Select 2 answers

A.As environment variables

B.As a Kubernetes Service

C.As a container command argument

D.As a Pod annotation

E.As a volume mount

AnswersA, E

Using configMapKeyRef in env.

Why this answer

Option A is correct because ConfigMap data can be injected into a pod as environment variables using the `envFrom` or `env` field in the pod spec, referencing the ConfigMap name and keys. This allows the pod to consume configuration values as standard environment variables, which are accessible to the container runtime at process startup.

Exam trap

The trap here is that candidates may confuse 'exposing data to pods' with 'using data in pod definitions,' leading them to select command arguments (option C) as a direct method, when in fact command arguments require an intermediate exposure method like environment variables or volume mounts to supply the ConfigMap values.

Practice this question →

30

MCQmedium

You need to schedule a pod on a node with label 'disktype=ssd'. Which field should you add to the pod spec?

A.nodeSelector

B.tolerations

C.nodeName

D.affinity.nodeAffinity

AnswerA

nodeSelector with key disktype and value ssd schedules the pod on matching nodes.

Why this answer

The `nodeSelector` field in a Pod spec is the simplest and most direct way to constrain a Pod to nodes that have a specific label. By setting `nodeSelector` with `disktype: ssd`, the scheduler will only consider nodes that have the label `disktype=ssd` for placement. This is a hard constraint that does not require any additional configuration on the nodes.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with `nodeAffinity` or `tolerations`, thinking that `nodeAffinity` is always required for label-based scheduling, or that `tolerations` can select nodes by labels, when in fact `nodeSelector` is the simplest and correct field for a single label match.

How to eliminate wrong answers

Option B (tolerations) is wrong because tolerations allow a Pod to be scheduled on nodes that have matching taints, but they do not select nodes based on labels; they are used to bypass taint restrictions, not to enforce label-based scheduling. Option C (nodeName) is wrong because `nodeName` directly assigns the Pod to a specific node by name, bypassing the scheduler entirely and ignoring any label-based selection; it is not a flexible scheduling constraint. Option D (affinity.nodeAffinity) is wrong because while `nodeAffinity` can also select nodes based on labels, it is a more advanced and complex feature that includes both required and preferred rules; for a simple label match like `disktype=ssd`, `nodeSelector` is the correct and minimal field to use.

Practice this question →

31

MCQmedium

You have a Deployment with 5 replicas. During a rolling update, you want to ensure that at most 3 pods are unavailable at any time. Which field should you set in the Deployment's strategy?

A.replicas: 3

B.minReadySeconds: 3

C.maxUnavailable: 3

D.maxSurge: 3

AnswerC

maxUnavailable limits the number of pods that can be unavailable during update.

Why this answer

Option B is correct. The 'maxUnavailable' field specifies the maximum number of pods that can be unavailable during the rolling update. Setting it to 3 means at most 3 pods can be down at once.

Option A is incorrect because maxSurge specifies how many extra pods can be created above the desired count. Option C is incorrect because replicas is the desired number. Option D is incorrect because minReadySeconds affects readiness, not availability during update.

Practice this question →

32

MCQhard

A pod with priorityClassName: high is pending. You describe the pod and see the event: '0/3 nodes are available: 3 node(s) didn't match pod affinity/anti-affinity, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod has required anti-affinity to avoid co-location with pods from the same app. How can you get the pod scheduled?

A.Add a toleration for the control-plane taint.

B.Increase the number of replicas of the app to spread the pods.

C.Delete the existing pods of the same app to free up nodes.

D.Change the anti-affinity rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution.

AnswerD

Changing to preferred makes the rule a soft requirement, allowing the scheduler to place the pod even if the rule cannot be met.

Why this answer

The pod is pending because its required anti-affinity rule cannot be satisfied on any node: all 3 nodes either have a control-plane taint (which the pod doesn't tolerate) or already host pods from the same app, violating the anti-affinity. Changing the rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a soft constraint, allowing the scheduler to place the pod on a node even if it means co-locating with same-app pods, thus resolving the scheduling conflict.

Exam trap

The trap here is that candidates focus on the taint error (which is only one node) and mistakenly think adding a toleration will solve the problem, ignoring the more fundamental anti-affinity constraint that affects all three nodes.

How to eliminate wrong answers

Option A is wrong because the pod's event explicitly states '1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate', but the primary issue is that 3 nodes didn't match pod affinity/anti-affinity — adding a toleration for the control-plane taint would only address one node, not the anti-affinity constraint blocking all nodes. Option B is wrong because increasing replicas would create more pods of the same app, which would worsen the anti-affinity conflict by requiring even more nodes that don't have same-app pods, making scheduling harder. Option C is wrong because deleting existing pods of the same app would free up nodes for the pending pod, but this is a manual, disruptive workaround that doesn't fix the underlying scheduling policy; the correct solution is to adjust the anti-affinity rule to be a preference rather than a requirement.

Practice this question →

33

MCQmedium

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?

A.4

B.3

C.5

D.6

AnswerA

maxSurge=1, so total running pods can be up to 4.

Why this answer

With maxSurge=50% (rounded up to 1) and maxUnavailable=0, the Deployment can create up to 1 extra pod above the desired 3 during a rolling update. Therefore, the maximum number of pods running simultaneously is 3 (desired) + 1 (surge) = 4.

Exam trap

The trap here is that candidates often forget that maxSurge is rounded up (ceil) when expressed as a percentage, leading them to miscalculate the surge as 1.5 (which rounds to 2) instead of correctly rounding 50% of 3 to 1.

How to eliminate wrong answers

Option B (3) is wrong because it ignores the maxSurge setting, which allows extra pods to be created during the rollout, so the count can exceed the desired replicas. Option C (5) is wrong because it incorrectly assumes maxSurge=50% allows 2 extra pods (50% of 3 rounded up is 1, not 2). Option D (6) is wrong because it doubles the desired replicas, which would only occur with maxSurge=100% or a different configuration.

Practice this question →

34

Multi-Selecthard

Which THREE of the following are true about HorizontalPodAutoscaler (HPA)?

Select 3 answers

A.HPA can use custom metrics from the Kubernetes Metrics Server.

B.HPA supports in-place pod resizing.

C.HPA cannot scale based on memory utilization.

D.HPA can be configured with target average CPU utilization.

E.HPA can scale Deployments and StatefulSets.

AnswersA, D, E

HPA can use custom metrics via the custom.metrics.k8s.io API.

Why this answer

Option A is correct because the HorizontalPodAutoscaler (HPA) can use custom metrics provided by the Kubernetes Metrics Server, such as requests per second or queue length, in addition to standard CPU and memory metrics. The HPA retrieves these metrics via the `metrics.k8s.io` API (for resource metrics) or custom metrics APIs, enabling scaling based on application-specific behavior.

Exam trap

The trap here is that candidates often assume HPA only supports CPU metrics, but it also supports memory and custom metrics, and they confuse horizontal scaling (replicas) with vertical scaling (in-place resizing), which is not supported by HPA.

Practice this question →

35

MCQmedium

You have a CronJob that runs a batch job every 5 minutes. The job takes about 2 minutes to complete. However, if a job takes longer than 5 minutes, you want to prevent a new job from starting until the previous one finishes. Which CronJob field should you configure?

A.successfulJobsHistoryLimit

B.concurrencyPolicy: Forbid

C.suspend: true

D.startingDeadlineSeconds

AnswerB

Setting concurrencyPolicy to Forbid ensures only one job is running at a time; new jobs are skipped if the previous hasn't completed.

Why this answer

The `concurrencyPolicy` field in a CronJob spec controls how the controller handles overlapping job executions. Setting it to `Forbid` ensures that if a previous job is still running when the next scheduled time arrives, the new job is skipped, preventing concurrent runs. This directly addresses the requirement to block a new job from starting until the previous one finishes.

Exam trap

The trap here is that candidates often confuse `concurrencyPolicy` with `suspend` or `startingDeadlineSeconds`, mistakenly thinking pausing or delaying the job will solve the overlap issue, when only `Forbid` explicitly prevents concurrent runs.

How to eliminate wrong answers

Option A is wrong because `successfulJobsHistoryLimit` controls how many completed jobs are retained for inspection, not the concurrency behavior of running jobs. Option C is wrong because `suspend: true` pauses the entire CronJob, preventing any new jobs from being created at all, rather than conditionally blocking only when a previous job is still running. Option D is wrong because `startingDeadlineSeconds` sets a time window for starting a missed job if the CronJob controller is down, but it does not affect concurrency control.

Practice this question →

36

MCQeasy

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

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

B.kubectl edit deployment webapp --replicas=5

C.kubectl scale deployment webapp --replicas=5

D.kubectl update deployment webapp --replicas=5

AnswerC

'kubectl scale' directly changes the replica count.

Why this answer

Option B is correct. 'kubectl scale' is the command to scale resources. Option A is incorrect because 'kubectl update' does not exist. Option C is incorrect because 'kubectl edit' opens an editor, not a direct scale.

Option D is incorrect because 'kubectl patch' can be used but is more complex than necessary.

Practice this question →

37

MCQhard

A StatefulSet named 'db' has 3 replicas. You need to update the pod template to change the resource limits. After applying the change, you run 'kubectl rollout status sts db' and it hangs. What is the most likely reason?

A.The update strategy is set to OnDelete, and you need to delete pods manually.

B.The StatefulSet's pod management policy is OrderedReady, and the first pod to update (db-2) is not becoming Ready.

C.The maxSurge setting is preventing the update from starting.

D.The StatefulSet's service name is incorrect, causing DNS resolution failures.

AnswerB

StatefulSet updates pods in reverse ordinal order, waiting for each to become Ready before proceeding. If db-2 fails to become Ready, the rollout hangs.

Why this answer

Option B is correct because StatefulSets with the default OrderedReady pod management policy update pods sequentially in reverse order (from highest ordinal to lowest). When `kubectl rollout status sts db` hangs, it indicates that the update is stuck waiting for the first pod in the update sequence (db-2) to become Ready. If db-2 fails to become Ready due to the new resource limits (e.g., insufficient cluster resources or misconfigured limits), the rollout cannot proceed to update db-1 and db-0, causing the command to hang indefinitely.

Exam trap

The trap here is that candidates confuse StatefulSet update behavior with Deployment behavior, assuming that maxSurge or maxUnavailable settings control the rollout, when in fact StatefulSets do not support those fields and rely on ordered pod management.

How to eliminate wrong answers

Option A is wrong because the OnDelete update strategy requires manual pod deletion to trigger updates, but the question states that the rollout status command hangs, implying the update was applied and is waiting for pods to become Ready—not that pods are untouched. Option C is wrong because StatefulSets do not support a maxSurge setting; maxSurge is a field for Deployments, not StatefulSets, and StatefulSets use a rolling update with partition or podManagementPolicy instead. Option D is wrong because an incorrect service name would cause DNS resolution failures for pod-to-pod communication, but it would not prevent the StatefulSet controller from updating pods or cause the rollout status to hang; the controller would still proceed with the update regardless of DNS issues.

Practice this question →

38

MCQmedium

You want to mount a Secret named 'db-secret' as a volume in a pod. Which volume type should you use in the pod spec?

A.hostPath

B.configMap

C.emptyDir

D.secret

AnswerD

The secret volume type mounts a Kubernetes Secret as a read-only volume.

Why this answer

Option D is correct because Kubernetes provides a dedicated 'secret' volume type specifically designed to mount Secret objects (like 'db-secret') as files into a pod. This volume type automatically handles decryption and projection of the secret data into the container's filesystem, ensuring sensitive information is securely exposed without being stored in the pod definition or environment variables.

Exam trap

The trap here is that candidates confuse ConfigMap and Secret volume types, thinking ConfigMap can mount Secrets because both store key-value data, but Kubernetes enforces strict separation: Secrets require the 'secret' volume type for security and proper handling of sensitive data.

How to eliminate wrong answers

Option A is wrong because hostPath mounts a file or directory from the host node's filesystem into the pod, not a Kubernetes Secret object; it bypasses Secret management entirely and is used for node-level access. Option B is wrong because configMap volume type mounts ConfigMap objects (which store non-sensitive configuration data), not Secrets; Secrets require the 'secret' volume type to handle encryption and base64 encoding properly. Option C is wrong because emptyDir creates an empty temporary directory that is initially empty and shared between containers in the pod; it cannot directly mount a Secret's contents without manual population.

Practice this question →

39

MCQhard

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?

A.Pods web-3 and web-4 are created in parallel, both sharing the same PVC

B.The existing pods are recreated with new PVCs

C.Pods web-3 and web-4 are created sequentially, each with its own PVC

D.Only web-3 is created because the StatefulSet cannot exceed 4 replicas

AnswerC

Correct. OrderedReady creates pods one by one, each with a unique PVC from the template.

Why this answer

Option C is correct because 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.

Exam trap

The trap here is that candidates may confuse the default OrderedReady policy with the Parallel pod management policy, or mistakenly think that scaling a StatefulSet recreates existing pods or imposes an arbitrary replica limit.

How to eliminate wrong answers

Option A is wrong because the default OrderedReady policy does not allow parallel creation; pods are created one at a time, and each pod gets its own PVC, not a shared one. Option B is wrong because scaling up does not recreate existing pods; only new pods are added, and existing pods retain their original PVCs. Option D is wrong because there is no hard limit of 4 replicas for a StatefulSet; the maximum is determined by the ordinal index, which can increase without such a restriction.

Practice this question →

40

MCQmedium

A StatefulSet named 'mysql' is deployed with 3 replicas. A developer reports that the pod 'mysql-0' is failing due to persistent volume issues. After fixing the underlying storage, they want to recreate 'mysql-0' while preserving its stable network identity. What is the correct approach?

A.Delete the StatefulSet and recreate it with the same configuration

B.Use kubectl replace --force on the StatefulSet to recreate the pod

C.Scale the StatefulSet down to 0 replicas, then scale back up to 3

D.Delete the pod 'mysql-0' using kubectl delete pod mysql-0, and let the StatefulSet controller recreate it

AnswerD

The controller will recreate the pod with the same name and stable network identity.

Why this answer

Option B is correct. Deleting a StatefulSet pod with kubectl delete pod will cause the StatefulSet controller to recreate it with the same name and identity. Option A is wrong because scaling down then up would recreate all pods and potentially lose the identity of mysql-0.

Option C is wrong because you cannot recreate a pod that still exists. Option D is wrong because deleting the entire StatefulSet would delete all pods and PVCs.

Practice this question →

41

Multi-Selectmedium

Which TWO commands can be used to view the rollout history of a Deployment?

Select 2 answers

A.kubectl get deployment my-app -o wide

B.kubectl get deployment my-app -o yaml

C.kubectl describe deployment my-app

D.kubectl rollout status deployment/my-app

E.kubectl rollout history deployment/my-app

AnswersC, E

The describe output includes annotations that show change-cause and revision history.

Why this answer

Option C is correct because `kubectl describe deployment my-app` includes a 'RollingUpdateStrategy' section and a list of revision numbers under 'OldReplicaSets' and 'NewReplicaSet', which effectively shows the rollout history by displaying the current and previous ReplicaSets. Option E is correct because `kubectl rollout history deployment/my-app` is the dedicated command to list all revisions of a Deployment, showing revision numbers and change causes.

Exam trap

The trap here is that candidates often confuse `kubectl describe` (which shows current ReplicaSets but not a clean history list) with `kubectl rollout history` (the dedicated command), or mistakenly think `kubectl get -o yaml` or `-o wide` expose rollout history, when they only show the current state.

Practice this question →

42

MCQmedium

You have a DaemonSet named 'fluentd' that is intended to run on all worker nodes. After deploying, you notice that the DaemonSet pods are not running on a node that has the label 'node-type=worker'. What is the most likely reason?

A.The DaemonSet has a nodeSelector that does not match the node's labels

B.The node has taints that the DaemonSet does not tolerate

C.The node has insufficient resources to run the DaemonSet pod

D.The DaemonSet's ReplicaSet is not managing the pods correctly

AnswerB

Taints without tolerations prevent pod scheduling on the node.

Why this answer

Option C is correct. Taints on the node would prevent pods from being scheduled unless the pod has a matching toleration. If the DaemonSet does not have tolerations for the node's taints, the pods will not be scheduled on that node.

Option A is incorrect because nodeSelector would prevent scheduling only if the node does not have the label, but the node has the label. Option B is incorrect because resource requests would cause pods to be pending, not simply not running. Option D is incorrect because DaemonSets are not affected by ReplicaSets.

Practice this question →

43

MCQmedium

You have a DaemonSet that runs a logging agent. You want to ensure it only runs on nodes with GPU. Which field should you set in the DaemonSet's pod template spec?

A.spec.selector

B.spec.template.spec.nodeSelector

C.spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

D.spec.template.spec.nodeName

AnswerB

nodeSelector constrains which nodes the pod can be scheduled on based on labels.

Why this answer

Option B is correct because `spec.template.spec.nodeSelector` is a simple, direct field in the Pod template spec that constrains which nodes the DaemonSet's pods can be scheduled on. By setting a key-value pair like `gpu: true`, you ensure the logging agent only runs on nodes that have that label, which is the standard Kubernetes mechanism for node-level selection without complex expressions.

Exam trap

The trap here is that candidates often confuse `spec.selector` (which manages pod ownership) with `nodeSelector` (which manages scheduling constraints), or they over-engineer by choosing node affinity when the simpler `nodeSelector` is sufficient for the question's requirement.

How to eliminate wrong answers

Option A is wrong because `spec.selector` is a label selector used by the DaemonSet controller to identify which pods it manages, not to constrain scheduling to specific nodes. Option C is wrong because `spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution` is a more advanced and verbose way to achieve node selection, but the question asks for the simplest field to set, and `nodeSelector` is the correct minimal answer. Option D is wrong because `spec.template.spec.nodeName` directly assigns a pod to a specific node by name, bypassing the scheduler entirely, which is inflexible and not suitable for a DaemonSet that should run on multiple nodes matching a condition.

Practice this question →

44

MCQeasy

What is the purpose of a PriorityClass in Kubernetes scheduling?

A.To set the quality of service class for a pod

B.To define which nodes are eligible for pod scheduling

C.To assign a priority value that determines the order pods are considered by the scheduler

D.To control the order in which containers are started inside a pod

AnswerC

Higher priority pods are scheduled first and can preempt lower priority pods.

Why this answer

PriorityClass in Kubernetes assigns an integer priority value to pods, which the scheduler uses to determine the order in which pods are considered for scheduling. Higher-priority pods are scheduled before lower-priority ones, and during resource contention, lower-priority pods may be preempted to make room for higher-priority pods. This ensures critical workloads get precedence over less important ones.

Exam trap

The trap here is that candidates confuse PriorityClass with QoS classes (Option A) or think it controls node selection (Option B), when in fact PriorityClass strictly governs scheduling priority and preemption behavior.

How to eliminate wrong answers

Option A is wrong because Quality of Service (QoS) classes (Guaranteed, Burstable, BestEffort) are determined by resource requests and limits, not by PriorityClass. Option B is wrong because node eligibility is controlled by node selectors, node affinity, taints/tolerations, and node labels, not by PriorityClass. Option D is wrong because the order of container startup inside a pod is controlled by container lifecycle hooks and init containers, not by PriorityClass.

Practice this question →

45

MCQmedium

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?

A.Do nothing; wait for stabilization

B.Scale up to 3 replicas

C.Scale up to 4 replicas

D.Scale down to 1 replica because utilization is too high

AnswerB

Correct. Desired = ceil(90/80 * 2) = 3.

Why this answer

Option B is correct. HPA scales up when current utilization exceeds target. Current = 90% > target 80%, so it will increase replicas.

It calculates desired replicas = ceil(currentUtilization/target * currentReplicas) = ceil(90/80 * 2) = ceil(2.25) = 3, so it scales to 3.

Practice this question →

46

Multi-Selectmedium

Which TWO of the following are valid ways to expose environment variables from a ConfigMap to a pod? (Select TWO.)

Select 2 answers

A.Using envFrom with secretRef

B.Using env field with configMapKeyRef directly

C.Using envFrom with configMapRef

D.Mounting the ConfigMap as a volume, which automatically sets environment variables

E.Using env field with valueFrom and configMapKeyRef

AnswersC, E

envFrom loads all keys from a ConfigMap as environment variables.

Why this answer

Option C is correct because `envFrom` with `configMapRef` allows you to inject all key-value pairs from a ConfigMap as environment variables into a pod, which is a concise way to expose ConfigMap data without specifying each key individually. This is a native Kubernetes feature that automatically creates environment variables for each entry in the ConfigMap.

Exam trap

The trap here is that candidates confuse `envFrom` with `configMapRef` (which injects all keys) with the `env` field using `valueFrom` and `configMapKeyRef` (which injects a single key), and they may also mistakenly think mounting a ConfigMap as a volume sets environment variables, when it actually creates files.

Practice this question →

47

MCQmedium

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?

A.kubectl describe job/pi-job

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

C.kubectl log job/pi-job

D.kubectl logs job/pi-job

AnswerD

You can view logs of a completed pod using 'kubectl logs' with the job name.

Why this answer

Option D is correct because `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.

Exam trap

The trap here is that candidates confuse `kubectl logs` with `kubectl exec` or `kubectl describe`, or they miss the correct syntax `kubectl logs job/<name>` versus the invalid `kubectl log`.

How to eliminate wrong answers

Option A is wrong because `kubectl describe job/pi-job` shows metadata, status, and events of the Job, but does not display pod logs. Option B is wrong because `kubectl exec` requires a running pod to execute commands; after the pod completes, it is in a terminated state and cannot be exec'd into. Option C is wrong because the command `kubectl log` is not a valid kubectl command; the correct verb is `logs`.

Practice this question →

48

MCQmedium

You want to ensure that a pod only runs on nodes that have a GPU. Nodes with GPUs are labeled with 'gpu=true'. Which scheduling constraint should you use?

A.spec.nodeName: gpu-node

B.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution

C.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

D.spec.nodeSelector: { gpu: "true" }

AnswerD

nodeSelector directly requires the node to have the label gpu=true.

Why this answer

Option B is correct. nodeSelector is the simplest way to require a node label. Option A (nodeName) is for specific node names. Option C (nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution) can also be used, but nodeSelector is more straightforward for a simple equality.

Option D (podAffinity) is for scheduling pods relative to other pods, not nodes.

Practice this question →

49

Multi-Selecteasy

Which TWO of the following are valid ways to expose a ConfigMap to a pod? (Select TWO)

Select 2 answers

A.Mounting the ConfigMap as a volume

B.The ConfigMap is automatically mounted at /etc/config in the container

C.Using the ConfigMap as a container image

D.The ConfigMap is automatically available as environment variables in the pod

E.Injecting specific keys as environment variables using configMapKeyRef

AnswersA, E

ConfigMaps can be mounted as volumes.

Why this answer

Options A and D are correct. ConfigMaps can be exposed as environment variables using 'valueFrom' with 'configMapKeyRef', or as volumes mounted into the container's filesystem. Option B is incorrect because ConfigMaps are not automatically injected as environment variables; they must be explicitly referenced.

Option C is incorrect because ConfigMaps cannot be used directly as the container image. Option E is incorrect because the host's /etc/config directory is not automatically populated from ConfigMaps.

Practice this question →

50

Multi-Selecthard

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

Select 3 answers

A.NeverSchedule

B.PreferSchedule

C.NoSchedule

D.PreferNoSchedule

E.NoExecute

AnswersC, D, E

Valid taint effect.

Why this answer

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.

Exam trap

CNCF often tests the exact spelling of taint effects, and candidates confuse `PreferNoSchedule` with `PreferSchedule` or invent effects like `NeverSchedule` that do not exist in the Kubernetes API.

Practice this question →

51

MCQhard

A pod has resource requests: cpu: 250m, memory: 128Mi. The node has 2 CPU cores and 4Gi memory. What is the maximum number of such pods that can fit on this node based solely on CPU requests?

A.32

B.16

C.4

D.8

AnswerD

8 pods * 250m = 2000m, exactly filling the CPU.

Why this answer

CPU request per pod is 250m = 0.25 CPU. Node has 2 CPUs = 2000m. 2000m / 250m = 8 pods.

Practice this question →

52

MCQmedium

You need to implement a PriorityClass named 'high-priority' with value 1000 and mark it as non-preempting. Which YAML field should you set to true?

A.spec.preemptionPolicy: Never

B.spec.description: "non-preempting"

C.spec.globalDefault: true

D.spec.value: 1000

AnswerA

Setting preemptionPolicy to Never prevents pods using this PriorityClass from preempting other pods.

Why this answer

Option A is correct because setting `spec.preemptionPolicy: Never` in a PriorityClass definition marks it as non-preempting, meaning pods with this priority will not preempt lower-priority pods even if they have a higher priority value. This field is the only one that controls preemption behavior for a PriorityClass.

Exam trap

CNCF often tests the distinction between `spec.value` (which sets priority) and `spec.preemptionPolicy` (which controls preemption behavior), leading candidates to mistakenly think that a high priority value alone implies preemption or that `spec.globalDefault` affects preemption.

How to eliminate wrong answers

Option B is wrong because `spec.description` is a free-text field for human-readable notes and has no effect on preemption behavior. Option C is wrong because `spec.globalDefault: true` sets this PriorityClass as the default for all pods that do not specify a priorityClassName, but it does not affect preemption. Option D is wrong because `spec.value: 1000` sets the priority value (higher numbers indicate higher priority) but does not control preemption; preemption is governed by the `preemptionPolicy` field.

Practice this question →

53

MCQhard

A node has a taint 'gpu=true:NoSchedule'. A pod has a toleration 'key: gpu, operator: Exists, effect: NoSchedule'. Will the pod be scheduled on the node?

A.Yes, because the toleration matches the taint

B.Yes, only if the pod has a nodeSelector for gpu

C.No, because the toleration does not specify a value

D.No, because the node also has other taints

AnswerA

Toleration matches the taint, so pod can be scheduled.

Why this answer

The toleration matches the taint (key gpu, effect NoSchedule). The pod can tolerate the taint and will be scheduled on the node.

Practice this question →

54

MCQmedium

A Job named 'data-processor' completes successfully. You want to run it again with the same configuration. What is the correct way to rerun the Job?

A.Edit the Job with 'kubectl edit job data-processor' and change the template.

B.Delete the Job with 'kubectl delete job data-processor' and then recreate it.

C.Run 'kubectl rollout restart job data-processor'

D.Run 'kubectl rerun job data-processor'

AnswerB

Jobs are immutable; to rerun, you must delete and recreate.

Why this answer

Option B is correct because a completed Job in Kubernetes is immutable and cannot be rerun by editing or restarting it. The only way to execute the same Job again is to delete the existing Job and recreate it with the same configuration, as Jobs are designed to run to completion and are not intended to be restarted like Deployments.

Exam trap

The trap here is that candidates confuse Jobs with Deployments or other controllers that support rolling updates and restarts, leading them to incorrectly apply commands like 'kubectl rollout restart' or assume editing the template will trigger a new run.

How to eliminate wrong answers

Option A is wrong because editing a completed Job's template does not trigger a new run; the Job's pod template is immutable after creation, and changes require deletion and recreation. Option C is wrong because 'kubectl rollout restart' is a command for Deployments, DaemonSets, and StatefulSets, not for Jobs, which do not support rolling updates or restarts. Option D is wrong because 'kubectl rerun' is not a valid kubectl command; Kubernetes does not provide a built-in command to rerun a Job.

Practice this question →

55

MCQeasy

Which command creates a Job that runs a single pod to execute the command 'echo Hello'?

A.kubectl create job hello --image=busybox -- echo Hello

B.kubectl create cronjob hello --image=busybox -- echo Hello

C.kubectl create deployment hello --image=busybox -- echo Hello

D.kubectl run job hello --image=busybox -- echo Hello

AnswerA

This is the correct command to create a Job.

Why this answer

kubectl create job hello --image=busybox -- echo Hello creates a Job named 'hello' that runs the command 'echo Hello' in a busybox container.

Practice this question →

56

Multi-Selectmedium

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

Select 2 answers

A.DaemonSets are typically managed by a parent Deployment.

B.DaemonSets do not support rolling updates.

C.DaemonSets are often used for cluster daemons like log collectors or monitoring agents.

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

E.DaemonSets ensure that all (or some) nodes run a copy of a pod.

AnswersC, E

Common use cases for DaemonSets.

Why this answer

Option C is correct because 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.

Exam trap

The trap here is that candidates often confuse DaemonSets with Deployments, mistakenly thinking DaemonSets have a replica count or are managed by a Deployment, or that they lack update strategies, when in fact DaemonSets are independent and fully support rolling updates.

Practice this question →

57

MCQmedium

You need to schedule a pod to a specific node named 'worker-2' for testing purposes. Which field should you set in the pod spec?

A.schedulerName

B.affinity

C.nodeSelector

D.nodeName

AnswerD

Setting nodeName to 'worker-2' will schedule the pod directly to that node.

Why this answer

The `nodeName` field in the PodSpec directly assigns the pod to a specific node by name, bypassing the scheduler entirely. Setting `nodeName: worker-2` forces the kubelet on that node to run the pod, making it the correct choice for pinning a pod to a specific node for testing.

Exam trap

CNCF often tests the distinction between `nodeSelector` (label-based scheduling) and `nodeName` (direct assignment), leading candidates to choose `nodeSelector` when the question explicitly requires a specific node name.

How to eliminate wrong answers

Option A is wrong because `schedulerName` specifies a custom scheduler to use for scheduling decisions, not a direct node assignment; it still relies on scheduling logic. Option B is wrong because `affinity` (node affinity or pod affinity) provides soft or hard constraints for scheduling preferences but does not guarantee placement on a specific node like `nodeName` does. Option C is wrong because `nodeSelector` matches labels on nodes to schedule the pod to any node with those labels, not a single named node.

Practice this question →

58

MCQmedium

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?

A.The DaemonSet is configured to run only on control plane nodes

B.The DaemonSet has a nodeSelector that the node does not match

C.The node has insufficient resources for the DaemonSet pod

D.The node has a taint that is not tolerated

AnswerB

Correct. nodeSelector filter causes the DaemonSet to skip nodes that don't match labels.

Why this answer

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.

Exam trap

The trap here is that candidates often assume 'MISSING' implies a resource or taint issue, but the CKA exam tests the understanding that nodeSelector mismatches cause the DaemonSet controller to skip the node entirely, not just fail to schedule.

How to eliminate wrong answers

Option A is wrong because a DaemonSet configured to run only on control plane nodes would use a nodeSelector or node affinity targeting control plane labels (e.g., node-role.kubernetes.io/control-plane), and the question states the node is Ready with no taints, but does not indicate it is a control plane node; however, the 'MISSING' status would occur for worker nodes, not for a specific node that is Ready—this option does not explain why only one node is missing. Option C is wrong because insufficient resources (CPU/memory) would cause the pod to be in a 'Pending' state, not 'MISSING'; the DaemonSet controller would still attempt to schedule and show the pod as pending, not missing. Option D is wrong because the question explicitly states the node has no taints, so a taint that is not tolerated cannot be the cause.

Practice this question →

59

MCQhard

A Pod is stuck in 'Pending' state. You run 'kubectl describe pod my-pod' and see the event: '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 Insufficient cpu.' The pod has resource requests: cpu: 2, memory: 1Gi. The cluster has 3 nodes: one control-plane with taint node-role.kubernetes.io/master:NoSchedule, and two worker nodes each with 1 CPU. What is the most likely cause?

A.The pod requests more memory than any available node can provide.

B.The pod has a higher priority than other pods and is preempting them.

C.The pod requests more CPU than any available node can provide.

D.The control-plane node has insufficient resources.

AnswerC

The pod requests 2 CPUs, but worker nodes have only 1 CPU each. The control plane node is tainted and not schedulable for this pod.

Why this answer

Option A is correct. The two worker nodes have only 1 CPU each, so they cannot satisfy the request of 2 CPUs. The control plane node is tainted and the pod does not tolerate it.

Option B is incorrect because memory is not the issue. Option C is incorrect because the control plane node is not available due to taint, not because of resource shortage. Option D is incorrect because there is no mention of a PriorityClass.

Practice this question →

60

MCQhard

A StatefulSet named 'mysql' manages 3 replicas. You need to scale it down to 1 replica. What happens to the PersistentVolumeClaims (PVCs) of the removed pods?

A.The PVCs are retained to preserve data.

B.The PVCs are automatically backed up before deletion.

C.The PVCs are retained only if the pod with the highest ordinal is removed first.

D.The PVCs are automatically deleted along with the pods.

AnswerA

StatefulSet does not delete PVCs when scaling down, to protect data.

Why this answer

When a StatefulSet is scaled down, the PersistentVolumeClaims (PVCs) associated with the removed pods are retained by default. This is because StatefulSets are designed for stateful workloads where data persistence is critical; the PVCs remain to preserve data in case the pod is recreated or the StatefulSet is scaled up again. Kubernetes does not automatically delete PVCs when a StatefulSet pod is removed, as PVC lifecycle is independent of pod lifecycle.

Exam trap

The trap here is that candidates often confuse StatefulSet PVC behavior with that of Deployments or Jobs, where pods and their volumes are ephemeral, leading them to incorrectly assume PVCs are automatically deleted on scale-down.

How to eliminate wrong answers

Option B is wrong because Kubernetes does not have an automatic backup mechanism for PVCs when scaling down a StatefulSet; PVCs are simply retained, not backed up. Option C is wrong because PVCs are retained regardless of which pod (highest ordinal or not) is removed first; the ordinal-based removal order only affects pod naming, not PVC retention. Option D is wrong because PVCs are not automatically deleted when pods are removed; they persist until explicitly deleted by the user or through a configured StorageClass with reclaimPolicy: Delete, which is not the default behavior for StatefulSet PVCs.

Practice this question →

61

MCQmedium

A pod is in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 1 node(s) had taint that the pod didn't tolerate, 2 node(s) didn't match pod's node affinity/selector, 1 node(s) had insufficient memory'. What does this indicate?

A.The pod's image pull failed on all nodes

B.The pod will eventually be scheduled when resources free up

C.The pod is unschedulable due to multiple constraints

D.The pod has a resource limit that prevents it from running

AnswerC

Correct. The pod cannot be scheduled because no node meets all requirements.

Why this answer

The 'Pending' state combined with the scheduler's message '0/4 nodes are available' and the listed reasons (taints, node affinity/selector mismatches, insufficient memory) indicates that the pod cannot be placed on any node due to multiple constraints. The scheduler evaluates all nodes and finds none that satisfy the pod's requirements, making the pod unschedulable. This is not a transient resource issue but a combination of scheduling constraints that must be resolved manually.

Exam trap

CNCF often tests the distinction between resource requests and limits, and candidates mistakenly think limits affect scheduling, when in fact only requests are considered by the scheduler's PodFitsResources predicate.

How to eliminate wrong answers

Option A is wrong because image pull failures produce 'ImagePullBackOff' or 'ErrImagePull' events, not a 'Pending' state with node availability messages. Option B is wrong because the message includes taints and affinity/selector mismatches, which are not resolved by freeing resources; only the 'insufficient memory' issue might clear up, but the other constraints are permanent until the pod or nodes are reconfigured. Option D is wrong because resource limits (spec.containers[].resources.limits) affect runtime behavior (e.g., OOMKill) but do not prevent scheduling; scheduling is blocked by resource requests (spec.containers[].resources.requests) or node capacity, not limits.

Practice this question →

62

Multi-Selectmedium

Which TWO taint effects can be used to prevent a pod from being scheduled on a node unless it has a matching toleration?

Select 2 answers

A.PreferNoSchedule

B.NoExecute

C.NoSchedule

D.FailSchedule

E.NoAdmit

AnswersB, C

Prevents scheduling and evicts existing pods without toleration.

Why this answer

NoSchedule and NoExecute prevent scheduling without toleration. PreferNoSchedule is a soft preference and does not prevent scheduling. Taint effects are: NoSchedule, PreferNoSchedule, NoExecute.

Practice this question →

63

Multi-Selectmedium

Which TWO statements are correct regarding DaemonSets?

Select 2 answers

A.DaemonSets do not support rolling updates.

B.DaemonSets can be scaled up and down using kubectl scale.

C.DaemonSets use a replica count to determine how many pods to run.

D.DaemonSets are often used for cluster monitoring or logging agents.

E.DaemonSets ensure that all (or some) nodes run a copy of a pod.

AnswersD, E

Common use cases include node-level services like log collectors and monitoring agents.

Why this answer

Option D is correct because DaemonSets are designed to run a copy of a pod on every node (or a subset of nodes based on node selectors), making them ideal for cluster-wide infrastructure services such as monitoring agents (e.g., Prometheus Node Exporter), logging agents (e.g., Fluentd), and network plugins (e.g., Calico). This pattern ensures that each node has the necessary agent running without manual intervention.

Exam trap

The trap here is that candidates confuse DaemonSets with Deployments or StatefulSets, mistakenly thinking they support scaling via `kubectl scale` or use a replica count, when in fact DaemonSets are node-driven and scale automatically based on node membership.

Practice this question →

64

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Increase the memory limit in the pod's container resource specification

B.Delete the namespace and redeploy all workloads

C.Delete and recreate the pod to clear the crash loop

D.Increase the CPU request for the container

AnswerA

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

The 'OOMKilled' status indicates the container was terminated because it exceeded its memory limit. Since the pod ran successfully for days, the issue is likely a memory leak or increased workload demand. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory usage without being killed.

Exam trap

The trap here is that candidates may confuse OOMKilled with a generic crash and choose to delete/recreate the pod (Option C), not realizing that the pod will immediately re-enter CrashLoopBackOff because the underlying memory limit is unchanged.

How to eliminate wrong answers

Option B is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that doesn't address the root cause (memory limit too low) and would cause unnecessary downtime. Option C is wrong because deleting and recreating the pod will only temporarily restart it; the pod will crash again with OOMKilled once memory usage exceeds the limit. Option D is wrong because increasing the CPU request does not affect memory allocation; OOMKilled is a memory-related termination, not CPU-related.

Practice this question →

65

MCQmedium

A Pod has an init container that writes a configuration file, and the main container reads that file. The init container runs successfully, but the main container fails with 'file not found'. What is the most likely cause?

A.The init container wrote the file to a different volume than the one mounted in the main container.

B.The main container restarted and the init container did not rerun.

C.The main container's command is incorrect.

D.The init container did not complete before the main container started.

AnswerA

Without a shared volume, the main container cannot see the init container's files.

Why this answer

Option B is correct. Init containers and main containers must share a volume to exchange data; otherwise, the init container's filesystem is not accessible to the main container. Option A is incorrect because init containers always run to completion before main containers start.

Option C is incorrect because the main container's command is not the issue. Option D is incorrect because restarts do not affect file existence if the init container succeeded.

Practice this question →

66

MCQhard

A StatefulSet named 'db' manages 3 pods. The pods are named db-0, db-1, db-2. What is the expected behavior when the StatefulSet's pod management policy is set to OrderedReady and you scale down from 3 to 1 replica?

A.All pods are deleted simultaneously.

B.Pod db-2 is deleted, then db-1, and db-0 remains.

C.Only pod db-2 is deleted; db-1 and db-0 remain.

D.Pod db-0 is deleted first, then db-1, and db-2 remains.

AnswerB

Correct: deletion in reverse order, one at a time.

Why this answer

With OrderedReady pod management, StatefulSet deletion proceeds in reverse ordinal order, waiting for each pod to terminate before moving to the next. So it deletes db-2, then db-1, and stops at 1 replica (db-0 remains).

Practice this question →

67

MCQhard

You create a PriorityClass named 'high-priority' with value 1000000 (one million). A pod uses this PriorityClass. The cluster has limited resources. What scheduling behavior is most likely?

A.The pod will never be preempted by other pods

B.The pod will be scheduled only after all lower-priority pods have been scheduled

C.The pod may preempt lower-priority pods to be scheduled

D.The pod will be assigned a higher CPU priority in the kernel

AnswerC

Correct. Pod priority enables preemption; higher priority pods can evict lower priority pods.

Why this answer

PriorityClass with value 1000000 is extremely high (the default max is 1 billion). When a pod with this PriorityClass is submitted and the cluster has limited resources, the Kubernetes scheduler may preempt (evict) lower-priority pods to free resources and schedule this high-priority pod. This is the core behavior of PriorityClass and preemption in Kubernetes.

Exam trap

CNCF often tests the misconception that PriorityClass affects kernel-level CPU priority or that a high-priority pod is scheduled before all lower-priority pods, when in reality it only enables preemption and does not guarantee scheduling order.

How to eliminate wrong answers

Option A is wrong because even a pod with a very high priority can be preempted by a pod with an even higher priority (up to 1 billion), so it is not immune to preemption. Option B is wrong because scheduling order is not strictly based on priority; lower-priority pods can be scheduled first if resources are available, and high-priority pods may preempt them later. Option D is wrong because Kubernetes PriorityClass does not affect the kernel's CPU priority (nice value); it only controls scheduling and preemption within the Kubernetes scheduler.

Practice this question →

68

MCQmedium

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?

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

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

C.kubectl rollout undo deployment/web-app --to-revision=1

D.kubectl rollout undo deployment/web-app

AnswerC

Correct command to roll back to revision 1.

Why this answer

Option C is correct because `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.

Exam trap

The trap here is that candidates often confuse `kubectl rollout undo` (which defaults to the previous revision) with the need to specify `--to-revision` to target an arbitrary revision, or they mistakenly use `kubectl set image` to 'revert' the image, which instead creates a new revision rather than rolling back.

How to eliminate wrong answers

Option A is wrong because `kubectl set image deployment/web-app web-app=image:v1` changes the container image to `image:v1` but does not perform a rollback; it creates a new revision (revision 3) rather than reverting to revision 1. Option B is wrong because `kubectl rollout history deployment/web-app --revision=1` only displays the details of revision 1 (e.g., annotations, template) without actually rolling back the Deployment. Option D is wrong because `kubectl rollout undo deployment/web-app` rolls back to the previous revision (revision 1 only if revision 2 is current and revision 1 is the immediate predecessor), but it does not guarantee targeting revision 1 if there are multiple revisions; the `--to-revision` flag is required to specify revision 1 explicitly.

Practice this question →

69

MCQeasy

What is the purpose of a PriorityClass in Kubernetes?

A.To define which nodes a pod can be scheduled on based on priority

B.To set the order in which pods are started

C.To ensure that high-priority pods can preempt lower-priority pods

D.To give a pod a higher share of CPU cycles

AnswerC

That is the core function of PriorityClass with preemption.

Why this answer

PriorityClass in Kubernetes is used to assign a priority value to pods, which the scheduler uses to determine scheduling order and, critically, to enable preemption. When the cluster is under resource pressure, the scheduler can preempt (evict) lower-priority pods to make room for higher-priority pods that cannot be scheduled. This ensures that critical workloads can run even when resources are scarce, which is the core purpose of PriorityClass.

Exam trap

CNCF often tests the misconception that PriorityClass controls CPU or memory resource allocation (like QoS classes), whereas it strictly controls scheduling priority and preemption behavior, not runtime resource guarantees.

How to eliminate wrong answers

Option A is wrong because node selection based on priority is handled by node affinity, node selectors, or taints/tolerations, not by PriorityClass. Option B is wrong because the order in which pods are started is influenced by PriorityClass only in the context of scheduling and preemption, but there is no guaranteed startup order; Kubernetes does not provide a sequential startup mechanism. Option D is wrong because CPU cycles are allocated based on resource requests and limits, not priority; priority does not affect CPU shares or scheduling fairness within the node's cgroups.

Practice this question →

70

MCQeasy

Which of the following is a valid way to mount a Secret as a volume in a Pod?

A.volumes: - name: secret-volume secret: secretName: my-secret

B.volumes: - name: secret-volume secretName: my-secret

C.volumes: - name: secret-volume configMap: name: my-secret

D.volumes: - name: secret-volume hostPath: path: /etc/secret

AnswerA

Correct format for mounting a Secret as a volume.

Why this answer

Option A is correct because it uses the `secret` volume type with the `secretName` field to reference a Kubernetes Secret object. This is the standard syntax for mounting a Secret as a volume in a Pod, allowing the Secret's data to be exposed as files in the container's filesystem.

Exam trap

The trap here is that candidates confuse the syntax for mounting a Secret with that of a ConfigMap, or incorrectly assume that `secretName` can be used as a top-level field without the `secret` key, leading them to pick option B.

How to eliminate wrong answers

Option B is wrong because it omits the `secret` key under the volume source; the `secretName` field must be nested under a `secret` key, not placed directly under the volume name. Option C is wrong because it uses the `configMap` volume type with a `name` field, which is for ConfigMaps, not Secrets; Secrets require the `secret` volume type. Option D is wrong because it uses `hostPath` to mount a directory from the node's filesystem, which does not mount a Kubernetes Secret object and bypasses Secret management and encryption.

Practice this question →

71

MCQeasy

Which command retrieves the rollout history of a Deployment named 'web'?

A.kubectl describe deployment web

B.kubectl get events --field-selector involvedObject.name=web

C.kubectl rollout history deployment web

D.kubectl rollout status deployment web

AnswerC

Correct command to view rollout history.

Why this answer

kubectl rollout history deployment web shows the revision history of the deployment.

Practice this question →

72

MCQhard

You apply a LimitRange that sets default CPU request to 0.5 and default CPU limit to 1. You create a pod without specifying any CPU resources. What are the effective CPU request and limit for the pod?

A.request: 0.5, limit: 1

B.request: 0.5, limit: 0 (no limit)

C.request: 0, limit: 0 (no defaults applied)

D.request: 1, limit: 0.5

AnswerA

The LimitRange default values are applied.

Why this answer

LimitRange applies default resource requests and limits to pods that do not specify them. The pod gets request=0.5, limit=1.

Practice this question →

73

MCQmedium

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?

A.The init container image was not found

B.The init container's command failed

C.The pod's main container failed to start

D.The init container exceeded a resource limit

AnswerB

Init:Error indicates the init container exited with an error. Probably wget failed or is not available.

Why this answer

The init container runs a `wget` command to download a file. The pod transitions from `Init:0/1` to `PodInitializing` (indicating the init container started) and then to `Init:Error`, which means the init container 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.

Exam trap

The trap here is that candidates see `Init:Error` and immediately assume a resource limit or image pull issue, but the progression from `Init:0/1` to `PodInitializing` proves the container started and ran, so the error must be from the command itself failing.

How to eliminate wrong answers

Option A is wrong because if the init container image were not found, the pod would show `ErrImagePull` or `ImagePullBackOff`, not `Init:Error` after having started. Option C is wrong because the pod never reached the main container stage; the error is specifically in the init container phase, as indicated by `Init:Error`. Option D is wrong because exceeding a resource limit (e.g., CPU or memory) would typically result in an `OOMKilled` or `CrashLoopBackOff` status, not a generic `Init:Error` from a command failure.

Practice this question →

74

MCQeasy

You need to create a ConfigMap named 'app-config' from a file named 'config.properties' located in the current directory. Which command should you use?

A.kubectl create configmap app-config --from-file config.properties

B.kubectl create configmap app-config --from-literal=config.properties

C.kubectl apply configmap app-config --from-file=config.properties

D.kubectl create configmap app-config --from-file=config.properties

AnswerD

Correct syntax.

Why this answer

Option C is correct. The command 'kubectl create configmap app-config --from-file=config.properties' creates a ConfigMap from the file. Option A is incorrect because the syntax uses --from-literal for key-value pairs.

Option B uses 'create configmap' but with wrong flag syntax. Option D is incorrect because 'apply' requires a manifest file.

Practice this question →

75

MCQeasy

You have a Deployment named 'web-app' in the 'default' namespace. You run the following command: kubectl rollout history deployment web-app. The output shows: revision 1, revision 2, revision 3. You want to roll back to revision 1. Which command achieves this?

A.kubectl rollout undo deployment web-app --revision=1

B.kubectl rollout undo deployment web-app --to-revision=1

C.kubectl rollback deployment web-app --to-revision=1

D.kubectl rollout undo deployment web-app

AnswerB

Correct flag to specify target revision.

Why this answer

Option A is correct. 'kubectl rollout undo deployment web-app --to-revision=1' rolls back to revision 1. Option B rolls back to the previous revision (2). Option C is incorrect because --revision flag does not exist.

Option D uses 'rollback' which is not a valid kubectl command.

Practice this question →

Page 1 of 2 · 126 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Cka Workloads Scheduling questions.

Start 20-question session