CCNA Cka Workloads Scheduling Questions — Page 1 of 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

This is a key characteristic of StatefulSets. They assign ordinal indices (0,1,2,...) and create/scale/terminate pods in order, ensuring that each pod is fully ready before the next is started. For example, when scaling up, pod-0 starts and becomes ready, then pod-1, etc. During termination, it's reverse order. This ordered behavior is critical for applications requiring leader election or primary/secondary roles, as the first pod often becomes the leader.

Why this answer

Option A is correct because a StatefulSet assigns each pod a stable ordinal index (0, 1, 2, ...) and creates, scales, and terminates pods in that strict ordered sequence, unlike a Deployment. Option B is correct because StatefulSets use volumeClaimTemplates to give each pod its own dedicated PersistentVolumeClaim, which is retained and reattached to the same ordinal pod even after rescheduling. Option D is correct because each StatefulSet pod receives a stable, unique network identity in the form of a predictable hostname (pod-name.service-name) backed by a headless Service, so DNS names remain consistent across restarts.

Option C is incorrect because StatefulSet pods are never created in random order; ordering is deterministic by ordinal. Option E is incorrect because StatefulSet pods are deliberately not interchangeable — each has its own identity, hostname, and storage, which is the opposite of the interchangeable replicas in a Deployment.

Exam trap

The trap here is that candidates often confuse StatefulSet behavior with Deployment behavior, assuming pods are interchangeable or created in random order, but StatefulSets enforce ordered creation/termination and unique identities for stateful workloads.

Practice this question →

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

When a CronJob's `concurrencyPolicy` is set to `Forbid`, the CronJob controller ensures that only one instance of the job runs at any given time. If the scheduled time for a new job arrives, but a previous job created by the same CronJob is still active (running or pending), the controller will simply skip the new scheduled run. This prevents resource contention or duplicate processing by ensuring strict sequential execution, directly explaining why a job might not run as scheduled.

Why this answer

When a CronJob's concurrency policy is set to 'Forbid', it prevents a new job from starting if the previous job is still running. If the previous job took longer than the scheduled interval (e.g., more than one hour), the next scheduled run will be skipped, causing the job not to run at the expected time. This is a common scenario where a long-running job overlaps with the next scheduled time, and the 'Forbid' policy enforces that only one job instance runs at a time.

Exam trap

The trap here is that candidates often assume a CronJob always runs at its scheduled time, overlooking how the 'Forbid' concurrency policy can skip runs when a previous job is still active, especially when the job duration exceeds the schedule interval.

How to eliminate wrong answers

Option B is wrong because 'Allow' is the default concurrency policy that permits multiple jobs to run concurrently, so it would not prevent the job from running at the scheduled time. Option C is wrong because CronJobs do not have a 'not rerun after success' configuration; they run based on the schedule regardless of previous job success or failure, unless the 'startingDeadlineSeconds' is exceeded. Option D is wrong because 'Replace' terminates the currently running job and starts a new one at the scheduled time, so the job would still run (the old one is replaced), not skipped.

Practice this question →

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

Kubernetes scheduler attempts to place a pod on any node, and each node may fail for a different reason. The event messages show one node lacks enough allocatable CPU, while two other nodes have taints the pod does not tolerate. Because no node passes all filters, the pod remains Pending, and the correct overall diagnosis is the union of these two distinct scheduling blockers.

Why this answer

The event message explicitly states that 0/3 nodes are available due to two distinct issues: one node has insufficient CPU, and two nodes have a taint (node-role.kubernetes.io/master) that the pod does not tolerate. This means no single node satisfies all scheduling requirements, so the pod remains Pending. Option B correctly identifies that the scheduling failure is caused by a combination of resource insufficiency and untolerated taints across different nodes, not a single global problem.

Exam trap

The trap here is that candidates often assume all nodes share the same problem (e.g., all tainted or all out of CPU) and fail to read the event message carefully, which lists separate counts for each issue across different nodes.

How to eliminate wrong answers

Option A is wrong because the event message mentions insufficient CPU, not memory; the pod's resource request is for CPU, and no node is reported as lacking memory. Option C is wrong because only two of the three nodes have the master taint; one node has insufficient CPU instead, so not all nodes are tainted. Option D is wrong because only one node has insufficient CPU; the other two nodes have sufficient CPU but are blocked by the untolerated taint.

Practice this question →

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

This is the correct command because the `--from-file` flag instructs kubectl to read the entire contents of the specified file. It automatically creates a single key in the ConfigMap named `app.properties` with the file's complete text content as its value.

Why this answer

`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 →

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 Kubernetes Job is the correct resource for running a task to completion. It manages the creation of one or more pods and ensures that a specified number of them successfully terminate. If a pod fails, the Job controller can restart it according to its `restartPolicy`, guaranteeing that the batch processing task finishes its work on the queue and then gracefully exits, without being restarted unnecessarily.

Why this answer

A Kubernetes Job is designed to run a specified number of pods to completion, making it the correct choice for a batch process that runs once and then terminates. Unlike controllers that maintain a desired state (like Deployments or DaemonSets), a Job tracks pod completion and will not restart the pod once it succeeds, perfectly matching the requirement of a single execution.

Exam trap

The trap here is that candidates often confuse a Job with a CronJob, thinking that any batch processing requires a schedule, but the key distinction is that a CronJob adds a time-based trigger, while a plain Job is for one-off execution.

How to eliminate wrong answers

Option A is wrong because a CronJob is used for scheduling jobs to run at specific times or intervals (e.g., every hour), not for a one-time execution. Option B is wrong because a DaemonSet ensures that a copy of a pod runs on every node in the cluster, which is intended for long-running services (like log collectors or monitoring agents), not for a batch job that terminates. Option D is wrong because a Deployment manages a set of identical pods to maintain a desired number of replicas, ensuring they are always running; it is designed for stateless, long-lived applications, not for a job that runs to completion.

Practice this question →

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 is the correct command to roll back a deployment to its immediately preceding revision. By default, it targets the last successful revision in the deployment's history, updating the ReplicaSet controller to scale down the current active ReplicaSet and scale up the previous one.

Why this answer

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

Exam trap

The trap here is that candidates confuse `rollout restart` (which restarts Pods without changing the revision) with `rollout undo` (which reverts to a previous revision), or they invent non-existent commands like `rollout revert` due to familiarity with other orchestration tools.

How to eliminate wrong answers

Option A is wrong because `kubectl rollout restart` triggers a new rollout by restarting Pods with the same configuration, not reverting to a previous revision. Option C is wrong because `kubectl rollout history --revision=previous` is not a valid flag; the correct syntax is `--revision=<number>` to view a specific revision's details, and it does not perform a rollback. Option D is wrong because `kubectl rollout revert` is not a valid kubectl command; the correct verb for rollback is `undo`, not `revert`.

Practice this question →

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

This is the correct configuration because it explicitly targets minute 0 and hour 0 (midnight) while using wildcards for the day of the month, month, and day of the week. This ensures the job runs exactly once every single day of the year. It perfectly matches the standard crontab format used by Kubernetes CronJobs.

Why this answer

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 →

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 correct phase for a pod immediately after it is created, because the pod object has been persisted in etcd but the scheduler has not yet assigned it to a node. Once scheduled, the phase still stays Pending while the container runtime pulls images, creates containers, and starts processes. Only after those actions complete does the phase transition to Running.

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 →

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

CronJobs default to a concurrency policy of Allow, so a new job is created at each scheduled time regardless of whether the previous run has finished. With a 45-minute runtime and hourly schedule, the next job therefore starts and runs concurrently with the still-executing one.

Why this answer

By default, CronJobs in Kubernetes have a concurrencyPolicy of 'Allow'. This means that if a new job is scheduled while a previous job is still running, the new job starts immediately and runs concurrently with the previous one. Option C correctly describes this default behavior.

If you want to prevent concurrent executions, you must explicitly set concurrencyPolicy to 'Forbid'.

Exam trap

The trap in this question is that many candidates mistakenly believe the default concurrencyPolicy for a CronJob is 'Forbid' to prevent resource exhaustion. However, the default is actually 'Allow', meaning overlapping jobs will run concurrently unless explicitly configured otherwise.

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 →

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

The `kubectl.kubernetes.io/restartedAt` annotation is a widely adopted method to force a deployment rollout restart. When `kubectl rollout restart deployment/<name>` is executed, it patches the deployment's Pod template metadata with this annotation, setting its value to the current timestamp. This modification to the Pod template triggers a new rollout, causing all existing pods to be gracefully replaced with new ones, effectively picking up any updated ConfigMap or Secret data.

Why this answer

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 →

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

The HPA computes pod CPU utilization as the measured CPU usage for each pod divided by that pod's CPU request, then averages these per-pod utilization ratios across the entire set of selected pods. If every pod has the same CPU request, this equals the total usage across pods divided by a single request value, but the canonical definition is per-pod usage/request averaged.

Why this answer

Option A is correct because the HPA computes average CPU utilization by taking the mean CPU usage across all targeted pods and dividing it by each pod's CPU request, expressing the result as a percentage of the request. Option B is correct because the utilization formula depends on the CPU request as its denominator; if a pod has no CPU request set, the HPA cannot compute a utilization percentage for it and will not act on that metric. Option C is wrong because the HPA target for CPU utilization is expressed as a percentage of the request (e.g., 50%), not an absolute CPU value.

Option D is wrong because exceeding the target utilization triggers scale up, not scale down. Option E is wrong because the HPA uses CPU requests, not CPU limits, as the baseline for utilization calculations.

Exam trap

The trap here is that candidates often confuse CPU requests with CPU limits, assuming limits are used in HPA calculations, or they mistakenly think the HPA scales down when utilization is high.

Practice this question →

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

This is the correct configuration because it precisely balances update velocity and safety for a five-replica Deployment. By allowing up to three unavailable pods (maxUnavailable: 3), the Deployment can terminate old ReplicaSet pods aggressively, while capping the total pod count at seven with a surge of two, which keeps the cluster from being overloaded during the rollout. The update thus guarantees at least two pods remain available throughout, which is the intended minimum availability, and it completes in fewer cycles than more conservative settings would allow.

Why this answer

The rolling update strategy specifies `maxUnavailable: 3` and `maxSurge: 2`. With 5 desired replicas, this allows up to 3 pods to be unavailable during the update (so at least 2 pods remain running) and up to 2 extra pods above the desired count (so a maximum of 7 pods total). This matches the requirement exactly.

Exam trap

The trap here is that candidates often confuse the roles of `maxUnavailable` and `maxSurge`, or misread the question's constraints (e.g., thinking 'maximum of 3 pods unavailable' maps to `maxUnavailable: 2` because they subtract from desired count incorrectly).

How to eliminate wrong answers

Option A is wrong because it sets `maxUnavailable: 2` and `maxSurge: 3`, which would allow only 2 pods unavailable (too restrictive) and up to 3 extra pods (exceeding the allowed 2 extra). Option B is wrong because it sets `maxUnavailable: 2` and `maxSurge: 2`, which allows only 2 pods unavailable (not the required 3) and 2 extra pods (correct for surge but wrong for unavailability). Option C is wrong because it sets `maxUnavailable: 3` and `maxSurge: 3`, which allows 3 pods unavailable (correct) but up to 3 extra pods (exceeding the allowed 2 extra).

Practice this question →

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

Mounting a ConfigMap as a volume is a valid and commonly used injection method. When you define a volume of type configMap and mount it into a container, Kubernetes creates a file for each key in the ConfigMap, with the key as the filename and the value as the file's content. This approach is ideal for configuration files (e.g., application .conf or YAML), allows large amounts of data, and supports dynamic updates—changes to the ConfigMap are eventually reflected in the mounted files after the kubelet's sync period, unless the mount uses subPath.

Why this answer

A ConfigMap can be mounted as a volume in a Pod, allowing files to be created or updated in the container's filesystem with configuration data. This is a standard Kubernetes feature where the ConfigMap's data keys become filenames and values become file contents, and updates to the ConfigMap can be reflected in the mounted volume without restarting the Pod (depending on the mount type).

Exam trap

The trap here is that candidates often confuse the declarative nature of Kubernetes configuration injection with imperative commands, and may incorrectly assume a 'kubectl inject' command exists, or they mix up the roles of Secrets and ConfigMaps as data sources for each other.

Practice this question →

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 and Kubernetes-native method for injecting a specific key's value from a ConfigMap into a container's environment. By defining the `env` variable within the Pod's YAML specification and utilizing `valueFrom.configMapKeyRef`, you explicitly reference the ConfigMap's name and the desired key. This declarative approach ensures precise control over environment variable injection and is the standard practice for managing application configurations.

Why this answer

To inject a specific key from a ConfigMap as a pod environment variable with a custom name, you must use a pod YAML with `env.valueFrom.configMapKeyRef`. This allows you to reference the ConfigMap key `database.url` and map it to the environment variable `DB_URL`. The `kubectl run` command does not support directly mapping a ConfigMap key to a custom environment variable name in a single command.

Exam trap

The trap here is that candidates often assume `kubectl run` with a simple flag can directly map a ConfigMap key to a custom environment variable name, but Kubernetes does not provide a single-command shortcut for this; you must use a YAML manifest with `configMapKeyRef`.

How to eliminate wrong answers

Option A is wrong because `--envFrom=configmap/app-config` would inject all keys from the ConfigMap as environment variables, but it would use the ConfigMap key names (e.g., `database.url`) as the environment variable names, not `DB_URL`. Option C is wrong because `--env="DB_URL=configmap:app-config:database.url"` is not a valid syntax for referencing a ConfigMap key; the correct syntax for referencing a ConfigMap value in `kubectl run` does not exist in this form. Option D is wrong because `--from-configmap=app-config` is not a valid flag for `kubectl run`; it is used with `kubectl create configmap` to create a ConfigMap from a file or literal.

Practice this question →

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

This is the correct command because the --from-file flag instructs kubectl to read the contents of config.properties and store them in the ConfigMap. The filename itself becomes the key, and the entire file content becomes the corresponding value.

Why this answer

`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 →

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

