Knowledge + Practice

CCNA Workloads and Scheduling Questions

39 questions · Workloads and Scheduling · All types, answers revealed

Practice these questions Domain overview All questions

1

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 →

2

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 →

3

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 →

4

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 →

5

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

This is incorrect. While it is possible to allow concurrent executions by setting concurrencyPolicy to 'Allow', the default is 'Forbid', so concurrent runs are not the default behavior.

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 →

6

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 →

7

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 →

8

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 →

9

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 →

10

MCQeasy

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

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

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

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

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

AnswerD

Correct.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

11

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 →

12

Multi-Selecthard

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

Select 3 answers

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

B.HPA supports in-place pod resizing.

C.HPA cannot scale based on memory utilization.

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

E.HPA can scale Deployments and StatefulSets.

AnswersA, D, E

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

Why this answer

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

Exam trap

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

Practice this question →

13

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 →

14

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 →

15

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 →

16

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 →

17

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 →

18

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 →

19

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 →

20

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 →

21

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 →

22

MCQmedium

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

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

B.Delete the namespace and redeploy all workloads

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

D.Increase the CPU request for the container

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

23

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 →

24

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 →

25

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 →

26

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 →

27

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 →

28

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 →

29

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 →

30

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 →

31

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 →

32

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 →

33

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 →

34

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 →

35

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 →

36

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

A DaemonSet controller is designed to ensure a pod runs on every eligible node. If a new node joins the cluster and has a taint, but the DaemonSet's pod template does not include a corresponding toleration, the Kubernetes scheduler will prevent the DaemonSet pod from being placed on that specific node. This is a common scenario for specialized nodes, such as master nodes, which often have `node-role.kubernetes.io/master:NoSchedule` taints by default, requiring explicit tolerations for DaemonSets like `kube-proxy` or `fluentd` to run on them.

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 →

37

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

In Kubernetes, CPU resources are specified in millicores, where 'm' is the unit suffix. A value of 500m precisely denotes 500 millicores, which is equivalent to 0.5 of a full CPU core. This is the standard, absolute measure for CPU requests and limits, ensuring consistent resource allocation across nodes.

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 →

38

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

The HorizontalPodAutoscaler (HPA) is indeed a namespaced resource in Kubernetes. It lives in a specific namespace, and its name must be unique within that namespace but can be reused across different namespaces. When you create an HPA, it can only target workloads (such as Deployments or StatefulSets) that exist in the same namespace, and it reads the scale subresource of that target through the namespaced API path.

Why this answer

HorizontalPodAutoscaler (HPA) is a namespaced resource in Kubernetes, meaning it exists within a specific namespace and can only target resources (like Deployments or StatefulSets) in that same namespace. This is defined in the Kubernetes API under the `autoscaling/v2` group, where HPA objects are scoped to a namespace, not cluster-wide.

Exam trap

The trap here is that candidates often assume HPA requires the metrics-server for all metric types, but the CKA exam tests the understanding that HPA can use custom and external metrics without the metrics-server, and that scaling to zero is not a native HPA feature.

Practice this question →

39

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

When one old pod is terminating and two new pods are ready, the deployment maintains a balanced state. There would be two old pods still running, plus the two new ready pods, totaling four active pods. This adheres to the `maxSurge=1` rule (4 <= 3 + 1). Crucially, only one pod is unavailable (the terminating old pod), which perfectly satisfies the `maxUnavailable=1` policy, ensuring minimal service disruption during the update.

Why this answer

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 →

Ready to test yourself?

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

Start 20-question session