Courseiva

CCNA Cka Workloads Scheduling Questions

21 of 96 questions · Page 2/2 · Cka Workloads Scheduling topic · Answers revealed

Practice these questionsExam hubAll questions
76
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

With the default podManagementPolicy of OrderedReady, a StatefulSet creates or terminates pod replicas one at a time in strict ordinal order. When scaling up, each pod must become Ready before the next is started; when scaling down or deleting, pods are removed from the highest ordinal back to the lowest, waiting for each deletion to complete. This controlled sequencing lets distributed applications bootstrap or shut down in a predictable, deterministic manner instead of all replicas launching simultaneously.

Why this answer

Option A is correct because a StatefulSet creates and deletes pods in a strict ordinal sequence (0, 1, 2, ... for creation and reverse order for termination), which is essential for stateful workloads that need ordered startup/shutdown. Option B is correct because StatefulSets use volumeClaimTemplates to give each replica its own PersistentVolumeClaim, so every pod gets dedicated storage that persists across rescheduling. Option E is correct because each pod in a StatefulSet receives a stable, unique hostname derived from the StatefulSet name plus ordinal index (e.g., web-0, web-1), backed by a governing headless Service.

Option C is not a StatefulSet characteristic; pod placement across nodes is handled by the scheduler for all workload types, not specifically by StatefulSets. Option D is inaccurate because stable network identities require a headless Service (clusterIP: None), not a regular ClusterIP Service.

Exam trap

The trap here is that candidates often confuse a Headless Service with a regular ClusterIP Service, mistakenly thinking a ClusterIP Service is required for stable network identities, when in fact a Headless Service is mandatory for StatefulSets.

Practice this question →
77
Multi-Selectmedium

Which ONE of the following is a valid field in a PodSpec for defining init containers?

Select 1 answer
A.initContainers
B.volumes
C.imagePullSecrets
D.restartPolicy
E.containers
AnswersA

The initContainers field is a specialized array within the PodSpec used to define one or more initialization containers. These containers run to completion sequentially before any app containers start, making them ideal for running setup scripts, blocking until dependencies are ready, or prepopulating data.

Why this answer

The `initContainers` field in the PodSpec is used to define init containers. The other options are separate PodSpec fields with different purposes: `volumes` for storage, `imagePullSecrets` for pulling private images, `restartPolicy` is a PodSpec field for restart behavior (not for defining init containers), and `containers` is for main application containers, not init containers.

Exam trap

The CKA exam often tests the distinction between `initContainers` and `containers` in the PodSpec, and the trap here is that candidates may mistakenly think `containers` includes init containers or that `volumes` or `imagePullSecrets` are valid fields for defining init containers, when in fact they are separate PodSpec fields with different purposes.

Practice this question →
78
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

A node taint with effect NoExecute triggers immediate eviction of any pod that does not tolerate the taint. The kubelet acts on this taint by evicting the running pod, and since the pod is typically managed by a controller such as a Deployment, its controller recreates the pod on another schedulable node. This eviction and recreation is the mechanism that causes the pod to be rescheduled.

Why this answer

Option A is correct because a taint with effect NoExecute on a node causes the node controller to evict pods that do not tolerate that taint, and the evicted pods are then recreated by their controller (e.g., Deployment/ReplicaSet) and rescheduled onto a different node. Option E is correct because when a higher-priority pod is scheduled and the cluster needs to free resources, the scheduler can preempt (evict) lower-priority pods; those preempted pods are deleted and their controllers recreate them, causing rescheduling to another node. Option B is not correct: increasing a pod's resource requests does not by itself trigger rescheduling — the change is not applied to an existing running pod (pod specs are largely immutable), and even if it were, it would not automatically move the pod to another node.

Option C is not correct: updating node affinity on a running pod is not a supported in-place change and does not cause the kubelet/scheduler to relocate the pod; affinity is evaluated at scheduling time. Option D is not correct: a NoSchedule taint only prevents new pods from being scheduled onto the node; it does not evict or reschedule pods already running there.

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