Using nodeAffinity with the requiredDuringSchedulingIgnoredDuringExecution field enforces a hard scheduling constraint. By specifying the NotIn operator with the key disk and value ssd, the Kubernetes scheduler is strictly prohibited from placing the DaemonSet pods on any node labeled with disk=ssd, effectively excluding them while allowing scheduling on all other nodes.

Why this answer

`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 →

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

If an init container enters a CrashLoopBackOff state, it is typically because the entrypoint command or script executed inside it returned a non-zero exit code. Kubernetes monitors the exit status of the init container's process, and any failure prevents the pod from transitioning to the running state, causing the kubelet to restart the init container repeatedly. Debugging this requires inspecting the init container's logs or exit codes.

Why this answer

The 'Init:CrashLoopBackOff' status indicates that the init container is repeatedly failing and restarting. Since init containers run to completion before the main container starts, the most likely cause is that the script in the init container is failing due to an error, such as a syntax mistake, missing dependency, or incorrect command.

Exam trap

The CKA exam often tests the distinction between init containers and regular containers, specifically that init containers run to completion before main containers start, so candidates mistakenly think the main container's resources or volume permissions could cause an init container failure.

How to eliminate wrong answers

Option A is wrong because init containers always run to completion before the main container starts; they do not wait for the main container. Option C is wrong because resource limits apply to containers after they start, and the main container hasn't started yet when the init container is failing. Option D is wrong because incorrect volume permissions would typically cause a runtime error in the main container, not prevent the init container from completing its script.

Practice this question →

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

Mounting a ConfigMap as a volume is a native injection method: you declare the ConfigMap in the pod's volumes list and reference it in a volumeMount, causing Kubernetes to expose each key as a file in the container's filesystem. This approach is ideal for large or structured configurations, and when the ConfigMap is updated, kubelet periodically syncs the mounted files so running applications can observe changes without a restart (depending on the app).

Why this answer

Option C is correct because a ConfigMap can be mounted as a volume into a pod, causing each key in the ConfigMap to appear as a file in the mounted directory, which is a standard Kubernetes mechanism for injecting configuration data. Option D is also correct because a ConfigMap's keys can be exposed as environment variables inside containers via envFrom or valueFrom.configMapKeyRef, directly injecting configuration values into the container's environment. Option A is not a valid injection method because kubectl edit modifies the pod's specification itself (and most pod fields are immutable after creation), not the configuration data consumed by the application.

Option B is not a native configuration-injection mechanism; a sidecar fetching config from a remote API is an application-level pattern, not a Kubernetes-provided way to inject config into a pod. Option E is incorrect because a PersistentVolume provides storage, not a mechanism for injecting configuration data into a pod.

Exam trap

Kubernetes often tests the distinction between valid configuration injection methods (ConfigMaps as volumes or env vars) and invalid ones like direct Pod spec edits or using PersistentVolumes, which are not designed for configuration data.

Practice this question →

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

This is the correct explanation. A Deployment performing a RollingUpdate relies on new pods becoming Ready before it can safely scale down old pods, especially with maxUnavailable preventing too many old pods from being removed. If new pods are unable to schedule onto nodes due to insufficient CPU, memory, or other resource requests exceeding available capacity, they will remain in a Pending state. Consequently, they never reach Ready, preventing the rollout from progressing and leaving the deployment stuck.

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% on a 5-replica deployment:

maxSurge (25% of 5 = 1.25) rounds up to 2. This means up to 7 pods can exist at once.

maxUnavailable (25% of 5 = 1.25) rounds down to 1. This means at least 4 pods must remain available.

If the 2 new pods are created but cannot start (e.g., remaining in Pending due to resource constraints like CPU/Memory), they will never become Ready. The rollout will stall because the controller cannot proceed with further replacements until the new pods are healthy.

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 →

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

With 4000m CPU allocatable and 500m requested per pod, the scheduler can pack 4000/500 = 8 pods. This ignores memory limits and other daemonset overhead, so in practice node exhaustion or memory may reduce this number. However, based strictly on CPU request, 8 is the ceiling.

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 →

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

A ConfigMap can be injected into a Pod as environment variables using the `configMapKeyRef` field in the container's `env` definition. This pulls a specific key's value into an environment variable, and `envFrom` can be used to load all keys as environment variables automatically. This is a valid, declarative method to expose configuration data to processes inside the container.

Why this answer

Option A is correct because a ConfigMap can be consumed via envFrom or valueFrom.configMapKeyRef in a container's env, injecting keys as environment variables. Option E is correct because a ConfigMap can be mounted as a volume, where each key becomes a file in the mounted directory, allowing applications to read configuration from the filesystem. Option B is incorrect because a Kubernetes Service provides network access to pods, not a mechanism to inject ConfigMap data.

Option C is incorrect because container command arguments are set in the pod spec and are not a native ConfigMap exposure method, though values could be referenced indirectly. Option D is incorrect because annotations are metadata attached to objects and are not a supported way to expose ConfigMap data to containers.

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 →

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

The nodeSelector field is the simplest and most direct mechanism to constrain a Pod to run on nodes with specific labels. By specifying the key-value pair disktype: ssd under this field in the Pod specification, the Kubernetes scheduler filters out any nodes lacking this exact label, ensuring the Pod is only placed on a matching SSD-backed node.

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 →

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

The maxUnavailable field directly specifies the maximum number of pods that can be unavailable during the update process relative to the desired replica count. Setting this to 3 ensures that during a rolling update of a 5-replica deployment, at least 2 pods (5 minus 3) remain online and capable of serving traffic at all times.

Why this answer

The `maxUnavailable` field in a Deployment's rolling update strategy specifies the maximum number of Pods that can be unavailable during the update process. Setting `maxUnavailable: 3` ensures that at most 3 out of 5 replicas can be down simultaneously, which directly satisfies the requirement. This field is part of the `spec.strategy.rollingUpdate` configuration in the Deployment manifest.

Exam trap

The trap here is that candidates often confuse `maxUnavailable` with `maxSurge`, thinking that limiting the number of new Pods (surge) indirectly controls unavailability, but `maxUnavailable` directly caps the number of Pods that can be down at any time.

How to eliminate wrong answers

Option A is wrong because `replicas: 3` sets the desired number of Pods to 3, not the maximum unavailable count, and would reduce the total replicas instead of controlling the update behavior. Option B is wrong because `minReadySeconds` defines the minimum time a Pod must be ready before it is considered available, which affects readiness but does not limit how many Pods can be unavailable during a rolling update. Option D is wrong because `maxSurge` controls the maximum number of Pods that can be created above the desired replicas during an update, not the number that can be unavailable.

Practice this question →

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 the anti-affinity rule from `requiredDuringSchedulingIgnoredDuringExecution` to `preferredDuringSchedulingIgnoredDuringExecution` transforms a hard constraint into a soft preference. With a `required` rule, the scheduler *must* satisfy the anti-affinity; otherwise, the pod remains pending. By making it `preferred`, the scheduler will *attempt* to satisfy the rule but will still schedule the pod on an available node even if the preference cannot be met, thus resolving the pending state.

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 →

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

AnswerC

This is the correct maximum number of pods that can exist during the update. With maxSurge set to 50% of the 3 desired replicas, the calculation yields 1.5, which Kubernetes rounds up to 2. Consequently, during the rolling update, the deployment controller can spin up 2 additional pods, bringing the temporary peak total to 5 pods (3 desired + 2 surge).

Why this answer

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

Exam trap

The trap is that candidates incorrectly round down 1.5 to 1, but Kubernetes rounds up percentages, so maxSurge=50% of 3 becomes 2 extra pods.

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 →

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: Forbid` ensures that if a scheduled job is still running when the next interval arrives, the CronJob controller skips the new execution. This guarantees that only one instance of the batch job runs at any given time, preventing overlapping executions.

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 →

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

