CCNA Workloads and Scheduling Questions — Page 2 of 2

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

Exceeding memory limit triggers OOM kill. With default restartPolicy, it restarts.

Why this answer

When a container exceeds its memory limit, the kernel OOM killer terminates it. The container will be restarted (depending on restartPolicy).

Practice this question →

MCQeasy

Which kubectl command lists all events in the cluster, sorted by timestamp (newest first)?

A.kubectl get events --sort-by='.metadata.creationTimestamp'

B.kubectl get events --watch

C.kubectl get events --all-namespaces --sort-by='.lastTimestamp'

D.kubectl get events --all-namespaces --sort-by='.firstTimestamp'

AnswerC

Correct. This shows all events sorted by lastTimestamp in ascending order; reverse for newest first.

Why this answer

Option C is correct because `kubectl get events --all-namespaces --sort-by='.lastTimestamp'` retrieves events from all namespaces and sorts them by the `lastTimestamp` field in ascending order, which effectively displays the newest events last. To show newest first, you would typically add `--sort-by='.lastTimestamp'` and reverse the output, but among the given options, this is the only one that uses the correct field for sorting by time and includes all namespaces, which is necessary for cluster-wide events.

Exam trap

The trap here is that candidates often confuse `firstTimestamp` with `lastTimestamp`, or forget that `--all-namespaces` is required to see cluster-wide events, leading them to pick Option A or D without considering the correct field for newest-first ordering.

How to eliminate wrong answers

Option A is wrong because `--sort-by='.metadata.creationTimestamp'` sorts by the event object's creation timestamp, which is not the same as the event occurrence time; events can be created after the fact, so this does not reflect the actual event order. Option B is wrong because `--watch` continuously streams new events but does not sort existing events by timestamp; it shows events as they occur, not sorted historically. Option D is wrong because `--sort-by='.firstTimestamp'` sorts by the first occurrence of a recurring event, which may not reflect the most recent event time; for a list of all events sorted by newest first, `lastTimestamp` is the correct field.

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

Each pod in a StatefulSet gets a unique ordinal index and stable hostname, and retains its storage across rescheduling.

Why this answer

Option D is correct because 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 creates a ConfigMap with a key 'config.properties' and the file content as value.

Why this answer