In Kubernetes, a Job tracks successful pod executions to determine its overall status. Once the number of successfully terminated pods reaches the configured completions value, the Job controller updates the Job's status to Complete. No further pods are scheduled, and the Job transitions to a terminal successful state.

Why this answer

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

This is the standard mechanism for reverting a Deployment to the last successful revision. The undo command instructs the Deployment controller to scale the previous ReplicaSet back up and the current one down, effectively applying the prior pod template. It's the safest, most direct way to reverse an unintentional change when you've verified the previous revision is healthy.

Why this answer

`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 →
81
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 scheduler reports that available nodes are tainted and the pod has no matching tolerations, often as '0/3 nodes available: 3 node(s) had taint {key=value:effect}, that the pod didn't tolerate.' Taints are applied to nodes with `kubectl taint nodes ...`, and only pods whose spec contains a toleration matching the taint's key, value, and effect can be scheduled there. Adding an appropriate toleration will let the scheduler place the pod, so this is the correct diagnosis.

Why this answer

The pod is in Pending state because the scheduler cannot find a node that meets all scheduling constraints. The event explicitly states that 1 node has a taint `node-role.kubernetes.io/master` and 3 nodes have a taint `node.kubernetes.io/not-ready`, and the pod does not have corresponding tolerations. Without tolerations, the pod is not allowed to schedule on any of these nodes, leaving no available node.

Exam trap

The trap here is that candidates may confuse taint/toleration issues with resource insufficiency, but the event message explicitly names taints, not resource shortages, making D the only correct answer based on the provided event details.

How to eliminate wrong answers

Option A is wrong because a container image pull failure would result in an ImagePullBackOff or ErrImagePull event, not a Pending state with taint-related scheduling events. Option B is wrong because the cluster being out of CPU capacity would manifest as a different event, such as 'Insufficient cpu' or 'Insufficient memory', not taint-based messages. Option C is wrong because if resource requests were too high, the event would indicate 'Insufficient cpu' or 'Insufficient memory' per node, not a taint-related message.

Practice this question →
82
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

With a desired replica count of 4 and a maxSurge set to 25%, Kubernetes calculates the maximum number of extra pods allowed during an update as 25% of 4, which equals exactly 1. Even if the percentage calculation yielded a fractional value, Kubernetes always rounds up to the nearest integer to ensure at least one extra pod can be created. Thus, 1 is the correct maximum surge capacity.

Why this answer

With maxSurge=25% and maxUnavailable=0%, the Deployment controller ensures that during a rolling update, the number of pods above the desired count is limited to 25% of the desired replicas, rounded up. For 4 replicas, 25% is 1, so at most 1 extra pod is created above the desired count, ensuring zero downtime by keeping all 4 original pods running until the new pod is ready.

Exam trap

The trap here is that candidates often forget that maxSurge is calculated as a percentage of the desired replicas and rounded up, leading them to incorrectly calculate 25% of 4 as 0 (if they round down) or 2 (if they double the percentage).

How to eliminate wrong answers

Option A is wrong because 2 pods would require maxSurge=50%, not 25%. Option C is wrong because 4 pods would require maxSurge=100%, which is not configured. Option D is wrong because maxSurge=25% with 4 replicas results in 1 extra pod, not 0; setting maxSurge=0% would prevent any extra pods but could cause downtime.

Practice this question →
83
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 →
84
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

The `requiredDuringSchedulingIgnoredDuringExecution` nodeAffinity rule enforces a hard constraint: the scheduler only places the pod on nodes matching the specified label selector, and the pod stays pending otherwise. This satisfies the stem's demand for a scheduling constraint guaranteeing placement on a labelled node, unlike preferred rules which merely bias scoring.

Why this answer

Option B (requiredDuringSchedulingIgnoredDuringExecution in nodeAffinity) is correct because it is a hard node affinity rule that forces the scheduler to place the pod only on nodes matching the specified label selector (e.g., matchExpressions or matchFields), so the pod will not be scheduled unless a node with that label exists. Option D (nodeSelector) is correct because it is the simplest scheduling constraint: the pod spec's nodeSelector field is a map of key-value pairs that must all match the node's labels for the pod to be scheduled there. Option A (topologySpreadConstraints) is not correct here because it controls how pods are distributed across topology domains (such as zones or hostnames) rather than requiring a specific node label.

Option C (tolerations) is not correct because tolerations only allow a pod to be scheduled onto nodes with matching taints; they do not select nodes by label. Option E (preferredDuringSchedulingIgnoredDuringExecution) is not correct because it is a soft affinity preference that the scheduler tries to honor but can ignore, so it cannot ensure the pod runs on a specifically labeled node.

Exam trap

The CKA exam often tests the distinction between hard constraints (`nodeSelector` and `requiredDuringSchedulingIgnoredDuringExecution` in `nodeAffinity`) and soft preferences (`preferredDuringSchedulingIgnoredDuringExecution`). It also tests the difference between node affinity (which matches node labels) and tolerations (which match node taints).

Practice this question →
85
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 →
86
Multi-Selectmedium

Which three are valid pod phases?

Select 3 answers
A.Pending
B.Terminating
C.Succeeded
D.CrashLoopBackOff
E.Running
AnswersA, C, E

Pending is a valid pod phase defined in the Kubernetes API (PodStatus.phase). A pod enters Pending as soon as the API server records it, but it has not yet been fully accepted by a kubelet: this phase covers scheduling onto a node, pulling container images, and waiting for containers to start. If scheduling fails, the pod can stay Pending indefinitely, and the condition PodScheduled=False typically explains why.

Why this answer

Option A (Pending) is a valid pod phase: it means the pod has been accepted by the Kubernetes API server but one or more containers are not yet running, typically because images are still being pulled or scheduling is incomplete. Option C (Succeeded) is valid: it indicates all containers in the pod terminated successfully with exit code 0 and the pod will not be restarted. Option E (Running) is valid: it means the pod has been bound to a node and all containers have been created, with at least one container still running or starting/restarting.

The unmarked options do not belong because Terminating is not a pod phase (it is a deletion state reflected in metadata.deletionTimestamp), and CrashLoopBackOff is a container waiting reason, not a pod phase.

Exam trap

The CKA exam often tests the distinction between pod phases and container states, so the trap here is confusing container-level statuses like CrashLoopBackOff or Terminating with the higher-level pod phase.

Practice this question →
87
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 →
88
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 is the precise way to inject a single key from a ConfigMap into a single environment variable. The env entry defines the environment variable's name, and valueFrom.configMapKeyRef specifies the ConfigMap name and the exact key to pull the value from. It gives you fine-grained control over which keys get exposed and what they are called in the environment, unlike envFrom which blindly imports all keys. You can also add an optional 'optional' field to make the resource not fail if the key is missing.

Why this answer

Option C is correct because the env.valueFrom.configMapKeyRef field lets you map a single specific key from a ConfigMap to one environment variable in the container spec. Option D is correct because envFrom.configMapRef imports all key/value pairs from a referenced ConfigMap as environment variables in the container, which is the bulk-injection mechanism. Option A is incorrect because volumeMounts mounts volumes into the filesystem and does not use configMapKeyRef, which is an env-source field, not a volume field.

Option B is incorrect because the env list does not support a configMapRef field; the correct env-level reference is valueFrom.configMapKeyRef, while configMapRef belongs under envFrom. Option E is incorrect because volumes with configMap project ConfigMap data as files in a mounted volume, not 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 →
89
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 correctly generates a ConfigMap named app-config by reading the contents of the specified local file. By using the --from-file flag, Kubernetes automatically uses the filename config.properties as the key and maps the entire file content as its corresponding value. This is the standard declarative approach for importing file-based configuration into a cluster.

Why this answer

`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. Option A is incorrect because the syntax `--from-file=key=config.properties` creates a ConfigMap with the key "key", not the filename.