StatefulSets with the default `RollingUpdate` strategy update pods in reverse ordinal order, meaning `db-2`, then `db-1`, then `db-0`. The `OrderedReady` pod management policy, which is also the default, mandates that each new pod must become `Ready` before the controller proceeds to update the next pod. If `db-2` fails its readiness probe, the entire rollout will halt indefinitely at that point, causing `kubectl rollout status` to hang.

Why this answer

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 →

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 is the correct mechanism to securely mount a Kubernetes Secret resource as a directory containing sensitive files. Each key in the secret's data map is projected as an individual file within the specified mount path. This volume is backed by tmpfs (RAM-backed storage) to ensure sensitive data is never written to physical disk on the node.

Why this answer

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 →

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

With the default OrderedReady policy, the StatefulSet controller creates pods one at a time in ordinal order: after web-2 is Running and Ready, it creates web-3, waits for it to be Ready, then creates web-4. Each new pod gets its own dedicated PVC from the volumeClaimTemplate, resulting in volumes such as data-web-3 and data-web-4. This ensures each pod has a unique, persistent identity and storage that survives rescheduling.

Why this answer

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 →

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

Deleting the individual pod mysql-0 prompts the StatefulSet controller to automatically provision a replacement pod. The newly created pod will retain the exact same name, stable network identity, and will automatically reattach to the existing PersistentVolumeClaim associated with that ordinal index, ensuring zero data loss.

Why this answer

StatefulSet pods are managed by a controller that automatically recreates a pod with the same identity (name, hostname, and stable network identity) when it is deleted. Deleting the pod 'mysql-0' triggers the StatefulSet controller to create a new pod with the same ordinal index and persistent storage binding, preserving its stable network identity.

Exam trap

The trap here is that candidates may think scaling down and up is required to recreate a pod, but the StatefulSet controller automatically recreates a deleted pod with the same identity, making direct pod deletion the correct and minimal approach.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the entire StatefulSet would cause all pods to be recreated, potentially losing the stable network identity and persistent storage claims for all replicas, and is unnecessary for fixing a single pod. Option B is wrong because 'kubectl replace --force' is used to replace a resource definition, not to recreate a pod; it would not trigger the StatefulSet controller to recreate the specific pod with its identity. Option C is wrong because scaling down to 0 and back up to 3 would recreate all pods, not just 'mysql-0', and would assign new ordinals (starting from 0 again), but the new pod 'mysql-0' would still get the same identity; however, this approach is overly disruptive and not the minimal correct action for a single failed pod.

Practice this question →

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

spec.template.spec.nodeSelector is the correct and most straightforward method to constrain a DaemonSet to run only on nodes possessing specific labels. By defining a map of key-value pairs here, the DaemonSet controller will only create pods on nodes that match all of these labels. This effectively filters the cluster's nodes, ensuring the logging agent runs exclusively on the desired subset of infrastructure.

Why this answer

`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 →

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

A PriorityClass defines a 32-bit integer value that the kube-scheduler uses to order the active scheduling queue. Pods with higher priority values are processed before lower-priority ones and can trigger the preemption of running, lower-priority pods if cluster resources are fully utilized.

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 →

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

The HPA uses the formula desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)]. Plugging in the values yields ceil[2 * (90 / 80)] = ceil[2.25], which rounds up to 3 replicas. This scaling action directly addresses the resource deficit by distributing the load across an additional pod to bring average utilization back down toward the 80% target.

Why this answer

The HPA calculates the desired number of replicas as ceil(currentReplicas * (currentUtilization / targetUtilization)). Here, currentUtilization is 90% and targetUtilization is 80%, so desiredReplicas = ceil(2 * (90/80)) = ceil(2.25) = 3. Since 3 is within the min/max range (2–10) and differs from currentReplicas (2), the HPA will scale up to 3 replicas immediately (no stabilization window for scale-up by default).

Exam trap

The trap here is that candidates forget the HPA uses ceiling (ceil) in its calculation and incorrectly round up to 4, or assume a stabilization delay applies to scale-up, leading them to choose 'do nothing'.

How to eliminate wrong answers

Option A is wrong because the HPA does not wait for stabilization on scale-up; stabilization windows apply only to scale-down by default (controlled by --horizontal-pod-autoscaler-downscale-stabilization). Option C is wrong because the calculation yields 3 replicas, not 4; the formula uses ceil, not rounding up to the next integer after a threshold. Option D is wrong because scaling down when utilization is above the target would worsen the overload; the HPA scales up to reduce per-pod load, and minReplicas=2 prevents scaling below 2.

Practice this question →

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

Using envFrom with configMapRef is a valid and straightforward way to expose all key-value pairs from a ConfigMap as environment variables. The configMapRef field inside envFrom specifies a source ConfigMap by name, and Kubernetes populates every entry from that ConfigMap into the container's environment. This is ideal when you want to inject multiple variables without listing each key individually, though you may still override specific keys using the env field.

Why this answer

`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 →

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

The nodeSelector field provides a concise key-value map that the scheduler uses as a hard constraint for node selection. When you set nodeSelector to { gpu: "true" }, the scheduler will only place the pod on nodes that have the label gpu with the exact value "true". This is entirely label-driven, so it works across any number of GPU-enabled nodes, unlike nodeName, and it is the simplest declarative mechanism for an equality-based node label requirement, requiring no nested API structures.

Why this answer

`spec.nodeSelector` is the simplest and most direct way to constrain a pod to nodes with a specific label. By setting `gpu: "true"` in the nodeSelector, the scheduler will only place the pod on nodes that have that exact label key-value pair. This is the standard Kubernetes mechanism for node-level selection based on labels.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with `nodeAffinity` or `podAffinity`, thinking the more complex option is always better, but the CKA exam tests your ability to choose the simplest correct solution for a given requirement.

How to eliminate wrong answers

Option A is wrong because `spec.nodeName` forces the pod to run on a specific node by name, not by label, and it bypasses the scheduler entirely, which is not the intended use for selecting nodes with a GPU label. Option B is wrong because `podAffinity` is used to schedule pods relative to other pods (e.g., co-location), not to select nodes based on their labels. Option C is wrong because while `nodeAffinity` can also select nodes by label, it is a more complex and flexible construct; the question asks for a 'scheduling constraint' and the simplest correct answer is `nodeSelector`, not the more verbose affinity syntax.

Practice this question →

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

Mounting a ConfigMap as a volume is a fully supported way to expose its data. When you define a volume of type configMap and mount it into a pod, each key in the ConfigMap becomes a file in the specified mount path. Use the items field to project only specific keys if needed, and note that updates to the ConfigMap will eventually be reflected in the mounted files, though there is no immediate guarantee.

Why this answer

Option A is correct because a ConfigMap can be exposed to a pod by mounting it as a volume, which projects each key as a file inside the container's filesystem at a chosen mount path. Option E is correct because individual ConfigMap keys can be injected as environment variables using valueFrom.configMapKeyRef (or envFrom.configMapRef for all keys), letting the container read specific values as env vars. Option B is wrong because ConfigMaps are never automatically mounted at /etc/config; a volume mount must be explicitly declared in the pod spec with a mountPath.

