Workloads and Scheduling practice questions

Delete the namespace and redeploy all workloads

Why it fails: Deleting the namespace removes every workload in production, not just the OOMKilled pod, so it cannot address a single container exceeding its memory limit. Namespace deletion suits decommissioning an entire environment or clearing a test namespace, where all contained resources are genuinely disposable.

Delete and recreate the pod to clear the crash loop

Why it fails: Recreating the pod produces an identical spec, so the container again exceeds its memory limit and returns to CrashLoopBackOff. Deleting and recreating pods is for clearing stuck states such as a bad node binding or an evicted pod, not for a deterministic resource-limit breach.

Increase the CPU request for the container

Why it fails: OOMKilled means the kernel terminated the container for exceeding its memory limit, so raising the CPU request leaves the memory ceiling unchanged and the pod keeps restarting. CPU requests govern scheduling and throttling, and are the right lever when a container is CPU-starved, not memory-killed.

maxSurge: 3, maxUnavailable: 2

Why it fails: maxSurge=3 allows up to 3 extra pods above the desired 10, violating the 'at most 2 pods above' constraint.

maxSurge: 3, maxUnavailable: 3

Why it fails: maxSurge=3 violates the extra pod limit, and maxUnavailable=3 would allow only 7 available pods (10-3=7), violating the 'at least 8 available' constraint.

maxSurge: '20%', maxUnavailable: '20%'

Why it fails: Correct. The 20% values translate to maxSurge=2 and maxUnavailable=2 for this replica count, meeting both constraints. In Kubernetes, percentage-based values are legally valid and equivalent to the integer values for this scenario.

0

Why it fails: Setting the maximum unavailable pods to 0 is incorrect because a rolling update requires at least one pod to be terminated and replaced to progress the rollout, unless maxSurge is configured to allow extra pods. In a standard configuration where we are calculating 25% of 4 replicas, a value of 0 would mean 0% unavailability, which does not match the 25% specification.

4

Why it fails: If 4 pods were allowed to be unavailable during the rolling update, it would represent 100% of the desired 4 replicas. This would result in a complete service outage during the deployment process, violating the 25% maximum unavailability constraint which is designed to maintain high availability.

2

Why it fails: Allowing 2 pods to be offline simultaneously represents 50% of the total 4 replicas. This exceeds the configured 25% threshold, meaning the deployment controller would be violating its safety parameters by taking down too many pods at once during the rolling update.

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

Why it fails: The `concurrencyPolicy` field in a Kubernetes CronJob specifies how to handle concurrent job executions. When set to 'Allow', which is the default behavior if not explicitly defined, it permits new job executions to start even if previous scheduled jobs are still running. This directly leads to overlapping executions, where multiple instances of the same backup job might be active simultaneously, fulfilling the scenario described.

The job's parallelism is set to 2.

Why it fails: The `parallelism` field within a Kubernetes Job definition controls the number of pods that can run concurrently *for a single execution* of that specific Job. For instance, if `parallelism` is 2, two pods would run simultaneously to complete one backup task. It does not, however, govern whether multiple *separate scheduled runs* of a CronJob can overlap. Overlapping executions refer to distinct instances of the CronJob's underlying Job running concurrently, which is managed by `concurrencyPolicy`.

The CronJob's startingDeadlineSeconds is set too low.

Why it fails: The `startingDeadlineSeconds` field in a CronJob specifies the maximum time in seconds that a job can be delayed from its scheduled start time before it is considered missed and not run. If this deadline is exceeded, the job will be skipped. A low `startingDeadlineSeconds` would cause jobs to be *skipped* if they cannot start on time, rather than causing multiple job instances to *overlap* by running concurrently. It addresses missed schedules, not concurrent execution.

The HPA is using the wrong metric.

Why it fails: Horizontal Pod Autoscalers commonly use CPU utilization as a primary metric for scaling decisions, as it directly reflects the computational load on pods. If the HPA is configured to scale based on CPU, and the problem describes a failure to scale down, it implies the metric itself is being correctly observed and evaluated. The issue isn't the choice of metric, but rather how the HPA's internal logic processes the observed metric over time.

The Deployment's rolling update is in progress.

Why it fails: While a Deployment undergoing a rolling update can indeed temporarily interfere with HPA scaling actions, particularly downscaling, the question provides no information to suggest such an update is active. During an update, the Deployment controller manages replica counts, potentially overriding HPA's desired state until the update completes. Without explicit mention of an ongoing update, this remains an unsubstantiated assumption.

The HPA's minReplicas is set to 5.

Why it fails: The `minReplicas` parameter in an HPA configuration establishes the absolute minimum number of pods the autoscaler will maintain, preventing scaling below this threshold. If `minReplicas` were set to 5, the HPA would simply refuse to scale down past five pods, regardless of low resource utilization. The problem statement indicates a general failure to scale down, not that it's specifically stuck at a floor of 5, making this a less precise explanation for the observed behavior.