Option C is incorrect because `--from-literal` is for literal key-value pairs, not files. Option D is incorrect because `kubectl create secret generic` creates a Secret, not a ConfigMap.

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

Kubernetes allows fine-grained resource configuration, meaning you can define a CPU limit without specifying a memory limit, or vice versa. This independence allows operators to tailor resource constraints to the specific workload profile, such as CPU-bound or memory-bound applications.

Why this answer

Option A is correct because Kubernetes allows CPU and memory limits to be configured separately per container via resources.limits.cpu and resources.limits.memory, so you can cap one resource without capping the other. Option D is correct because the kube-scheduler uses the sum of container CPU requests (resources.requests.cpu) when filtering and scoring nodes, ensuring a node has enough allocatable CPU to satisfy the pod's guaranteed share. Option B is wrong because memory is incompressible: exceeding a memory limit triggers OOMKill rather than throttling, whereas CPU is the compressible resource.

Option C is wrong because exceeding a memory limit causes the container to be terminated with an OOMKilled status, not throttled; CPU limit overuse is what gets throttled via CFS quota. Option E is wrong because a pod without explicit limits is not truly unlimited: it can burst up to node allocatable capacity, but it is still constrained by the node's resources and may be evicted under pressure, and in namespaces with a LimitRange, default limits may be applied automatically.

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