Option C is wrong because a ConfigMap holds configuration data, not a container image, so it cannot be used as an image. Option D is wrong because ConfigMap data is not automatically exposed as environment variables; it must be explicitly referenced via envFrom or configMapKeyRef.

Exam trap

The trap here is that candidates often assume ConfigMaps are automatically available as environment variables or mounted at a default path, but Kubernetes requires explicit configuration for both methods.

Practice this question →

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

NoSchedule is a valid, hard taint effect that prevents the scheduler from placing new pods onto the tainted node unless they have a matching toleration. It has no effect on pods that are already running on the node; those pods continue to run unless they are evicted by other means. This effect is commonly used to restrict a node for dedicated workloads or to perform maintenance without disrupting existing pods.

Why this answer

In Kubernetes, taints are applied to nodes with a taint effect that determines how the scheduler and kubelet react to pods lacking a matching toleration. Option C, NoSchedule, is correct because it instructs the scheduler to avoid placing new pods on the node unless they tolerate the taint, while existing pods remain running. Option D, PreferNoSchedule, is correct because it is a soft preference: the scheduler tries to avoid the node but may still place pods there if no better option exists.

Option E, NoExecute, is correct because it not only prevents new pods from scheduling but also evicts already-running pods that do not tolerate the taint. Options A (NeverSchedule) and B (PreferSchedule) are not valid Kubernetes taint effects; the only supported effects are NoSchedule, PreferNoSchedule, and NoExecute.

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 →

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 each requesting 250m CPU sum to exactly 2000m, matching the node's allocatable CPU. The scheduler can place all 8 because the total request does not exceed capacity, and CPU requests are not burstable at this level—every pod is guaranteed its full 250m. This is the maximum number that can be scheduled based on CPU alone, since adding one more 250m request would require 2250m > 2000m.

Why this answer

The node has 2 CPU cores, which equals 2000m (2000 milliCPU). Each pod requests 250m CPU. Dividing 2000m by 250m gives 8 pods.

This calculation assumes no other pods or system overhead, and only considers CPU requests, not limits or other resources.

Exam trap

The trap here is that candidates may incorrectly convert 2 CPU cores to 2000m (which is correct) but then misapply the division, or confuse milliCPU with memory units (e.g., thinking 128Mi memory limits CPU count), leading to answers like 16 or 32.

How to eliminate wrong answers

Option A is wrong because 32 would require 8000m CPU (32 * 250m), but the node only has 2000m, so this answer incorrectly multiplies by memory or uses a wrong conversion. Option B is wrong because 16 would require 4000m CPU (16 * 250m), which is double the node's capacity, likely confusing 2 cores with 4 cores or misreading the request as 125m. Option C is wrong because 4 would require only 1000m CPU (4 * 250m), which is half the node's capacity, possibly from mistaking 2 cores as 2000m but dividing by 500m or thinking each core can run only one pod.

Practice this question →

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

spec.preemptionPolicy: Never is the correct field because PriorityClass supports a preemptionPolicy that controls whether pods with this class may evict lower-priority pods. The Kubernetes default is PreemptLowerPriority, which allows preemption; setting it to Never explicitly disables that behavior, making the PriorityClass non-preempting. This is the only option that directly affects the scheduler's preemption logic.

Why this answer

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 →

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

When a pod's toleration matches the key, value, and effect of a node's taint, the Kubernetes scheduler is permitted to schedule the pod onto that node. Tolerations do not force scheduling, but they successfully bypass the NoSchedule restriction imposed by the matching taint.

Why this answer

A toleration with `operator: Exists` and no `value` field matches any taint that has the specified key (`gpu`) and effect (`NoSchedule`), regardless of the taint's value. The taint `gpu=true:NoSchedule` has the key `gpu` and effect `NoSchedule`, so the toleration matches it perfectly, allowing the pod to be scheduled on the node. Tolerations do not require a value when using the `Exists` operator, as it checks only for the key and effect.

Exam trap

The trap here is that candidates often assume a toleration must specify a `value` to match a taint, forgetting that the `Exists` operator with no `value` field matches any value for the given key, making the toleration valid even without an explicit value match.

How to eliminate wrong answers

Option B is wrong because a `nodeSelector` is not required for tolerations to work; tolerations alone determine whether a pod can tolerate a taint, and scheduling is based on matching taints and tolerations, not node selectors. Option C is wrong because the `Exists` operator explicitly does not require a value; it matches any taint with the specified key and effect, so the absence of a value is intentional and valid. Option D is wrong because the question only specifies one taint on the node, and the pod's toleration matches that taint; other taints are not mentioned, and even if they existed, they would need their own matching tolerations to allow scheduling, but that is not part of the given scenario.

Practice this question →

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

A Job is immutable with respect to its pod template, so issuing `kubectl delete job data-processor` removes both the Job object and any completed Pods, and then `kubectl create job` (or `kubectl apply -f job.yaml`) creates a new Job resource that will schedule fresh Pods and run the template again. Without deletion, the old Job object's status and spec prevent an in-place rerun; a completed Job will never recreate its finished Pods.

Why this answer

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 →

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

The `kubectl create job` command is the correct imperative way to create a Kubernetes Job object named `hello`. It uses the busybox image and passes `echo Hello` as the container's command, and since a Job's default completion count is 1, the Job controller schedules one Pod that runs to successful exit. This Job-managed Pod is automatically restarted or recreated if it fails, fulfilling the requirement of a single Pod execution to completion.

Why this answer

`kubectl create job` is the dedicated command to create a Kubernetes Job object, which runs a pod to completion. The `--image=busybox` specifies the container image, and the `-- echo Hello` passes the command and its arguments to the container's entrypoint. This creates a non-repeating Job that executes the command once.

Exam trap

The trap here is that candidates confuse `kubectl create job` with `kubectl run` or `kubectl create cronjob`, mistakenly thinking a one-time task can be created with a deployment or cronjob syntax, or that `kubectl run` supports a 'job' subcommand.

How to eliminate wrong answers

Option B is wrong because `kubectl create cronjob` creates a CronJob, which schedules Jobs on a recurring basis, not a one-time Job. Option C is wrong because `kubectl create deployment` creates a Deployment, which manages a ReplicaSet to ensure a specified number of pods run continuously, not a single-run Job. Option D is wrong because `kubectl run job` is not a valid command; `kubectl run` can create a pod or deployment, but not a Job directly, and the syntax `kubectl run job` is incorrect.

Practice this question →

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

DaemonSets are the standard mechanism for running system-level services that need to be present on every node, such as log collectors (e.g., Fluentd), monitoring agents (e.g., Prometheus Node Exporter), and network components (e.g., kube-proxy, CNI plugins). Because these daemons provide cluster-wide functionality, they must be automatically scheduled on each node and removed when the node leaves, which is exactly what a DaemonSet guarantees.

Why this answer

Option C is correct because DaemonSets are designed for node-level cluster services such as log collectors (e.g., Fluentd/Fluent Bit), monitoring agents (e.g., node-exporter), and CNI/storage daemons, where one pod per node is needed. Option E is correct because a DaemonSet's core behavior is to ensure that all nodes, or a subset selected via nodeSelector/affinity/tolerations, run a copy of a specified pod, with new nodes automatically getting the pod. Option A is incorrect because DaemonSets are standalone controllers managed directly by the DaemonSet controller, not by a parent Deployment.

Option B is incorrect because DaemonSets do support rolling updates via updateStrategy: RollingUpdate (with maxUnavailable), as well as OnDelete. Option D is incorrect because DaemonSets do not use a desired replica count like Deployments or ReplicaSets; their pod count is determined by the number of matching nodes.

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 →

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

nodeName is the only field that directly assigns a pod to a specific node by its exact Node resource name. When nodeName is set, the kubelet on that node sees the pod in the API server and attempts to run it, completely bypassing the scheduling process. This is a hard assignment: the pod will never be scheduled elsewhere, and if the node does not exist or is not ready, the pod stays Pending or fails.

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 →

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

The DaemonSet controller uses the nodeSelector field to match node labels before scheduling pods. If a specific node lacks the required label or has a mismatched value, the controller will intentionally skip scheduling the DaemonSet pod on that node, leaving it as the sole exception.

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 →

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, which exceeds the capacity of any individual worker node, as each worker node only provides 1 CPU. Furthermore, the control-plane node, which might have sufficient CPU, is typically tainted with `node-role.kubernetes.io/control-plane:NoSchedule` or similar, preventing the scheduler from placing this pod on it unless the pod explicitly tolerates this taint. Consequently, no suitable node exists in the cluster to satisfy the pod's CPU request, leading to its Pending status.

Why this answer

The pod requests 2 CPU, but each worker node has only 1 CPU, making them insufficient. The control-plane node has the taint `node-role.kubernetes.io/master:NoSchedule` which the pod does not tolerate, so it is also unavailable. The event explicitly states '2 Insufficient cpu', confirming that the CPU request cannot be satisfied by any node.

Exam trap

The trap here is that candidates may focus on the taint message and assume the control-plane node's resources are the issue (Option D), or misinterpret the 'Insufficient cpu' as a memory problem (Option A), rather than recognizing that the CPU request exceeds the capacity of the only schedulable nodes (the workers).

How to eliminate wrong answers

Option A is wrong because the pod requests 1Gi memory, which is well within the capacity of any node (worker nodes typically have more than 1Gi memory), and the event does not mention memory insufficiency. Option B is wrong because priority and preemption are unrelated to the 'Pending' state caused by resource shortages; the event shows no preemption activity, and preemption would involve evicting lower-priority pods, not failing to schedule. Option D is wrong because the control-plane node is tainted with NoSchedule, making it unschedulable for this pod regardless of its resources; the issue is the taint, not insufficient resources on that node.