kubectl get events --watch

Why it fails: Incorrect: The `--watch` flag does not produce a sorted list of all events; it streams new events as they occur.

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

Why it fails: Incorrect: This command sorts by `.lastTimestamp` in ascending order, displaying oldest events first. It does not show newest first.

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

Why it fails: Incorrect: This command sorts by `.firstTimestamp` in ascending order, displaying oldest events first.

The init container image was not found

Why it fails: If the init container's image was not found, Kubernetes would report an `ImagePullBackOff` status for the pod. This status specifically indicates that the Kubelet failed to pull the container image, typically due to an incorrect image name, tag, or registry authentication issue. An `Init:Error` status, however, signifies that the image was successfully pulled and started, but the command executed within the init container itself failed.

The pod's main container failed to start

Why it fails: The pod's main container would not even attempt to start if an init container is still in an `Init:Error` state. Init containers are designed to run to completion, one after another, before any of the application containers are launched. Therefore, a failure in the main container would manifest as a different status, such as `CrashLoopBackOff` or `Error`, but only *after* all init containers have successfully finished their tasks.

The init container exceeded a resource limit

Why it fails: If the init container exceeded a resource limit, the pod status would reflect a more specific error, such as `OOMKilled` for memory exhaustion or a `CPUThrottled` event if CPU limits were hit. While these conditions can lead to a container exiting, the `Init:Error` status specifically points to a command-level failure rather than a direct resource constraint violation that Kubernetes explicitly monitors and reports with distinct states.

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

Why it fails: Although representing nested fields as inline JSON-like maps is technically valid in YAML parsers, it deviates from standard Kubernetes API schema representations used on the CKA exam. The exam expects the standard nested block structure or dot-notation representation (`secret.secretName`) to ensure clear, declarative manifest definitions.

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

Why it fails: While this syntax is valid for injecting all key-value pairs from a Secret as environment variables inside the container, it does not mount the Secret as a volume. Volume mounting requires defining a volume in `spec.volumes` and a corresponding mount path in `spec.containers[*].volumeMounts`.

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

Why it fails: This configuration incorrectly attempts to use a `configMap` volume source instead of a `secret` volume source. Additionally, the schema for a ConfigMap volume uses the field `name` to reference the resource, whereas a Secret volume specifically requires the `secretName` field to locate the target Secret.

progressDeadlineSeconds

Why it fails: This is a field of the Deployment spec, not part of the rolling update strategy.

minReadySeconds

Why it fails: This is a field of the pod template spec, not of the rolling update strategy.

type

Why it fails: Correct. The type field in spec.strategy defines the strategy type: Recreate or RollingUpdate. Within RollingUpdate, maxSurge and maxUnavailable are used.

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

Why it fails: This command is incorrect because `kubectl update` is not a valid subcommand for directly modifying deployment properties like container images. Kubernetes uses more specific commands such as `kubectl set image` or `kubectl apply` for declarative updates, or `kubectl edit` for interactive modifications. Attempting to use `kubectl update` in this manner would result in a command not found error or an invalid argument error, as it does not support `--image` or `--strategy` flags for deployments.

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

Why it fails: This command is incorrect for two primary reasons. First, `kubectl rollout` does not have a `set image` subcommand; image updates are handled by `kubectl set image`. The `kubectl rollout` command is primarily used for managing the lifecycle of a rollout (e.g., `status`, `history`, `undo`, `pause`, `resume`). Second, `--max-surge` is not a valid flag for `kubectl set image` itself; rollout strategy parameters are typically configured within the Deployment's spec or handled by default values.

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

Why it fails: This is the correct and most idiomatic command for updating a container image within a Kubernetes Deployment. `kubectl set image` directly targets the specified container (`nginx`) within the `nginx-deployment` and updates its image to `nginx:1.21`. By default, this command triggers a RollingUpdate strategy, ensuring that new pods are gradually brought up and old pods are terminated, minimizing downtime. The default `RollingUpdate` strategy includes `maxSurge=25%` and `maxUnavailable=25%`, managing the rollout automatically.

kubectl describe job/pi-job

Why it fails: While `kubectl describe job/pi-job` provides valuable high-level metadata, event history, and the current status of the Job controller, it does not display the standard output (stdout) or standard error (stderr) streams of the underlying Pod. To view the actual computation results generated by the container, you must query the container logs directly rather than inspecting the Job resource definition.

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

Why it fails: Attempting to run `kubectl exec` against a Job or its completed Pod will fail because execution requires an active, running container process. Once a Job finishes its execution, the Pod transitions to a `Succeeded` or `Failed` phase, terminating its containers. Furthermore, standard Kubernetes applications write their output to stdout/stderr rather than an arbitrary internal log file like `/var/log/pi.log`.