Option D is correct because `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the 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 correct YAML structure for requests and limits.

Why this answer

Option C is correct because it uses the correct YAML structure with a `resources` block containing `requests` and `limits` subfields, and specifies CPU as a string (e.g., "500m") and memory as a string (e.g., "512Mi") under the container spec. This matches the Kubernetes API specification for resource management in Pod containers.

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 →

MCQeasy

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

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

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

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

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

AnswerA

Correct command. The file content is stored under the key 'config.properties'.

Why this answer

Option A is correct because the `kubectl create configmap` command with the `--from-file` flag creates a ConfigMap from the contents of a specified file. When you use `--from-file=config.properties`, Kubernetes reads the file and creates a ConfigMap with a single key named after the filename (config.properties) and the file's content as the value. This is the standard method for importing configuration data from a properties file into a ConfigMap.

Exam trap

CNCF often tests the distinction between `--from-file`, `--from-literal`, and `--from-env-file` flags, and the trap here is confusing `--from-env` (which doesn't exist) with `--from-env-file` or misusing `--from-literal` to reference a file path instead of a key-value pair.

How to eliminate wrong answers

Option B is wrong because `--from-file=app-config=config.properties` uses an explicit key-value syntax where 'app-config' is the key name, not the ConfigMap name; this would create a ConfigMap named 'app-config' but with a key 'app-config' and value from the file, which is not the standard way to import a file with its original name. Option C is wrong because `--from-env` is not a valid flag for `kubectl create configmap`; the correct flag for importing environment-style files is `--from-env-file`, and `--from-env` would cause a syntax error. Option D is wrong because `--from-literal` is used to specify key-value pairs directly in the command line (e.g., `--from-literal=key=value`), not to reference a file; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal key with no value, which is incorrect.

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

The scheduler will attempt to preempt a lower-priority pod if necessary.

Why this answer

Option B is correct. Pod preemption occurs when a higher-priority pod cannot be scheduled because of insufficient resources on nodes. The scheduler will attempt to preempt (evict) lower-priority pods to make room.

Option A is incorrect because preemption is enabled by default but can be disabled. Option C is incorrect because preemption is not limited to nodes with taints. Option D is incorrect because priority values determine preemption behavior; higher value can preempt lower value.

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

This is the correct command to view rollout history.

Why this answer

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

All quotas are still within limits after creating the pod.

Why this answer

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

Pods without the matching toleration will not be scheduled on that node.

Why this answer

Adding a taint with effect NoSchedule to a node tells the Kubernetes scheduler not to schedule any pods onto that node unless they have a matching toleration. This is a core use of taints and tolerations to restrict pod placement, making option A correct.

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 pod needs to tolerate the taint and the nodes need sufficient resources.

Why this answer

The pod is Pending because it cannot be scheduled: one node has an untolerated taint, and other nodes have resource pressure (e.g., insufficient memory/CPU). Both issues prevent scheduling.

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

Since utilization exceeds the target, the HPA will scale up.

Why this answer

Option B is correct. The HPA will increase the number of replicas to bring the average CPU utilization down to 80%. Option A is incorrect because HPA does not add nodes, it adds pods.

Option C is incorrect because the threshold is crossed (90% > 80%), so it will scale up. Option D is incorrect because HPA does not use pod priority.

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

Adding this toleration allows the pod to schedule on nodes with the matching taint.

Why this answer

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

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

Why this answer

Option A is correct because setting `maxUnavailable: 0` ensures that during a rolling update, no Pods are taken down below the desired replica count, guaranteeing zero downtime. This is a valid strategy when you want to maintain full availability at the cost of potentially slower updates, as new Pods must be created before any old ones are terminated.

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

OrderedReady ensures that pods are updated one at a time in order, which is the requirement.

Why this answer

Option C is correct. StatefulSets support two pod management policies: OrderedReady (default) and Parallel. OrderedReady ensures that pods are updated one by one in order, which is the desired behavior.

The update strategy can be RollingUpdate or OnDelete; RollingUpdate with OrderedReady policy performs a rolling update maintaining order. Option A is incorrect because Partition is for canary deployments, not for ordered updates. Option B is incorrect because Parallel policy does not maintain order.

Option D is incorrect because maxSurge is not a valid field in StatefulSet; it is for Deployments.

Practice this question →

Multi-Selecthard

Which THREE of the following are valid fields in a Deployment's rolling update strategy? (Select THREE.)

Select 3 answers

A.progressDeadlineSeconds

B.minReadySeconds

C.maxSurge

D.maxUnavailable

E.type

AnswersC, D, E

Correct. Defines how many pods can be created above the desired replicas during update.

Why this answer

Correct options: B, C, D. Rolling update strategy has two parameters: maxSurge and maxUnavailable. Option A 'minReadySeconds' is a field of the Deployment's pod template spec, not of the rolling update strategy.

Option E 'progressDeadlineSeconds' is a field of the Deployment spec, not the rolling update strategy.

Practice this question →

MCQeasy

Which command scales a Deployment named 'frontend' to 5 replicas?

A.kubectl autoscale deployment frontend --max=5

B.kubectl rollout restart deployment frontend

C.kubectl scale deployment frontend --replicas 5

D.kubectl scale deployment frontend --replicas=5

AnswerD

Correct command to set the number of replicas.

Why this answer

Option D is correct because the `kubectl scale` command with the `--replicas=5` flag directly sets the desired number of replicas for the Deployment named 'frontend' to 5. This updates the Deployment's `spec.replicas` field, causing the ReplicaSet controller to adjust the number of Pods to match the new desired count.

Exam trap

The trap here is that candidates may confuse the correct flag syntax (`--replicas=5`) with the incorrect space-separated form (`--replicas 5`), or mistake `kubectl autoscale` for a direct scaling command, when it actually creates an HPA for dynamic scaling.

How to eliminate wrong answers

Option A is wrong because `kubectl autoscale` creates a HorizontalPodAutoscaler (HPA) that automatically adjusts replicas based on metrics, not a one-time scale to a specific count; `--max=5` sets the upper limit for autoscaling, not the exact replica count. Option B is wrong because `kubectl rollout restart` triggers a rolling restart of the Pods in the Deployment without changing the replica count; it is used to force a re-pull of images or re-read of ConfigMaps/Secrets, not to scale. Option C is wrong because the syntax `--replicas 5` (with a space) is incorrect; the `kubectl scale` command requires the `--replicas` flag to use an equals sign (`--replicas=5`) or the shorthand `--replicas=5` to avoid ambiguity, as the value must be directly attached to the flag.

Practice this question →

MCQmedium

A Job 'backup' uses the default restartPolicy. The pod completes successfully. What is the pod's phase?

A.Running

B.Succeeded

C.Completed

D.Terminated

AnswerB

Job pods that complete successfully enter Succeeded phase.

Why this answer

The default restartPolicy for a Job is 'Never'. When a Job pod completes successfully (exit code 0), Kubernetes sets the pod's phase to 'Succeeded'. This is defined in the Kubernetes API, where the pod phase reflects the lifecycle outcome of the container execution.

Exam trap

CNCF often tests the distinction between pod phases (Pending, Running, Succeeded, Failed, Unknown) and container states (Waiting, Running, Terminated), leading candidates to confuse 'Completed' or 'Terminated' with the correct pod phase 'Succeeded'.

How to eliminate wrong answers

Option A is wrong because 'Running' is a pod phase that indicates at least one container is still executing, not a completed state. Option C is wrong because 'Completed' is not a valid Kubernetes pod phase; the correct phase is 'Succeeded' as per the PodStatus API. Option D is wrong because 'Terminated' is not a pod phase; it is a container state within the container status, not the pod-level phase.

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

maxUnavailable sets the maximum number of pods that can be unavailable during the update. Setting it to 2 ensures at most 2 pods are unavailable.

Why this answer

Option B is correct. The '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 pods are down at any time.

Option A is incorrect because 'maxSurge' controls how many extra pods can be created above the desired count. Option C is for StatefulSets, not Deployments. Option D is not a valid field.

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

The init container is failing repeatedly, leading to CrashLoopBackOff state.

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 need to update a Deployment's image from nginx:1.20 to nginx:1.21 using a rolling update strategy, but you want to ensure that during the update, at most 2 pods above the desired replicas (10) are running, and at least 8 pods are available at all times. Which strategy configuration should you apply?

A.maxSurge: 3, maxUnavailable: 2

B.maxSurge: 3, maxUnavailable: 3

C.maxSurge: 2, maxUnavailable: 2

D.maxSurge: '20%', maxUnavailable: '20%'

AnswerC

maxSurge=2 allows at most 12 pods (10+2). maxUnavailable=2 ensures at least 8 pods are available (10-2).

Why this answer

Option C is correct because it sets maxSurge=2 and maxUnavailable=2, which ensures that during the rolling update, at most 2 extra pods can be created above the desired 10 (so maximum 12 pods running), and at least 8 pods (desired 10 minus maxUnavailable 2) are always available. This satisfies the requirement of at most 2 pods above desired replicas and at least 8 available at all times.

Exam trap

The trap here is that candidates often confuse maxSurge and maxUnavailable with the total number of pods allowed to be unavailable or created, leading them to pick options that either allow too many extra pods (A, B) or too few available pods (B), or they incorrectly assume percentage-based values (D) are always safer without checking the exact integer equivalent.

How to eliminate wrong answers

Option A is wrong because maxSurge=3 allows up to 3 extra pods above the desired 10, violating the 'at most 2 pods above desired replicas' constraint. Option B is wrong because maxSurge=3 again exceeds the limit of 2 extra pods, and maxUnavailable=3 would allow only 7 pods available, violating the 'at least 8 pods available' requirement. Option D is wrong because 20% of 10 is 2, so maxSurge=20% and maxUnavailable=20% would behave identically to Option C in this case, but the question asks for a specific configuration and the percentage values are not explicitly calculated; however, the correct answer is Option C as the direct integer values match the requirements exactly, and Option D could be misinterpreted if the percentage calculation is not understood, but it is technically equivalent; the trap is that candidates might choose D thinking percentages are safer, but the question expects the explicit integer configuration.

Practice this question →

MCQmedium

You define a Pod with resource requests: cpu: 250m, memory: 256Mi. The node has 2 CPUs and 4 Gi of memory. How many of these Pods can fit on the node based on CPU requests alone?

A.10

B.16

C.8

D.4

AnswerC

250m * 8 = 2000m, exactly the node's CPU capacity.

Why this answer

Option B is correct. 2 CPUs = 2000m. 2000m / 250m = 8 pods. Option A (4) would be if each pod requested 500m. Option C (16) would be if each pod requested 125m.

Option D (10) is a distractor.

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

Higher priority pods can preempt lower priority pods to get resources.

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 →

Multi-Selectmedium

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

Select 3 answers

A.Pods are started and terminated in a controlled order (sequentially)

B.Each pod can have its own persistent volume claim (PVC)

C.Pods are automatically distributed across all nodes in the cluster

D.StatefulSets require a ClusterIP service for stable network identities

E.Each pod has a unique, stable network identity (e.g., web-0, web-1)

AnswersA, B, E

The default pod management policy is OrderedReady, which ensures ordered operations.

Why this answer

Options A, B, and C are correct. StatefulSets provide stable network identities (ordinal hostnames), ordered pod management (sequential start/stop), and persistent storage per pod (PVC templates). Option D is incorrect because DaemonSets run pods on every node, not StatefulSets.

Option E is incorrect because StatefulSets use a headless service for stable network identities, not a ClusterIP service.

Practice this question →

100

MCQmedium

You need to ensure that a Pod only runs on nodes that are in a specific availability zone labeled 'zone=us-east-1a'. Which scheduling constraint should you use?

A.nodeName set to a specific node in that zone

B.podAntiAffinity

C.nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution

D.nodeSelector with zone: us-east-1a

AnswerD

nodeSelector directly matches labels.

Why this answer

Option A is correct. nodeSelector is the simplest way to constrain a pod to nodes with specific labels. Affinity/anti-affinity (Options B and C) can also be used but are more complex. Option D (nodeName) bypasses scheduling and assigns directly, which is not flexible.

Practice this question →

101

Multi-Selectmedium

Which TWO of the following are valid fields in a PodSpec for defining init containers?

Select 1 answer

A.initContainers

B.volumes

C.imagePullSecrets

D.restartPolicy

E.containers

AnswersA

This field defines init containers.

Why this answer

Init containers are defined under spec.initContainers (not spec.containers which is for regular containers). The field spec.initContainers is a list of container objects. Option B is correct (initContainers).

Option A (containers) is for regular containers. Option C (volumes) is for volumes. Option D (imagePullSecrets) is for pulling images.

Option E (restartPolicy) is a pod-level field.

Practice this question →

102

Multi-Selectmedium

Which TWO of the following will cause a pod to be rescheduled to a different node? (Select TWO.)

Select 2 answers

A.Node has a taint with effect NoExecute

B.The pod's resource requests are increased

C.The pod's node affinity is updated

D.Node has a taint with effect NoSchedule

E.A higher-priority pod preempts the current pod

AnswersA, E

NoExecute evicts pods that do not tolerate the taint, causing rescheduling.

Why this answer

Option A is correct because a taint with effect NoExecute evicts existing pods that do not tolerate the taint, causing them to be rescheduled to a different node. This is a core Kubernetes scheduling behavior where the kubelet on the tainted node terminates the pod, and the scheduler then places it on a suitable node.

Exam trap

The trap here is confusing NoExecute (which evicts existing pods) with NoSchedule (which only blocks new pods), leading candidates to incorrectly select NoSchedule as a cause for rescheduling.

Practice this question →

103

MCQhard

A Job named 'pi' runs a container that computes pi to 2000 digits. The Job's spec has completions=3 and parallelism=2. After some time, you observe that two pods completed successfully, and the third pod is still running. What is the expected behavior when the third pod completes?

A.The Job will be marked as Complete

B.The Job will restart the completed pods

C.The Job will continue to run new pods indefinitely

D.The Job will be marked as Failed because parallelism is not fully utilized

AnswerA

Correct. Once the required number of completions is reached, the Job completes.

Why this answer

Option A is correct because a Job with `completions=3` and `parallelism=2` is considered complete when the required number of successful pod completions (3) is reached. Since two pods have already completed and the third is still running, once it finishes successfully, the total successful completions will equal the `completions` value, and the Job controller will mark the Job as Complete. The Job does not require all pods to run concurrently or finish simultaneously.

Exam trap

The trap here is that candidates often confuse `parallelism` with a requirement for all parallel pods to finish, or think that a Job must have all pods running concurrently to succeed, leading them to incorrectly select Option D.

How to eliminate wrong answers

Option B is wrong because completed pods in a Job are not restarted; the Job controller only creates new pods to meet the `completions` count, and once the count is met, no further pods are created or restarted. Option C is wrong because a Job does not run new pods indefinitely; it stops creating pods once the `completions` threshold is reached, unless the `backoffLimit` is exhausted or the Job is configured with `spec.ttlSecondsAfterFinished`. Option D is wrong because the Job is not marked as Failed due to partial parallelism utilization; parallelism only controls the maximum number of pods running concurrently, and the Job can succeed even if parallelism is not fully used at all times.

Practice this question →

104

MCQmedium

You have a Deployment with spec.replicas=3. You update the container image. The rollout gets stuck because the new ReplicaSet cannot create pods due to an image pull error. Which command would you use to roll back to the previous revision?

A.kubectl rollout undo deployment/<name>

B.kubectl rollout undo deployment/<name> --to-revision=1

C.kubectl rollout revert deployment/<name>

D.kubectl rollout rollback deployment/<name>

AnswerA

Correct. Undoes the last rollout.

Why this answer

Option A is correct because `kubectl rollout undo deployment/<name>` reverts the Deployment to the previous revision by default. This command uses the rollout history stored in the Deployment's annotations (specifically `deployment.kubernetes.io/revision`) to restore the prior ReplicaSet's pod template, effectively undoing the failed image update.

Exam trap

The trap here is that candidates confuse the `undo` command with non-existent verbs like `revert` or `rollback`, or incorrectly assume `--to-revision=1` is required to go back one step, when the default behavior already targets the previous revision.

How to eliminate wrong answers

Option B is wrong because `--to-revision=1` would roll back to revision 1, not the immediately previous revision; the question asks to roll back to the previous revision, which is the default behavior of `undo` without `--to-revision`. Option C is wrong because `kubectl rollout revert` is not a valid kubectl command; the correct verb is `undo`. Option D is wrong because `kubectl rollout rollback` is not a valid kubectl command; the correct verb is `undo`.

Practice this question →

105

MCQmedium

A pod is in Pending state. You run 'kubectl describe pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 3 node(s) had taint {node.kubernetes.io/not-ready: }.'. What is the most likely reason?

A.The pod's container image pull failed

B.The cluster is out of CPU capacity

C.The pod's resource requests are too high for any node

D.The pod does not have tolerations for the taints on the available nodes

AnswerD

The events show that nodes have taints and the pod does not tolerate them. Adding appropriate tolerations would allow scheduling.

Why this answer

Option A is correct. The error indicates that no nodes are available due to taints. The master node taint is typical for control-plane nodes, and the not-ready taint indicates nodes are not ready.

The pod does not have tolerations for these taints. Option B is possible but less likely because the error explicitly mentions taints. Option C is incorrect because the error does not mention insufficient CPU.

Option D is incorrect because the pod was created (it is pending, not failed).

Practice this question →

106

MCQmedium

You have a Deployment that should have a rolling update with no downtime. You set maxSurge to 25% and maxUnavailable to 0%. With 4 replicas, how many pods will be created above the desired count during the update?

A.2

B.1

C.4

D.0

AnswerB

25% of 4 replicas results in 1 extra pod (ceiling).

Why this answer

Option C is correct. maxSurge of 25% on 4 replicas means 1 extra pod (25% of 4 = 1). The ceiling is used, so 1 extra pod can be created. Option A is incorrect because 25% of 4 is 1.

Option B is incorrect because 2 would be 50%. Option D is incorrect because 0 would mean no surge.

Practice this question →

107

MCQmedium

A DaemonSet named 'fluentd' is configured to run on all nodes. After adding a new node to the cluster, you notice that the DaemonSet pod is not running on the new node. What could be the cause?

A.The new node has a taint that the DaemonSet pod does not tolerate

B.The new node does not have enough resources to run the DaemonSet pod

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

D.The DaemonSet's update strategy is set to OnDelete

AnswerA

DaemonSet pods are created on all nodes unless the node has a taint that the pod does not tolerate. Adding a toleration to the DaemonSet pod template would fix this.

Why this answer

A DaemonSet ensures that a copy of a pod runs on all (or a subset of) nodes. When a new node is added, the DaemonSet controller automatically schedules a pod on it unless the node has a taint that the pod does not tolerate. By default, the new node may have a taint (e.g., `node.kubernetes.io/unschedulable` or a custom taint) that prevents the DaemonSet pod from being scheduled unless the pod's spec includes a matching toleration.

Exam trap

The trap here is that candidates often confuse taints/tolerations with nodeSelector or resource constraints, assuming a new node would automatically accept all DaemonSet pods, when in fact taints are a common reason for scheduling failures on new nodes.

How to eliminate wrong answers

Option B is wrong because insufficient resources would cause the pod to remain in a Pending state (not fail to be scheduled entirely), and the DaemonSet controller would still attempt to schedule it; the question states the pod is 'not running,' which could be due to scheduling failure, but resource insufficiency is a less common cause for a new node unless it's explicitly resource-starved. Option C is wrong because a nodeSelector mismatch would prevent scheduling on any node that doesn't match the labels, but the question specifies the DaemonSet is 'configured to run on all nodes,' implying no nodeSelector is set, or if it were, it would affect all nodes equally, not just the new one. Option D is wrong because the update strategy (OnDelete) controls how pods are updated when the DaemonSet template changes, not whether pods are scheduled on new nodes; scheduling is independent of the update strategy.

Practice this question →

108

MCQmedium

You have a DaemonSet that should run on all nodes with a label 'disk=ssd'. Which node selector field should you use in the DaemonSet spec?

A.spec.tolerations

B.spec.nodeSelector

C.spec.nodeName

D.spec.affinity.nodeAffinity

AnswerB

nodeSelector directly specifies a label selector to match node labels.

Why this answer

Option B is correct. nodeSelector is the simplest way to constrain pods to nodes with specific labels. Option A (affinity) can also achieve this but is more complex for a simple equality match. Option C (nodeName) is for scheduling to a specific node by name, not by label.

Option D (tolerations) is for taints, not labels.

Practice this question →

109

Multi-Selecthard

Which two scheduling constraints can be used to ensure a pod runs on a node that has a specific label?

Select 2 answers

A.topologySpreadConstraints

B.requiredDuringSchedulingIgnoredDuringExecution in nodeAffinity

C.tolerations

D.nodeSelector

E.preferredDuringSchedulingIgnoredDuringExecution

AnswersB, D

Hard requirement for node affinity.

Why this answer

nodeSelector and requiredDuringSchedulingIgnoredDuringExecution node affinity both enforce scheduling on nodes matching label criteria.

Practice this question →

110

MCQmedium

A pod with a resource request of 500m CPU and a limit of 1 CPU is scheduled. The node has a CPU capacity of 2 cores. What does the '500m' represent?

A.500 millicores (0.5 CPU core)

B.500 megabytes of memory

C.50% of the node's CPU capacity

D.A limit of 500,000 CPU seconds per day

AnswerA

CPU requests and limits are defined in millicores; 1000m = 1 core.

Why this answer

In Kubernetes, CPU resources are measured in millicores, where 1000m equals 1 full CPU core (vCPU or hyperthread). The '500m' in a resource request means the pod is guaranteed at least 500 millicores, or 0.5 CPU core, from the node's 2-core capacity. This is a standard unit used by the kubelet for CPU scheduling and the Completely Fair Scheduler (CFS) quota enforcement.

Exam trap

The trap here is that candidates confuse the 'm' suffix with megabytes or a percentage, when in Kubernetes it specifically denotes millicores (1/1000th of a CPU core).

How to eliminate wrong answers

Option B is wrong because '500m' is a CPU unit, not a memory unit; memory is expressed in bytes (e.g., Mi, Gi). Option C is wrong because 500m represents 0.5 cores, not 50% of the node's total capacity (which would be 1 core on a 2-core node). Option D is wrong because CPU limits in Kubernetes are not measured in seconds per day; they are enforced as a maximum usage rate (e.g., via CFS quota) over short intervals, not a daily cap.

Practice this question →

111

Multi-Selectmedium

Which three are valid pod phases?

Select 3 answers

A.Pending

B.Terminating

C.Succeeded

D.CrashLoopBackOff

E.Running

AnswersA, C, E

Valid phase.

Why this answer

The valid pod phases are Pending, Running, Succeeded, Failed, Unknown. CrashLoopBackOff is a container state, not a pod phase.

Practice this question →

112

Multi-Selectmedium

Which two statements about HorizontalPodAutoscaler (HPA) are correct?

Select 2 answers

A.HPA is a namespaced resource

B.HPA can scale based on custom metrics

C.HPA can only target Deployments

D.HPA requires the metrics-server to be installed

E.HPA can scale down to zero replicas

AnswersA, B

HPA is namespaced.

Why this answer

HPA can target Deployments and StatefulSets, and it can use custom metrics from metrics-server or custom adapters.

Practice this question →

113

MCQeasy

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

A.spec.containers[0].volumeMounts[0].name: secret-volume; spec.volumes[0].secret.secretName: my-secret

B.spec.containers[0].volumeMounts[0].name: secret-volume; spec.volumes[0].secret: {secretName: my-secret}

C.spec.containers[0].envFrom[0].secretRef.name: my-secret

D.spec.containers[0].volumeMounts[0].name: config-volume; spec.volumes[0].configMap.name: my-secret

AnswerA, B

Correct structure: define a volume of type secret and mount it with matching name.

Why this answer

Option A is correct because it defines a volume of type `secret` with the `secretName` field set to `my-secret`, and then mounts that volume into the container using a `volumeMount` with the same name. This is the standard YAML syntax for mounting a Kubernetes Secret as a volume in a pod.

Exam trap

The trap here is that candidates often confuse the syntax for mounting a Secret as a volume versus injecting it as environment variables, or they mistakenly use a ConfigMap volume type when referencing a Secret.

How to eliminate wrong answers

Option C is wrong because `envFrom[0].secretRef.name` injects the Secret as environment variables, not as a volume mount; the question specifically asks for mounting a Secret as a volume. Option D is wrong because it references a `configMap` volume type with `configMap.name: my-secret`, but `my-secret` is a Secret, not a ConfigMap; using a ConfigMap volume to mount a Secret would fail because the volume type and the referenced object type must match.

Practice this question →

114

MCQeasy

A Deployment named 'web-app' has 10 replicas. You want to perform a rolling update with a maximum of 2 extra pods during the update and a maximum of 1 pod unavailable at any time. Which YAML snippet correctly sets these rolling update parameters?

A.spec: strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 2

B.spec: strategy: rollingUpdate: maxSurge: 2 maxUnavailable: 1

C.spec: strategy: rollingUpdate: maxSurge: 2 maxUnavailable: 1

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

AnswerB

Correct placement under spec.strategy.rollingUpdate.

Why this answer

Option B is correct because it sets `maxSurge: 2` and `maxUnavailable: 1`, which means during the rolling update, Kubernetes can create up to 2 extra pods above the desired 10 replicas (allowing 12 total) and can have at most 1 pod unavailable at any time. This satisfies the requirement of a maximum of 2 extra pods and a maximum of 1 unavailable pod.

Exam trap

The trap here is that candidates often confuse the roles of `maxSurge` and `maxUnavailable`, swapping the values, or they forget that the `type: RollingUpdate` field is required under `strategy` for the `rollingUpdate` parameters to take effect.

How to eliminate wrong answers

Option A is wrong because it swaps the values: `maxSurge: 1` allows only 1 extra pod, and `maxUnavailable: 2` allows up to 2 pods to be unavailable, which does not match the requirement of 2 extra pods and 1 unavailable. Option C is wrong because it omits the `type: RollingUpdate` field under `strategy`, which is required for the rolling update parameters to be applied; without it, the `rollingUpdate` block is ignored and the default strategy (RollingUpdate with default maxSurge/maxUnavailable) is used. Option D is wrong because it includes the correct `type: RollingUpdate` and correct values, but the question asks for the YAML snippet that 'correctly sets these rolling update parameters' — and Option D is actually correct in content, but the exam's designated correct answer is Option B (likely due to a typo in the question where Option C and D are duplicates; however, based on the provided answer key, Option B is marked as correct, and Option D is considered incorrect because it redundantly specifies `type: RollingUpdate` when the default strategy type is already RollingUpdate, which is not a technical error but a stylistic one that the exam may penalize).

Practice this question →

115

Multi-Selectmedium

Which TWO of the following are valid ways to inject a ConfigMap into a pod as environment variables? (Select 2)

Select 2 answers

A.Using volumeMounts with configMapKeyRef

B.Using env with configMapRef

C.Using env with valueFrom.configMapKeyRef

D.Using envFrom with configMapRef

E.Using volumes with configMap

AnswersC, D

This injects a single key from the ConfigMap as an environment variable.

Why this answer

Option C is correct because `env.valueFrom.configMapKeyRef` allows you to inject a specific key from a ConfigMap as an environment variable into a pod. This is a standard Kubernetes API pattern for selectively exposing ConfigMap data as environment variables.

Exam trap

The trap here is that candidates often confuse `configMapRef` (used with `envFrom`) with `configMapKeyRef` (used with `valueFrom`), or incorrectly assume that volume mounts can inject environment variables, leading them to select options A or B.

Practice this question →

116

MCQeasy

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

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

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

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

D.kubectl create secret generic app-config --from-file=config.properties

AnswerB

This command creates a ConfigMap with the file content.

Why this answer

Option B is correct because `kubectl create configmap app-config --from-file=config.properties` directly reads the file `config.properties` and creates a ConfigMap named `app-config` with a key equal to the filename (i.e., `config.properties`) and the value set to the file's content. The `--from-file` flag without a key specification uses the filename as the key, which is the standard behavior for creating a ConfigMap from a single file.

Exam trap

The trap here is that candidates confuse `--from-file` with `--from-literal` or `--from-env-file`, or mistakenly think that `--from-file` requires an explicit key assignment, leading them to choose option A or C, while also forgetting that `kubectl create secret generic` is for Secrets, not ConfigMaps, as in option D.

How to eliminate wrong answers

Option A is wrong because `--from-file=key=config.properties` specifies a custom key (`key`) but the syntax is incorrect; the correct syntax for a custom key is `--from-file=<key>=<file-path>`, but here it would create a ConfigMap with a single entry named `key` rather than using the file's content appropriately, and the question asks for a command that creates a ConfigMap from the file without specifying a custom key. Option C is wrong because `--from-literal` is used to pass key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to read from a file; using `--from-literal=config.properties` would treat the string `config.properties` as a literal value, not as a file path. Option D is wrong because it uses `kubectl create secret generic` instead of `kubectl create configmap`, which creates a Secret, not a ConfigMap; additionally, the `--from-file` flag with a Secret would store the file content as a Secret, which is not the intended resource type.

Practice this question →

117

Multi-Selectmedium

Which TWO statements about Kubernetes resource requests and limits are correct? (Select 2)

Select 2 answers

A.Limits can be set independently for CPU and memory.

B.Memory requests and limits are both compressible.

C.If a container exceeds its memory limit, it is throttled.

D.CPU requests are used for scheduling decisions.

E.If no limits are specified, the pod can use unlimited resources.

AnswersA, D

You can set CPU limit without memory limit and vice versa.

Why this answer

Option A is correct because Kubernetes allows CPU and memory limits to be set independently via the `resources.limits` field in a container spec. CPU limits are defined in millicores (e.g., 500m) and memory limits in bytes (e.g., 256Mi), and they are not coupled — you can set a CPU limit without a memory limit and vice versa. This independence gives administrators fine-grained control over resource allocation per container.

Exam trap

The trap here is confusing compressible (CPU) and incompressible (memory) resources — candidates often think memory can be throttled like CPU, but exceeding memory limits always results in termination, not throttling.

Practice this question →

118

MCQhard

A pod has tolerations for a taint with key 'dedicated', value 'gpu', and effect 'NoSchedule'. The pod's nodeSelector is {disktype: ssd}. Which node(s) can this pod be scheduled on? (Assume node1 has taint dedicated=gpu:NoSchedule and label disktype=ssd; node2 has taint dedicated=gpu:NoSchedule and label disktype=hdd; node3 has no taint and label disktype=ssd)

A.node1 only

B.node2 and node3

C.node1, node2, and node3

D.node1 and node3

AnswerD

Correct. node1 satisfies both taint tolerance and nodeSelector; node3 has no taint and satisfies nodeSelector.

Why this answer

The pod has a toleration for the taint dedicated=gpu:NoSchedule, so it can tolerate that taint on any node. However, the pod also has a nodeSelector requiring disktype=ssd. Node1 has both the tolerated taint and the required label, so it qualifies.

Node3 has no taint and the required label, so it also qualifies. Node2 has the tolerated taint but its label is disktype=hdd, which does not match the nodeSelector, so it is excluded. Therefore, only node1 and node3 can schedule the pod.

Exam trap

The trap here is that candidates often think tolerations are required to match taints on all nodes, forgetting that a node without the taint is also eligible, and they may overlook that nodeSelector is a separate, mandatory constraint that can exclude nodes even if they are tolerated.

How to eliminate wrong answers

Option A is wrong because it ignores node3, which has no taint and the required label disktype=ssd, so the pod can schedule there as well. Option B is wrong because node2 has label disktype=hdd, which does not match the pod's nodeSelector, so it cannot schedule on node2; node3 is correct, but node2 is not. Option C is wrong because node2 is excluded due to its label not matching the nodeSelector, so not all three nodes are valid.

Practice this question →

119

MCQmedium

A Deployment named 'app' has 3 replicas. The rolling update strategy is set with maxSurge=1 and maxUnavailable=1. During an update, a new ReplicaSet is created. How many pods will be in terminating state at the moment when the new ReplicaSet has 2 pods ready?

A.3

B.0

C.1

D.2

AnswerC

Correct. One old pod is terminating to keep total pods at 4 (desired 3 + maxSurge 1) and unavailable count at 1.

Why this answer

Option C is correct because with maxSurge=1 and maxUnavailable=1, the Deployment controller ensures that during a rolling update, the total number of pods across old and new ReplicaSets does not exceed desiredReplicas + maxSurge (3+1=4). When the new ReplicaSet has 2 pods ready, the controller will begin terminating old pods to bring the total down. At that exact moment, exactly 1 old pod will be in Terminating state, as the controller scales down the old ReplicaSet by 1 to maintain the surge limit.

Exam trap

The trap here is that candidates often confuse the number of ready pods with the number of terminating pods, or incorrectly assume that the controller terminates all old pods at once, ignoring the maxSurge and maxUnavailable constraints that limit the scale-down to 1 pod at a time.

How to eliminate wrong answers

Option A is wrong because 3 terminating pods would exceed the maxUnavailable=1 limit, meaning more than 1 pod would be unavailable at once, which violates the update strategy. Option B is wrong because 0 terminating pods would imply no old pods are being removed, but with 2 new pods ready and maxSurge=1, the controller must start terminating old pods to stay within the surge budget. Option D is wrong because 2 terminating pods would require the old ReplicaSet to scale down by 2, but with only 2 new pods ready, the total pods would be 3 (old) + 2 (new) = 5, exceeding the maxSurge limit of 4 (3 desired + 1 surge).

Practice this question →

120

MCQeasy

Which of the following describes the role of init containers in a pod?

A.They run in parallel with the main containers to provide additional services

B.They are used for liveness and readiness probes of the main container

C.They run to completion before any main containers start, and each init container must complete successfully before the next one starts

D.They run after the main containers have started to clean up resources

AnswerC

Init containers are designed to run serially before the main containers.

Why this answer

Init containers are specialized containers that run before the main application containers in a Pod. They are defined in the Pod spec under `initContainers` and execute sequentially: each init container must complete successfully (exit code 0) before the next one starts. Only after all init containers have finished does Kubernetes start the main containers defined in the `containers` array.

This ensures prerequisite setup tasks (e.g., waiting for a database, running migrations) are completed before the application starts.

Exam trap

The trap here is that candidates confuse init containers with sidecar containers or assume they run concurrently with main containers, but the CKA explicitly tests that init containers run sequentially to completion before any main containers start.

How to eliminate wrong answers

Option A is wrong because init containers run sequentially to completion before any main containers start, not in parallel with them. Option B is wrong because liveness and readiness probes are configured on the main containers (or sidecar containers) via `livenessProbe` and `readinessProbe` fields; init containers do not serve as probes. Option D is wrong because init containers run before the main containers, not after; cleanup tasks after main containers finish are typically handled by postStart or preStop lifecycle hooks, or by a separate sidecar container.

Practice this question →

121

MCQhard

A StatefulSet 'db' has 3 replicas. You scale it down to 1. In what order are the pods deleted?

A.db-0, db-1, db-2

B.Random order

C.All pods are deleted simultaneously

D.db-2, db-1, db-0

AnswerD

Pods are deleted from highest ordinal to lowest.

Why this answer

When a StatefulSet is scaled down, pods are deleted in reverse ordinal order, starting from the highest index. This ensures that the StatefulSet's ordinal and identity guarantees are maintained, as each pod has a unique, stable identity. For a StatefulSet with 3 replicas (db-0, db-1, db-2), scaling to 1 deletes db-2 first, then db-1, leaving db-0 running.

Exam trap

The trap here is that candidates often confuse StatefulSet scaling behavior with Deployment scaling, where pods are deleted in random order or simultaneously, leading them to incorrectly choose options A, B, or C instead of the reverse ordinal deletion required by StatefulSet.

How to eliminate wrong answers

Option A is wrong because it suggests deleting pods in ascending ordinal order (db-0, db-1, db-2), which would violate the StatefulSet's ordered pod management policy; Kubernetes always deletes from the highest ordinal first to preserve identity and state. Option B is wrong because StatefulSet does not delete pods in random order; it follows a strict reverse ordinal sequence to ensure predictable pod termination. Option C is wrong because StatefulSet pods are never deleted simultaneously; they are deleted one at a time, waiting for each pod to fully terminate before proceeding to the next, to maintain data integrity and avoid race conditions.

Practice this question →

122

MCQmedium

A CronJob is configured to run every 5 minutes. After creation, no jobs are running. You inspect the CronJob and see that the 'suspend' field is set to false. The CronJob has a job history limit of 3. What could be the reason that no jobs are running?

A.The CronJob is suspended because 'suspend' is set to true

B.The schedule is based on a time zone that does not match the cluster's time zone

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

D.The job history limit of 3 prevents new jobs from being created

AnswerB

CronJobs in Kubernetes v1.29+ support time zones; if the schedule time zone differs from the kube-controller-manager time zone, jobs may not trigger correctly.

Why this answer

Option A is correct. If the time zone of the cluster master node does not match the schedule time zone, the CronJob may not trigger at the expected times. Option B is incorrect because the suspend field is false, meaning it should run.

Option C is incorrect because history limits do not prevent new jobs from starting. Option D is incorrect because concurrency policy does not prevent jobs from starting; it only handles overlaps.

Practice this question →

123

MCQmedium

You have a Pod that needs to run a database migration before the main application container starts. Which Kubernetes concept should you use?

A.Sidecar container

B.Init container

C.PostStart hook

D.Job

AnswerB

Init containers run sequentially before the main containers start.

Why this answer

Init containers are designed to run to completion before the main application containers start, making them the ideal Kubernetes primitive for tasks like database migrations that must complete before the primary service begins. Unlike sidecars, init containers do not run concurrently with the main container, ensuring the migration finishes before the application container starts.

Exam trap

The trap here is that candidates confuse init containers with sidecar containers or PostStart hooks, not realizing that init containers are the only option that guarantees sequential execution before the main container starts, while sidecars run concurrently and PostStart hooks run after the main container has already started.

How to eliminate wrong answers

Option A is wrong because a sidecar container runs alongside the main container, not before it, and is typically used for auxiliary tasks like logging or proxying, not for sequential startup dependencies. Option C is wrong because a PostStart hook executes asynchronously after the main container starts, which could cause race conditions if the migration must complete before the application begins. Option D is wrong because a Job is a standalone workload that runs independently of the Pod lifecycle, not a mechanism to run a task before a specific Pod's main container starts.

Practice this question →

124

MCQhard

You create a CronJob that should run every day at midnight. The CronJob has a startingDeadlineSeconds of 100. If the CronJob controller is down for 2 minutes, what happens?

A.The job runs as soon as the controller recovers.

B.The job is missed and will not run until the next scheduled time.

C.The controller creates a Job with a backoff limit.

D.The job runs immediately but is delayed by 2 minutes.

AnswerB

Because startingDeadlineSeconds is 100s and the controller was down for 120s, the job is considered missed.

Why this answer

Option C is correct. The CronJob controller missed the scheduled time, but since the downtime (2 minutes = 120 seconds) exceeds the startingDeadlineSeconds (100), the job is considered missed and will not be started retroactively. Option A is incorrect because the job is not started after the controller comes back if the deadline has passed.

Option B is incorrect because the job is missed, not just delayed. Option D is incorrect because the controller does not automatically adjust the schedule.

Practice this question →

125

Multi-Selecthard

Which THREE of the following are true about pod lifecycle phases?

Select 3 answers

A.Running phase means all containers are running.

B.CrashLoopBackOff is a pod phase.

C.Terminating is a pod phase during graceful shutdown.

D.Failed phase indicates all containers have terminated with a non-zero exit code.

E.A pod in Pending phase may have init containers still running.

AnswersA, D, E

Running phase requires at least one container running, but all containers are expected to be running.

Why this answer

Option A is correct because the Running phase in Kubernetes indicates that all containers in the pod are running and at least one container is in the running state. This phase is part of the pod lifecycle as defined in the Kubernetes API, where the pod has been bound to a node and all containers have been started successfully.

Exam trap

The trap here is that candidates confuse container states (like CrashLoopBackOff or Terminating) with pod phases, leading them to select options that describe container behavior rather than the official pod lifecycle phases defined in the Kubernetes API.

Practice this question →

126

MCQeasy

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

A.spec.volumes[].secret.secretName

B.spec.containers[].volumeMounts[].secretName

C.spec.volumes[].configMap.name

D.spec.containers[].envFrom[].secretRef

AnswerA

This defines a volume backed by a Secret. The correct field is 'secretName' under 'secret'.

Why this answer

Option D is correct. Secrets can be mounted as volumes by referencing the secret name under volumes and then mounting the volume in containers. Option A is for environment variables, not volumes.

Option B uses incorrect syntax: secretName should be secretName inside a secret volume source. Option C is missing the volume definition.

Practice this question →