Practice this question →

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

When a StatefulSet is scaled down or deleted, Kubernetes intentionally preserves the associated PersistentVolumeClaims (PVCs) to prevent accidental data loss. This ensures that if the StatefulSet is scaled back up or recreated, the new pods can seamlessly reattach to their existing storage volumes and resume operations with their historical data intact.

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 →

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 '0/N' node count in kubectl describe means the scheduler evaluated all nodes and none satisfied the pod's combined requirements, such as nodeSelector, node affinity, required tolerations, or disk/resource requests. The pod's PodScheduled condition is False with a reason of Unschedulable, and events show failedScheduling. Multiple simultaneous constraints each eliminate different nodes, leaving no feasible candidate.

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 →

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

NoExecute is one of the two valid taint effects that actively prevent pods from being scheduled on a tainted node. In addition to preventing new pods without the toleration from landing there, it also evicts any existing pods on the node that do not tolerate the taint. This makes NoExecute the most aggressive effect, as it immediately removes running workloads, unlike NoSchedule which only blocks future scheduling.

Why this answer

NoSchedule (C) is correct because it is a taint effect that prevents new pods from being scheduled onto a tainted node unless the pod has a matching toleration; existing pods already running on the node are not evicted. NoExecute (B) is also correct because it not only prevents scheduling of pods without a matching toleration but also evicts already-running pods that do not tolerate the taint, making it a valid taint effect for blocking scheduling. PreferNoSchedule (A) is a soft preference, so the scheduler will try to avoid the node but may still place a pod there without a toleration, so it does not strictly prevent scheduling.

FailSchedule (D) and NoAdmit (E) are not valid Kubernetes taint effects; the only supported effects are NoSchedule, PreferNoSchedule, and NoExecute.

Exam trap

The trap here is that candidates often confuse `PreferNoSchedule` with a hard scheduling constraint, but it only provides a soft preference and does not prevent scheduling, unlike `NoSchedule` and `NoExecute` which are hard constraints.

Practice this question →

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

DaemonSets are the standard workload type for node-level agents because they guarantee coverage on every node. Common use cases include log shippers like Fluentd or Filebeat, which must run locally to forward each node's logs, and monitoring agents such as Prometheus Node Exporter or Datadog, which collect per-node metrics. Running such agents as a DaemonSet ensures they automatically appear on newly added nodes and are removed when nodes are deleted.

Why this answer

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 →

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

Kubernetes containers within a pod, including init and main containers, have isolated filesystems by default. For an init container to share data, such as a configuration file, with a main container, they must both mount the same shared volume, like an `emptyDir`. If the init container wrote the file to its own ephemeral filesystem or a volume not also mounted by the main container, the main container would correctly report "file not found" as it cannot access that location.

Why this answer

The most likely cause is that the init container wrote the configuration file to a volume that is not shared with the main container. In Kubernetes, init containers and main containers in the same Pod share the same filesystem only if they mount the same Volume. If the init container writes to a volume that is not mounted in the main container, or writes to a different path within the same volume, the main container will not see the file.

This is a common misconfiguration when using emptyDir or hostPath volumes.

Exam trap

The trap here is that candidates assume init containers and main containers automatically share the same filesystem, but Kubernetes isolates container filesystems by default unless volumes are explicitly shared.

How to eliminate wrong answers

Option B is wrong because if the main container restarts, init containers do not rerun by design — they run to completion before any main container starts, and their output persists in shared volumes, so a restart of the main container would still see the file if it was written to a shared volume. Option C is wrong because an incorrect command in the main container would typically cause a different error (e.g., command not found, exit code 127) or a crash loop, not a 'file not found' error, unless the command explicitly references a missing file. Option D is wrong because Kubernetes guarantees that init containers complete successfully before any main container starts; the Pod's lifecycle ensures the init container's status is 'Completed' before the main container's status moves to 'Running'.

Practice this question →

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

When you scale a StatefulSet from 3 replicas to 1 with the default OrderedReady policy, the controller deletes pods in reverse ordinal order: db-2 is terminated first, then db-1, and the process stops once only the pod with ordinal 0 remains. This maintains the StatefulSet identity and ordering guarantees, ensuring db-0 is the final surviving member. Each deletion is completed before the next pod is terminated, so db-0 is never at risk of being deleted.

Why this answer

With the OrderedReady pod management policy, scaling down a StatefulSet deletes pods in reverse ordinal order, starting from the highest index. When scaling from 3 to 1 replica, pods db-2 (index 2) is deleted first, then db-1 (index 1), leaving db-0 (index 0) running. This ensures that each pod is fully terminated before the next one is deleted, maintaining the ordered startup and shutdown guarantees.

Exam trap

Kubernetes often tests the misconception that scaling down deletes pods in ascending order (starting from db-0) or that all pods are deleted at once, but the correct behavior for OrderedReady is reverse ordinal deletion.

How to eliminate wrong answers

Option A is wrong because OrderedReady policy does not delete all pods simultaneously; it deletes them one at a time in reverse order. Option C is wrong because scaling down to 1 replica requires deleting both db-2 and db-1, not just db-2. Option D is wrong because it describes deletion in ascending ordinal order (db-0 first), which is the opposite of the correct reverse-order behavior for scaling down.

Practice this question →

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. When a pod carries a high-priority PriorityClass, the scheduler treats it as eligible for preemption: if the pod cannot be placed on any node because of insufficient resources, the scheduler identifies nodes running pods with lower priorities and evicts those lower-priority pods to free capacity for the pending high-priority pod. This is governed by the preemptionPolicy field in the PriorityClass, which defaults to PreemptLowerPriority, and the actual eviction is performed through the PodDisruptionBudget-aware API, though critical pods may be protected if they have higher priority or are in terminating state.

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 →

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

This command explicitly instructs the deployment controller to revert the deployment's state to the exact configuration defined in revision 1. It achieves this by scaling up the ReplicaSet associated with revision 1 while scaling down the current active ReplicaSet.

Why this answer