kubectl log job/pi-job

Why it fails: The command fails due to a syntax error because `kubectl` does not recognize `log` as a valid plural or singular command for retrieving container output. The correct, built-in CLI command is pluralized as `kubectl logs`. Using the singular form will result in an "unknown command" error from the Kubernetes command-line interface.

PreferNoSchedule

Why it fails: PreferNoSchedule is a soft preference taint effect; the scheduler will generally avoid placing new pods on the node but is not required to. It does not affect pods that are already running, so it can never cause eviction, and adding a toleration for it has no bearing on an existing pod. Since the pod in question is already scheduled on the node, PreferNoSchedule is irrelevant to its fate.

NoSchedule

Why it fails: NoSchedule only influences the scheduling of new or pending pods; it neither evicts existing pods nor affects their running status. A pod already scheduled on a node with a NoSchedule taint will continue running unless another mechanism removes it. Since the pod is already on the node, NoSchedule would not help keep it there, nor does it address the question of eviction.

NoExecute with tolerationSeconds: 300

Why it fails: While this is a NoExecute effect, the inclusion of tolerationSeconds: 300 makes the toleration temporary. The pod will tolerate the taint for 300 seconds, after which Kubernetes will evict it if the taint persists. So instead of preventing eviction, it only delays it for five minutes, which is not the desired continuous protection required for the pod to stay.

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

Why it fails: kubectl patch deployment webapp -p '{"spec":{"replicas":5}}' does update the Deployment's replica count via a strategic merge patch, so it technically works. However, it requires hand-crafting JSON patch syntax and is much less readable than the dedicated imperative scaling command. Because the question asks for the standard way to scale a Deployment, this convoluted approach is not the expected answer even though it is functionally valid.

kubectl edit deployment webapp --replicas=5

Why it fails: The command kubectl edit deployment webapp --replicas=5 is invalid because kubectl edit does not accept a --replicas flag; its purpose is to open the resource's manifest in your default text editor so you can make manual changes and save them. Even if you could pass such a flag, the edit command focuses on interactive YAML/JSON modifications rather than a single arithmetic change. To change replicas in one shot, you need kubectl scale, so this option is incorrect.

kubectl update deployment webapp --replicas=5

Why it fails: kubectl update deployment webapp --replicas=5 is not a valid kubectl command because there is no kubectl update subcommand in the CLI. The kubectl tool offers apply, edit, patch, scale, and other verbs, but update is not among them—so this command would immediately produce an "unknown command" error. You cannot scale a Deployment with a nonexistent invocation, which is why this option is wrong.

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

Why it fails: Kubernetes does not force high-priority pods to wait indefinitely for lower-priority workloads to complete their execution naturally. Instead, the scheduler actively terminates the lower-priority pods by sending a SIGTERM signal to free up resources immediately. This active eviction mechanism ensures that critical workloads are not delayed by long-running, non-urgent tasks.

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

Why it fails: The Kubernetes scheduler strictly respects the resource requests defined in pod specifications and will not overcommit a node's physical capacity to place a pod. If a node lacks the unallocated capacity to satisfy the high-priority pod's requests, the scheduler must evict existing pods rather than simply ignoring resource boundaries. Overcommitting beyond allocatable limits would risk node instability and OOM kills.

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

Why it fails: Pod preemption and priority-based scheduling are core Kubernetes features that are enabled by default in all modern clusters. The scheduler does not ignore PriorityClass objects unless preemption has been explicitly disabled via the scheduler configuration file (`KubeSchedulerConfiguration`). In a standard CKA exam environment or default cluster setup, this feature is fully active and operational.

Running

Why it fails: The Running phase indicates that a Pod has been bound to a node, all containers have been created, and at least one container is currently starting or running. Because the Job's backup task has finished executing successfully, the Pod is no longer active. Therefore, it transitions out of the Running phase into a terminal state.

Completed

Why it fails: While kubectl get pods may display Completed in the STATUS column as a user-friendly summary, Completed is not an official Pod phase in the Kubernetes API. The Pod's actual .status.phase field is set to Succeeded once its containers exit with code 0. Completed is instead derived from container states and Pod conditions.

Terminated

Why it fails: "Terminated" describes a container state, not a pod phase. When a Job's pod successfully completes its tasks, as specified, its phase transitions to `Succeeded`. This option is tempting because individual containers within a pod *do* enter a `Terminated` state once they have finished executing, whether successfully or with an error. However, the question specifically asks for the overall pod's phase, which reflects its lifecycle status.

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

Why it fails: kubectl create cm has no --file flag; it accepts --from-file or --from-literal, so the command errors out. It is tempting because --file appears in kubectl create -f and in other subcommands, and it would be correct if the manifest were supplied via kubectl apply -f instead.

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