Node1 qualifies because it satisfies the nodeSelector and has a toleration that matches the dedicated taint, so the taint is effectively ignored. Node3 qualifies because it has no taint, meaning no toleration is needed, and it also satisfies the nodeSelector. Node2 is excluded because it fails the nodeSelector label requirement. Thus the correct schedulable set is node1 and node3.

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 →
92
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 →
93
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

This option correctly describes the lifecycle of init containers, which are executed sequentially during Pod startup. Kubernetes guarantees that each init container must exit with a zero status code before the subsequent one begins. The primary application containers will only start initializing once all defined init containers have successfully completed their execution.

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

When scaling down a StatefulSet, Kubernetes terminates pods one at a time in reverse ordinal order, starting from the highest index down to the lowest. In this scenario, the controller first gracefully terminates db-2, waits for its complete removal, and then proceeds to terminate db-1 to reach the target of 1 replica (db-0). This predictable, step-by-step reduction ensures that distributed state is safely migrated or persisted.

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 →
95
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 are specialized containers that run to completion sequentially before any app containers in the Pod are started. If an init container fails, Kubernetes restarts the Pod repeatedly until it succeeds, making it the ideal mechanism to block the main application until database migrations are successfully applied.

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

Since the controller was down for 120 seconds, the gap between the scheduled midnight execution and the controller's recovery exceeds the configured startingDeadlineSeconds of 100 seconds. Consequently, Kubernetes classifies this execution as a missed deadline and skips it. The controller will now wait until the next scheduled daily occurrence at midnight to trigger the job.

Why this answer

The CronJob controller was down for 2 minutes (120 seconds), which exceeds the `startingDeadlineSeconds` of 100. According to Kubernetes CronJob behavior, if the controller misses the scheduled start time by more than `startingDeadlineSeconds`, the job is considered missed and will not be retroactively created. The controller will only run the next scheduled instance.

Exam trap

The trap here is that candidates assume the controller will always catch up on missed jobs after recovery, but Kubernetes explicitly drops jobs if the delay exceeds `startingDeadlineSeconds`, testing your understanding of the deadline's purpose as a hard cutoff.

How to eliminate wrong answers

Option A is wrong because the job does not run as soon as the controller recovers if the delay exceeds `startingDeadlineSeconds`; the controller only creates missed jobs within the deadline window. Option C is wrong because `backoffLimit` is a field on the Job spec that controls retries for failed Pods, not a mechanism for handling missed CronJob schedules. Option D is wrong because the job does not run immediately with a 2-minute delay; it is permanently skipped for that schedule, and the controller does not retroactively execute it beyond the deadline.

Practice this question →
← PreviousPage 2 of 2 · 96 questions total

Ready to test yourself?

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

Start 20-question session