`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 →

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

The primary function of a PriorityClass is to assign a priority value to a pod, enabling the Kubernetes scheduler to make preemption decisions. When a higher-priority pod is pending due to insufficient resources on any node, the scheduler can evict one or more lower-priority pods from a suitable node to free up the necessary capacity. This mechanism ensures that critical workloads can always find space to run, even in a resource-constrained environment.

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 →

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

This is the correct syntax for mounting a Kubernetes Secret as a volume. The 'secret' volume source must be declared directly under the volume's name, and the 'secretName' field nested within it specifies the exact Secret resource to retrieve from the namespace.

Why this answer

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 →

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

`kubectl rollout history deployment web` is the dedicated subcommand that lists all historical rollouts for Deployment `web`, displaying a table of revisions with their change causes (e.g., `REVISION CHANGE-CAUSE`). Internally it reads the Deployment's managed ReplicaSets and their `deployment.kubernetes.io/revision` annotations; with `--revision=N` it can also show the complete pod template for a specific revision, making it the correct command to view rollout history.

Why this answer

The `kubectl rollout history deployment web` command retrieves the revision history of the specified Deployment, showing each revision number and, with the `--revision` flag, the details of a specific revision. This is the standard Kubernetes command for viewing rollout history, as defined in the kubectl reference.

Exam trap

The CKA exam often tests the distinction between commands that show current state (`describe`, `status`) versus those that show historical data (`rollout history`), leading candidates to confuse `rollout status` with `rollout history`.

How to eliminate wrong answers

Option A is wrong because `kubectl describe deployment web` shows the current state and configuration of the Deployment, including its rollout strategy, but does not display the historical revisions or changes. Option B is wrong because `kubectl get events --field-selector involvedObject.name=web` retrieves events related to the Deployment, which may include rollout-related events but does not provide a structured history of revisions. Option D is wrong because `kubectl rollout status deployment web` shows the current status of an ongoing rollout (e.g., waiting for pods to become ready), not the historical record of past rollouts.

Practice this question →

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's admission controller applies its declared default request and default limit to any Pod that omits resource requirements. Because default.cpu is 0.5 and default.limit is 1, the effective container specification becomes request: 0.5, limit: 1. This happens automatically at Pod creation, before the object is persisted, so you do not need to manually add the values to the manifest.

Why this answer

When a LimitRange is applied to a namespace, it automatically injects default resource requests and limits into pods that do not specify them. In this case, the LimitRange sets default CPU request to 0.5 and default CPU limit to 1, so the pod inherits these values. This ensures the pod is subject to resource constraints even without explicit specification.

Exam trap

The trap here is that candidates may think a pod without resource specifications will have no limits or requests, but the LimitRange admission controller automatically applies defaults, overriding the absence of explicit values.

How to eliminate wrong answers

Option B is wrong because a LimitRange default limit is applied, so the pod gets a limit of 1, not 0 (no limit). Option C is wrong because the LimitRange is active and applies defaults to pods without resource specifications, so the pod does not have zero values. Option D is wrong because it reverses the request and limit values, which does not match the LimitRange configuration.

Practice this question →

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

This is the correct command to revert the `web-app` Deployment to exactly revision 1. The `--to-revision=1` flag explicitly selects the first recorded revision from the rollout history, forcing Kubernetes to restore that revision's pod template spec. All later changes—such as image updates, environment variable modifications, or container command changes—are discarded, and the Deployment will scale down the current ReplicaSet and scale up the ReplicaSet corresponding to revision 1.

Why this answer

`kubectl rollout undo` with the `--to-revision` flag is the proper syntax to roll back a Deployment to a specific revision. The command `kubectl rollout undo deployment web-app --to-revision=1` reverts the Deployment to revision 1, as shown in the rollout history output.

Exam trap

The trap here is that candidates confuse the `--revision` flag (used with `kubectl rollout history`) with the `--to-revision` flag required for `kubectl rollout undo`, or they mistakenly think `kubectl rollback` is a valid command.

How to eliminate wrong answers

Option A is wrong because `kubectl rollout undo` does not accept a `--revision` flag; the correct flag is `--to-revision`. Option C is wrong because `kubectl rollback` is not a valid kubectl command; the correct command is `kubectl rollout undo`. Option D is wrong because it rolls back to the previous revision (revision 2), not to revision 1, as it omits the `--to-revision` flag.

Practice this question →

MCQmedium

A container requests 256Mi memory and has a limit of 512Mi. The container tries to allocate 600Mi. What happens?

A.The container is allowed to use up to 600Mi if the node has free memory

B.The kernel throttles the container's memory usage

C.The container is killed with OOMKilled and restarted

D.The container is evicted from the node

AnswerC

When a container exceeds its 512Mi memory limit, the kernel's OOM killer terminates the process, resulting in an OOMKilled status. Because the default restartPolicy for Pods is Always, the kubelet will automatically restart the container in an attempt to restore the application's availability.

Why this answer

The container's memory limit is 512Mi, and it attempts to allocate 600Mi, which exceeds the limit. Kubernetes enforces memory limits via cgroups; when a container exceeds its memory limit, the kernel's OOM killer terminates the process, resulting in an OOMKilled status. The container will then be restarted according to its restart policy (e.g., Always).

Exam trap

The trap here is confusing memory limits with node-level memory pressure or CPU throttling, leading candidates to think the container can burst beyond its limit if node memory is available, or that memory usage is throttled like CPU.

How to eliminate wrong answers

Option A is wrong because the container is not allowed to exceed its memory limit (512Mi) even if the node has free memory; Kubernetes enforces the limit via cgroups, not node availability. Option B is wrong because memory throttling (e.g., via CPU cfs quota) applies to CPU, not memory; exceeding the memory limit triggers an OOM kill, not throttling. Option D is wrong because eviction occurs when the node is under memory pressure and the pod exceeds its request, not when a single container exceeds its limit; the container is killed and restarted in place, not evicted from the node.

Practice this question →

MCQhard

You have a Deployment 'db' with 3 replicas. Each pod writes to a PersistentVolumeClaim (PVC). A StatefulSet is required for stable network identities and ordered pod management. Which of the following is a key characteristic that differentiates a StatefulSet from a Deployment?

A.StatefulSets support rolling updates but not canary deployments

B.StatefulSets automatically create a Service for each pod

C.StatefulSets cannot use PersistentVolumeClaims

D.StatefulSets maintain a sticky identity for each pod, including stable hostnames and persistent storage

AnswerD

StatefulSets are designed to provide a stable, unique identity to each pod they manage, which is crucial for stateful applications. This identity includes a stable network hostname, typically in the format `$(pod-name).$(headless-service-name)`, and persistent storage that remains associated with the pod's ordinal index even if the pod is rescheduled to a different node. This ensures data integrity and consistent application behavior across pod lifecycle events.

Why this answer

StatefulSets assign each pod a unique, stable network identity (e.g., a hostname derived from the StatefulSet name and ordinal index) and guarantee that each pod's PersistentVolumeClaim is bound to the same PersistentVolume across rescheduling. This ensures that each pod retains its identity and data, which is critical for stateful applications like databases. Deployments, in contrast, treat pods as interchangeable and do not guarantee stable hostnames or persistent storage binding.

Exam trap

The trap here is that candidates often confuse the automatic creation of a Headless Service (which is required but not automatically created) with the automatic creation of a Service for each pod, leading them to incorrectly select Option B.

How to eliminate wrong answers

Option A is wrong because StatefulSets do support canary deployments via the `partition` parameter in the rolling update strategy, allowing a subset of pods to be updated while others remain unchanged. Option B is wrong because StatefulSets do not automatically create a Service for each pod; they require a Headless Service (with `clusterIP: None`) to provide stable network identities, but the Service itself is not automatically created by the StatefulSet controller. Option C is wrong because StatefulSets can and commonly do use PersistentVolumeClaims, and the StatefulSet controller manages the creation and binding of PVCs for each pod based on a `volumeClaimTemplate`.

Practice this question →

MCQeasy

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

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

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

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

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

AnswerD

This command correctly uses the `--from-file` flag, which instructs `kubectl` to read the entire content of the specified file, `config.properties`. It then creates a ConfigMap named `app-config` where the key for this entry defaults to the filename, `config.properties`, and its corresponding value is the complete textual content of that file. This is the standard and intended method for incorporating file contents directly into a ConfigMap.

Why this answer

`kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the content of the file 'config.properties'. The `--from-file` flag reads the file and stores its entire content as a single key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content. This is the standard syntax for creating a ConfigMap from a file in Kubernetes.

Exam trap

The trap here is confusing `--from-file` with `--from-env-file`; candidates often mistakenly choose `--from-env-file` because they think it reads any configuration file, but it only works with files formatted as environment variable definitions (KEY=VALUE per line), not arbitrary files like config.properties.

How to eliminate wrong answers

Option A is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option B is wrong because `--from-env-file` is used to import a file containing key-value pairs in a line-by-line format (like a .env file), not to store the entire file content as a single key. Option C 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 reference a file.

Practice this question →

Multi-Selecthard

Which TWO of the following are valid ways to specify resource requests and limits for a container in a pod? (Select 2)

Select 2 answers

A.spec: containers: - name: app cpu: 0.5 memory: 512Mi

B.spec: containers: - name: app resource: request: cpu: 1 memory: 1Gi limit: cpu: 2 memory: 2Gi

C.spec: containers: - name: app resources: requests: cpu: "500m" memory: "512Mi" limits: cpu: "1" memory: "1Gi"

D.spec: containers: - name: app resources: limits: cpu: "1" memory: "1Gi"

E.spec: containers: - name: app resources: requests: cpu: "500 millicores" memory: "512 MB"

AnswersC, D

This is the canonical way to specify resource requirements in Kubernetes: each container has a `resources` field containing `requests` and `limits`. The `cpu` value `"500m"` means 500 milliCPUs (half a core), and `"1"` means one full core; memory uses binary suffixes, with `"512Mi"` and `"1Gi"` being valid mebibyte units. These strings are parsed by Kubernetes quantity format, and this structure is accepted by the API server while satisfying both scheduling and kubelet constraints.

Why this answer

Options C and D are both correct. Option C uses the correct YAML structure with a `resources` block containing both `requests` and `limits`, and specifies CPU as a string (e.g., "500m") and memory as a string (e.g., "512Mi"). Option D is also valid because Kubernetes allows specifying only `limits` without `requests`; the request defaults to the limit if omitted.

Both options conform to the Kubernetes API specification for resource management in Pod containers. Options A, B, and E contain invalid syntax: A uses CPU and memory directly under the container without a resources block; B uses the singular `resource` instead of the plural `resources`; E uses invalid units ('millicores' and 'MB').

Exam trap

The trap here is that candidates often confuse the singular `resource` with the correct plural `resources`, or they incorrectly place CPU/memory fields directly under the container spec without the proper nesting, mimicking the syntax of Docker Compose or older Kubernetes versions.

Practice this question →

MCQhard

You have a PriorityClass named 'high-priority' with value 1000 and 'low-priority' with value 100. A Pod with 'high-priority' is pending because no node has enough resources. Another Pod with 'low-priority' is running on a node. Will the high-priority Pod preempt the low-priority Pod?

A.No, because preemption only works on nodes with taints

B.No, because preemption is disabled by default

C.Yes, but only if the high-priority Pod has tolerations for the node's taints

D.Yes, because the high-priority Pod has a higher priority value and the scheduler will try to preempt lower-priority pods

AnswerD

This is correct because when a high-priority Pod cannot be scheduled due to insufficient resources, the scheduler actively looks for nodes where evicting lower-priority pods can free up enough capacity. The scheduler will then preempt those lower-priority pods, allowing the high-priority Pod to be scheduled and run.

Why this answer

Kubernetes Pod priority-based preemption is a built-in scheduler feature. When a high-priority Pod (value 1000) cannot be scheduled due to insufficient resources, the scheduler identifies and preempts (evicts) lower-priority Pods (value 100) to free up resources, regardless of taints or tolerations. This behavior is controlled by the `Priority` and `PriorityClass` objects, and preemption is enabled by default in the scheduler.

Exam trap

The trap here is that candidates often confuse preemption with taints/tolerations or assume preemption is disabled by default, but the CKA exam expects you to know that preemption is enabled by default and triggered solely by priority value differences, not by node conditions.

How to eliminate wrong answers

Option A is wrong because preemption is not tied to taints; it is a resource-based scheduling decision that can occur on any node, and taints/tolerations are separate mechanisms for node selection. Option B is wrong because preemption is enabled by default in the Kubernetes scheduler (controlled by the `enablePreemption` flag in the scheduler configuration, which defaults to true). Option C is wrong because preemption does not require the high-priority Pod to have tolerations for the node's taints; preemption evicts lower-priority Pods to make room, and tolerations are only needed if the high-priority Pod needs to tolerate node taints after preemption.

Practice this question →

MCQeasy

Which kubectl command will show the rollout history of a Deployment named 'web-app'?

A.kubectl describe deployment web-app

B.kubectl rollout status deployment web-app

C.kubectl rollout history deployment web-app

D.kubectl get deployment web-app -o yaml

AnswerC