Why it fails: Using --from-literal treats the entire string 'config.properties' as a single key-value pair, so no file content is read and the resulting ConfigMap is empty of the intended data. The flag is designed for inline key=value pairs typed directly on the command line, which suits small static settings rather than importing an existing properties file.

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

Why it fails: --from-env-file parses the file as newline-separated KEY=value environment variables, not as a properties file with the expected key-value semantics, so keys containing dots or comments may be mishandled. It is intended for importing shell-style env files, which is correct when the source is genuinely an env file rather than config.properties.

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

Why it fails: This configuration is incorrect because it sets `maxSurge: 1` and `maxUnavailable: 2`. While `maxSurge: 1` allows only one new pod to be created above the desired replica count, potentially slowing down the update process, `maxUnavailable: 2` means that up to two existing pods can be taken offline simultaneously. This level of unavailability might exceed acceptable service disruption thresholds for many production applications, making the rollout less resilient than desired.

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

Why it fails: This option is also correct because it precisely defines the rolling update strategy with `maxSurge: 2` and `maxUnavailable: 1`. This setup dictates that the deployment can temporarily exceed its desired replica count by two pods during the update, facilitating a smoother transition. Crucially, it limits the number of unavailable pods to one at any moment, ensuring that the service maintains a high level of availability throughout the update process by keeping at least 90% of its replicas operational.

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

Why it fails: This option is technically incorrect because it explicitly includes `type: RollingUpdate` within the strategy. While the `rollingUpdate` parameters themselves (`maxSurge: 2`, `maxUnavailable: 1`) are correct for the desired behavior, `RollingUpdate` is the default deployment strategy type. Therefore, explicitly declaring it is redundant and adds unnecessary verbosity to the manifest, conflicting with the common CKA exam expectation for concise and minimal configurations.

spec.tolerations

Why it fails: Tolerations are a mechanism used to allow pods to be scheduled on nodes that have taints, which would otherwise repel them. They do not actively select nodes based on labels but rather permit a pod to run on a node despite a taint. Therefore, `spec.tolerations` cannot be used to *select* all nodes possessing a specific label for a DaemonSet, as their function is to overcome node restrictions, not to define node selection criteria.

spec.nodeName

Why it fails: Using `spec.nodeName` forces a pod to run on a specific node identified by its exact name, completely bypassing the Kubernetes scheduler. This hard constraint is suitable for very specific, single-node deployments but prevents the DaemonSet from distributing pods across *multiple* nodes that merely share a common label. It cannot dynamically select multiple nodes based on a label criterion, making it unsuitable for the stated goal.

spec.affinity.nodeAffinity

Why it fails: While `spec.affinity.nodeAffinity` allows for sophisticated node selection based on labels, it's overkill and not the direct mechanism for a simple label-based DaemonSet placement. This option is tempting because affinity rules *do* use node labels, and it's the correct choice for complex scheduling scenarios like preferring certain nodes or avoiding others, but it doesn't directly map to the DaemonSet's fundamental requirement for *all* nodes matching a specific label.

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

Why it fails: While this syntax is technically valid for mapping a file's contents to a custom key named app-config, it is incorrect here because the question asks to create the ConfigMap directly from the file. Using the key=path syntax unnecessarily alters the default behavior where the filename itself acts as the key. This introduces redundant complexity when a simple file import is requested.

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

Why it fails: The --from-env-file flag (often mistaken as --from-env) is designed specifically to parse files containing key=value environment variables, turning each line into an individual key-value pair in the ConfigMap. It cannot be used to import an entire configuration file as a single block of text under a filename key. Attempting to use this flag on a standard configuration file that does not strictly conform to environment variable formatting will result in parsing errors.

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

Why it fails: The --from-literal flag is reserved for passing raw key-value pairs directly from the command line, such as key=value. Passing a file path like config.properties to this flag will not read the file's contents; instead, it will literally store the string path itself as the value or fail due to incorrect syntax. To load actual file contents, the --from-file flag must be used instead.

10

Why it fails: Scheduling 10 pods with a CPU request of 250m each requires a total of 2500m (2.5 cores) of allocatable CPU. Since the node's total CPU capacity is limited to 2000m (2 cores), the Kubernetes scheduler will block the 9th and 10th pods, leaving them in a Pending state due to insufficient CPU resources.

16

Why it fails: Attempting to run 16 pods would demand 4000m of CPU capacity, which is double the node's physical limit of 2000m. The kube-scheduler strictly enforces resource requests during the filtering phase of scheduling, meaning half of these requested pods would fail to bind to the node and remain unschedulable.

4

Why it fails: While 4 pods can easily fit on the node, they only consume 1000m of CPU, which is exactly half of the node's 2000m capacity. This leaves the node underutilized, meaning it is not the maximum number of pods that can be successfully scheduled under these resource constraints.