kubectl rollout history deployment web-app is correct because it is the dedicated kubectl subcommand for viewing the Deployment's rollout history. It lists all revisions with their change-cause annotations (if set), and can be combined with --revision to inspect a specific revision; this history is actually derived from the underlying ReplicaSets created for each change to the pod template.

Why this answer

`kubectl rollout history deployment web-app` is the dedicated command to display the rollout history of a Deployment, including revision numbers and change-cause annotations. This command retrieves the stored ReplicaSet revisions associated with the Deployment, allowing you to see past rollout states.

Exam trap

The trap here is that candidates confuse `rollout status` (which shows live progress) with `rollout history` (which shows past revisions), or assume `describe` or `get -o yaml` will expose the revision list, but neither command formats the rollout history in the concise, revision-based output that `rollout history` provides.

How to eliminate wrong answers

Option A is wrong because `kubectl describe deployment web-app` shows the current state and metadata of the Deployment, but does not display the rollout history or revision list. Option B is wrong because `kubectl rollout status deployment web-app` shows the current progress of a rollout (e.g., waiting for pods to become ready), not the historical record of past rollouts. Option D is wrong because `kubectl get deployment web-app -o yaml` outputs the full YAML manifest of the Deployment, which includes the `spec.revisionHistoryLimit` and `status.observedGeneration` but does not present the formatted rollout history with revision numbers and change-causes.

Practice this question →

MCQhard

You have a ResourceQuota in a namespace that sets limits: pods: 10, requests.cpu: 4, requests.memory: 8Gi. You try to create a Pod with requests.cpu: 1, requests.memory: 2Gi, and no limits. The namespace currently has 8 pods using 3 CPUs and 5Gi memory in total requests. What happens?

A.The pod is created successfully.

B.The pod is rejected because it exceeds the memory request quota.

C.The pod is rejected because it exceeds the CPU request quota.

D.The pod is rejected because it does not specify CPU and memory limits.

AnswerA

The new pod's resource requests are 1 CPU and 2Gi memory. When combined with the existing pods' total requests of 3 CPU and 5Gi memory, the cumulative resource consumption becomes 4 CPU and 7Gi memory. Since the ResourceQuota specifies hard limits of 4 CPU and 8Gi memory for requests, both the CPU and memory totals remain at or below their respective quotas. Therefore, the admission controller allows the pod to be created without any quota violations.

Why this answer

The ResourceQuota only enforces the total sum of requests across all pods in the namespace. Currently, the namespace has 8 pods using 3 CPUs and 5Gi memory. Adding a pod with requests.cpu: 1 and requests.memory: 2Gi would bring totals to 4 CPUs (3+1) and 7Gi memory (5+2), both within the quota limits of 4 CPUs and 8Gi.

The pod does not specify limits, but ResourceQuota does not require limits unless a LimitRange enforces default limits; here, no LimitRange is mentioned, so the pod is allowed.

Exam trap

The trap here is that candidates often assume a ResourceQuota enforces both requests and limits simultaneously, or that creating a pod without limits will be rejected, but Kubernetes only rejects pods if the sum of requests (or limits, if specified) would exceed the quota, and it does not require limits unless a LimitRange is present.

How to eliminate wrong answers

Option B is wrong because the total memory requests after creation would be 7Gi, which is under the 8Gi quota limit, so it does not exceed the memory request quota. Option C is wrong because the total CPU requests after creation would be exactly 4 CPUs, which is at the quota limit but not exceeded (the quota allows up to 4 CPUs, and equality is permitted). Option D is wrong because ResourceQuota does not require pods to specify CPU and memory limits; it only enforces requests and limits if they are set, and without a LimitRange, a pod can be created without limits.

Practice this question →

Multi-Selecthard

Which THREE of the following are valid ways to restrict or influence pod scheduling using taints and tolerations? (Select THREE.)

Select 3 answers

A.Adding a taint with effect NoSchedule to a node

B.Adding a toleration to a pod to prevent it from being scheduled on certain nodes

C.Adding a taint with effect PreferNoSchedule to a node

D.Applying a nodeSelector to a pod to match node labels

E.Adding a taint with effect NoExecute to a node

AnswersA, C, E

A NoSchedule taint on a node instructs the Kubernetes scheduler to exclude any Pod that does not have a matching toleration from being placed onto that node. It is a hard scheduling constraint: the scheduler will not assign new Pods to that node unless the Pod's toleration matches the taint's key, value, and effect. However, Pods already running on the node are not evicted by this effect, so it is useful for cordoning off nodes for maintenance without disrupting workloads.

Why this answer

Adding a taint with effect NoSchedule (option A) prevents scheduling of pods without matching tolerations onto the node. Adding a taint with effect PreferNoSchedule (option C) is a soft preference that tries to avoid scheduling pods without tolerations onto the node but does not guarantee it. Adding a taint with effect NoExecute (option E) not only prevents scheduling but also evicts any existing pods that do not tolerate the taint.

Options B and D are not valid uses of taints and tolerations: tolerations allow pods to be scheduled on tainted nodes, not prevent scheduling, and nodeSelector is a separate mechanism not based on taints and tolerations.

Exam trap

The trap here is that candidates often confuse tolerations as a way to repel pods from nodes, when in fact tolerations allow pods to be scheduled onto tainted nodes, while taints themselves repel pods.

Practice this question →

MCQmedium

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {gpu: true} that the pod didn't tolerate, 3 node(s) had resource pressure.'. What is the most likely cause?

A.The pod has a nodeSelector that doesn't match any node.

B.The pod is using a deprecated API version.

C.The pod needs a toleration for the gpu taint, and nodes have resource constraints.

D.The pod's image pull secret is missing.

AnswerC

The scheduler cannot place the pod because the available nodes either carry a gpu taint that the pod does not tolerate, or they lack sufficient CPU/memory capacity to satisfy the pod's resource requests. To resolve this, you must add the appropriate tolerations to the pod specification and ensure the cluster has nodes with adequate allocatable resources.

Why this answer

The event message explicitly states that 1 node has a taint (gpu: true) that the pod does not tolerate, and 3 nodes have resource pressure (e.g., memory, disk, or PID exhaustion). A pod remains in Pending state when no node can satisfy its scheduling requirements; adding a toleration for the gpu taint would allow scheduling on that node, but the resource pressure on the other nodes must also be resolved (e.g., by freeing resources or increasing capacity).

Exam trap

CKA often tests the distinction between taint/toleration issues and other scheduling constraints (like nodeSelector or affinity), and the trap here is that candidates may overlook the resource pressure component and focus only on the taint, or confuse the event message with a nodeSelector mismatch.

How to eliminate wrong answers

Option A is wrong because the event message does not mention any nodeSelector mismatch; it specifically cites taints and resource pressure, not label mismatches. Option B is wrong because deprecated API versions cause warnings or failures during resource creation, not a Pending state with scheduling events about taints and resource pressure. Option D is wrong because a missing image pull secret would cause an ImagePullBackOff or ErrImagePull event, not a Pending state with scheduling-related events about taints and resource pressure.

Practice this question →

MCQmedium

A HorizontalPodAutoscaler (HPA) is configured for a Deployment with targetCPUUtilizationPercentage: 80. The current CPU utilization is 90%. The deployment has minReplicas: 3 and maxReplicas: 10. What will the HPA do?

A.It does nothing because the utilization is within the acceptable range.

B.It adds a new node to the cluster.

C.It decreases the number of replicas to reduce CPU usage.

D.It increases the number of replicas.

AnswerD

This is the correct behavior because the current average CPU utilization (90%) is higher than the target utilization (80%). The HPA controller uses the formula of desired replicas equals the ceiling of current replicas multiplied by the ratio of current metric value to target metric value. Since this ratio is greater than 1.0, the controller will increase the replica count of the deployment to distribute the load and bring utilization down.

Why this answer

The HPA increases the number of replicas because the current CPU utilization (90%) exceeds the target of 80%. The HPA calculates the desired replica count using the formula: desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)], which yields ceil[3 * (90/80)] = ceil[3.375] = 4 replicas. This scales the deployment up to reduce per-pod CPU load, staying within the configured minReplicas (3) and maxReplicas (10).

Exam trap

The CKA exam often tests the misconception that the HPA can directly manage cluster nodes, but the HPA only adjusts pod replicas; node autoscaling is a separate component.

How to eliminate wrong answers

Option A is wrong because the utilization of 90% is above the target of 80%, so the HPA does not consider it within the acceptable range and must act. Option B is wrong because the HPA only manages replica counts within the cluster; node scaling is handled by the Cluster Autoscaler, not the HPA, and the HPA does not directly add nodes. Option C is wrong because increasing utilization above the target triggers scale-up, not scale-down; decreasing replicas would further increase per-pod CPU load, worsening the situation.

Practice this question →

MCQmedium

You have a DaemonSet that is supposed to run on all nodes, but you notice it is not running on a node with a taint 'dedicated=monitoring:NoSchedule'. What must be added to the DaemonSet's pod template to make it run on that node?

A.Add the annotation 'scheduler.alpha.kubernetes.io/tolerations'

B.A nodeSelector with key 'dedicated' and value 'monitoring'

C.Set the priorityClassName to 'system-node-critical'

D.A toleration with key 'dedicated', value 'monitoring', effect 'NoSchedule'

AnswerD

To allow DaemonSet pods to schedule on nodes carrying the 'dedicated=monitoring:NoSchedule' taint, you must define a matching toleration in the Pod template spec. This toleration explicitly permits the scheduler to place the pods on these tainted nodes, ensuring complete cluster-wide coverage for the DaemonSet.

Why this answer

A DaemonSet's pods must tolerate a node's taints to be scheduled on that node. The taint 'dedicated=monitoring:NoSchedule' means pods without a matching toleration will not be scheduled. Adding a toleration with key 'dedicated', value 'monitoring', and effect 'NoSchedule' explicitly allows the DaemonSet pod to bypass this taint and run on the node.

Exam trap

The trap here is that candidates often confuse nodeSelector (which selects nodes by labels) with tolerations (which handle taints), leading them to pick option B, but nodeSelector does not override taints.

How to eliminate wrong answers

Option A is wrong because 'scheduler.alpha.kubernetes.io/tolerations' is a deprecated annotation from early Kubernetes versions and is not the standard way to add tolerations; the correct method is to use the 'tolerations' field in the pod spec. Option B is wrong because a nodeSelector with key 'dedicated' and value 'monitoring' would only schedule pods on nodes that have that label, but it does not address the taint; the pod would still be blocked by the NoSchedule taint. Option C is wrong because setting priorityClassName to 'system-node-critical' increases the pod's priority but does not bypass taints; tolerations are required to override scheduling restrictions from taints.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid strategies for a Deployment's rolling update? (Select TWO.)

Select 2 answers

A.maxUnavailable: 0

B.maxSurge: 1

C.podManagementPolicy: OrderedReady

D.scaleUp: 2

E.type: Recreate

AnswersA, B

Setting maxUnavailable to 0 ensures that no pods are terminated before new ones are ready. This guarantees that 100% of the desired replica count remains available during a rolling update, preventing any capacity drop. It is a valid configuration under the rollingUpdate strategy field of a Deployment.

Why this answer

In a Kubernetes Deployment's rollingUpdate strategy, maxUnavailable: 0 (option A) is valid because it guarantees that the number of available Pods never drops below the desired replica count during an update, forcing new Pods to become Ready before old ones are terminated. maxSurge: 1 (option B) is also valid because it allows the Deployment to temporarily exceed the desired replica count by one Pod, enabling new Pods to be created before old ones are removed. Both fields belong under spec.strategy.rollingUpdate and accept either an integer or a percentage. Option C (podManagementPolicy: OrderedReady) is a StatefulSet field, not a Deployment rolling-update parameter.

Option D (scaleUp: 2) is not a Kubernetes Deployment field at all. Option E (type: Recreate) is a valid Deployment strategy type, but it is not a rolling-update strategy since it terminates all existing Pods before creating new ones.

Exam trap

The trap here is that candidates often confuse `podManagementPolicy` (a StatefulSet-only field) with Deployment update strategies, or incorrectly assume that `scaleUp` is a valid rolling update parameter, when in fact only `maxSurge` and `maxUnavailable` are used.

Practice this question →

MCQhard

A StatefulSet named 'web' has 3 replicas. You need to update the container image from 'nginx:1.19' to 'nginx:1.20' using a rolling update with ordered pod management. What must you ensure in the StatefulSet spec?

A.Set spec.updateStrategy.rollingUpdate.maxSurge to 1

B.Set spec.updateStrategy.rollingUpdate.partition to 0

C.Set spec.podManagementPolicy to Parallel

D.Set spec.podManagementPolicy to OrderedReady (default)

AnswerD

Setting `spec.podManagementPolicy` to `OrderedReady` is the correct choice, as it is the default and ensures ordered, one-at-a-time updates. This policy dictates that the StatefulSet controller will create, update, or delete pods strictly in ascending ordinal order (for creation/update) or descending ordinal order (for deletion), waiting for each pod to be fully ready or terminated before proceeding to the next. This sequential processing is crucial for maintaining the stable identity and data consistency of stateful applications during lifecycle events.

Why this answer

For a StatefulSet to perform a rolling update with ordered pod management (pods updated one at a time in reverse ordinal order), the podManagementPolicy must be set to OrderedReady. This is the default policy and ensures that pods are created, deleted, and updated in a strict sequential order, maintaining the stable identity and startup ordering required by stateful applications.

Exam trap

The trap here is that candidates often confuse Deployment rolling update parameters (like maxSurge or maxUnavailable) with StatefulSet update strategies, or mistakenly think that setting a partition value is required for a full rolling update, when in fact the key requirement is the podManagementPolicy being OrderedReady.

How to eliminate wrong answers

Option A is wrong because maxSurge is not a valid field in the StatefulSet update strategy; it is used in Deployments to control how many extra pods can be created during a rolling update, but StatefulSets do not support maxSurge. Option B is wrong because setting spec.updateStrategy.rollingUpdate.partition to 0 is the default and does not affect the ordered rolling update behavior; partition is used for canary or phased rollouts, not for enabling ordered updates. Option C is wrong because setting spec.podManagementPolicy to Parallel would cause all pods to be created or deleted concurrently, which defeats the ordered pod management required for a rolling update that updates pods one at a time in reverse order.

Practice this question →

MCQmedium

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

A.spec.strategy.rollingUpdate.maxUnavailable

B.spec.updateStrategy.rollingUpdate.maxUnavailable

C.spec.replicas.maxUnavailable

D.spec.strategy.rollingUpdate.maxSurge

AnswerA

This is the correct field path for defining rolling update behavior in a Kubernetes Deployment. By setting spec.strategy.rollingUpdate.maxUnavailable to 2, you guarantee that at least 2 pods (out of the 4 desired replicas) remain active and available to serve traffic at any given point during the rolling update process.

Why this answer

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

Exam trap

The trap here is confusing `maxUnavailable` with `maxSurge`; candidates often pick `maxSurge` thinking it controls unavailability, but it actually controls how many extra Pods can be created above the replica count during an update.

How to eliminate wrong answers

Option B is wrong because the correct path is `spec.strategy.rollingUpdate.maxUnavailable`, not `spec.updateStrategy.rollingUpdate.maxUnavailable`; the `updateStrategy` field does not exist in the Deployment spec. Option C is wrong because `spec.replicas` is an integer specifying the desired number of replicas, not a field that accepts a subfield like `maxUnavailable`. Option D is wrong because `spec.strategy.rollingUpdate.maxSurge` controls the maximum number of Pods that can be created above the desired replicas during an update, not the number of unavailable Pods.

Practice this question →

MCQmedium

A pod with an init container that runs a database migration fails. The init container exits with code 1. What is the pod's status?

A.Init:CrashLoopBackOff

B.Pending

C.Failed

D.Running

AnswerA

When an init container fails (e.g., exits with a non-zero status code), Kubernetes will restart it according to its restart policy. If it repeatedly fails, Kubernetes applies an exponential back-off delay between restart attempts. This continuous cycle of starting, failing, and backing off is precisely what the "Init:CrashLoopBackOff" status indicates for an init container, preventing the main application containers from ever starting.

Why this answer

When an init container exits with a non-zero exit code (code 1), Kubernetes considers the init container to have failed. By default, the pod restarts the init container according to the pod's restart policy (which defaults to Always for pods, but init containers always restart on failure regardless of the pod's restart policy). This repeated failure and restart cycle places the pod in the Init:CrashLoopBackOff status, indicating that the init container is crashing in a loop.

Exam trap

The trap here is that candidates confuse the pod phase (Pending, Running, Failed) with the detailed pod status condition (Init:CrashLoopBackOff), and mistakenly choose 'Failed' thinking the init container failure ends the pod, not realizing Kubernetes will retry the init container automatically.

How to eliminate wrong answers

Option B (Pending) is wrong because the pod has already started executing its init containers; it is not stuck waiting for scheduling or image pull. Option C (Failed) is wrong because a pod enters the Failed phase only when all its containers have terminated and the pod will not be restarted (e.g., a non-init container with restart policy Never), but here the init container will be retried. Option D (Running) is wrong because the pod's init container has not completed successfully, so the pod's status cannot be Running; the pod remains in a waiting state until all init containers succeed.

Practice this question →

MCQhard

You have a PriorityClass 'high-priority' with value 1000 and 'low-priority' with value 100. A pod A with 'high-priority' is pending because the node has no resources. A pod B with 'low-priority' is running on that node. What will happen if preemption is enabled?

A.Pod A will be scheduled only after pod B completes its work

B.Pod A will remain pending because preemption is not enabled by default

C.The cluster administrator must manually delete pod B to allow pod A to schedule

D.Pod B will be preempted (evicted) to allow pod A to be scheduled on the node

AnswerD

This is the correct behavior. When Pod A, possessing a higher priority, cannot find a node with sufficient available resources, the kube-scheduler will identify a node where Pod B (a lower-priority pod) is running and whose eviction would free up the necessary resources. The scheduler then initiates the preemption process, which involves evicting Pod B from that node. This action frees up the required resources, allowing Pod A to be successfully scheduled and started on the now-available node.

Why this answer

When preemption is enabled, the Kubernetes scheduler can evict lower-priority pods to free resources for pending higher-priority pods. In this scenario, Pod A (priority 1000) is pending due to insufficient resources, while Pod B (priority 100) is running on the node. The scheduler will preempt (evict) Pod B to allow Pod A to be scheduled, as the priority difference is significant and preemption is enabled by default in Kubernetes (via the 'PrioritySort' and 'Preemption' plugins).

Exam trap

The trap here is that candidates often assume preemption requires manual configuration or is disabled by default, but Kubernetes enables preemption by default in the scheduler, and the scheduler automatically handles eviction without administrator intervention.

How to eliminate wrong answers

Option A is wrong because preemption does not wait for the lower-priority pod to complete; it actively evicts it to schedule the higher-priority pod. Option B is wrong because preemption is enabled by default in Kubernetes (the 'Preemption' plugin is active in the default scheduler configuration), so Pod A will not remain pending if a lower-priority pod can be evicted. Option C is wrong because the scheduler automatically handles preemption without manual intervention from the cluster administrator.

Practice this question →