Workloads and Scheduling practice questions

maxSurge: 3, maxUnavailable: 2

Why wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: Using the 'scheduler.alpha.kubernetes.io/tolerations' annotation is a deprecated, pre-v1.6 alpha method for specifying tolerations. In modern Kubernetes clusters, the scheduler ignores this annotation entirely, requiring tolerations to be defined natively within the 'spec.tolerations' field of the Pod template.

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

Why wrong: A nodeSelector is used to constrain pods to run only on nodes with matching labels, but it does not bypass or satisfy taints. Even if a node has the label 'dedicated=monitoring', the pod will still be blocked by the 'NoSchedule' taint unless an explicit matching toleration is configured in the pod spec.

Set the priorityClassName to 'system-node-critical'

Why wrong: Setting the priorityClassName to 'system-node-critical' ensures the DaemonSet pods are prioritized during scheduling and protected from preemption under resource pressure. However, priority classes do not override scheduling constraints like taints, meaning the scheduler will still refuse to place the pods on tainted nodes.

successfulJobsHistoryLimit

Why wrong: This field specifies the number of successfully completed jobs that Kubernetes retains in the system's history for auditing and debugging. Adjusting this limit only cleans up old metadata and pods; it has no impact on active job scheduling or preventing concurrent executions.

suspend: true

Why wrong: Enabling the `suspend` field pauses the CronJob entirely, preventing any future jobs from being scheduled until it is set back to false. While this stops concurrent runs, it does so by completely halting the 5-minute batch processing schedule.

startingDeadlineSeconds

Why wrong: This parameter defines the maximum duration in seconds that a job can start late if it misses its scheduled time due to controller delays or resource constraints. It does not manage concurrency or prevent multiple instances from running concurrently if they start on time.

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

Why wrong: Init containers do not run concurrently with application containers; instead, they execute sequentially in a strict, predefined order. Each init container must run to completion and exit successfully before the next one begins, and all of them must finish before the primary application containers are even initialized. Parallel execution alongside main containers is a characteristic of sidecar containers, not init containers.

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

Why wrong: Liveness and readiness probes are distinct lifecycle management mechanisms configured directly within the main container definitions to monitor their ongoing health and traffic readiness. Init containers cannot execute these probes for main containers because init containers run and terminate before the main containers are even created. Furthermore, init containers themselves do not support readiness probes because they must run to completion rather than remain active to serve traffic.

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

Why wrong: Init containers are strictly initialization tools that execute and terminate before the main application containers boot up. They cannot be used for post-execution cleanup tasks because they do not exist once the main containers are running. Post-start hooks, pre-stop hooks, or separate CronJobs are typically utilized for post-execution resource cleanup instead of init containers.

schedulerName

Why wrong: schedulerName only selects which scheduler process evaluates the pod for placement (e.g., my-custom-scheduler). The built-in kube-scheduler and any custom scheduler still decide the node using predicates and priorities; schedulerName does not bypass scheduling logic or pin the pod to a specific node. Unless you set nodeName, the pod remains unscheduled until a scheduler selects it.

affinity

Why wrong: Affinity rules, especially nodeAffinity, use label selectors to constrain feasible nodes but do not bypass the scheduler. You can require a node with a label owned by worker (e.g., kubernetes.io/hostname=worker), yet this is still label-based matching executed during scheduling. nodeAffinity is a soft or hard preference, not a direct pointer to a node object; the scheduler must still select a matching node and the pod is not instantaneously tied to a name.

nodeSelector

Why wrong: nodeSelector is a simple label-based constraint that limits scheduling to nodes carrying all specified labels. It never references the node's name field; while a node's hostname is typically exposed as a label (kubernetes.io/hostname), using nodeSelector with that label is indirect and requires the scheduler to match it. nodeSelector cannot force placement when no node is labeled, and it does not modify the pod's nodeName field.

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

Why wrong: Incorrect. The syntax `--from-file=key=config.properties` specifies a key named "key" explicitly, so the ConfigMap will have a key "key" rather than using the filename as the key. The question expects the default behavior where the filename becomes the key.

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

Why wrong: The --from-literal flag is designed to inject raw key-value pairs directly from the command line using a key=value syntax. Passing a file path like config.properties to this flag will fail because it does not conform to the expected format and cannot read file contents. To load configuration data directly from an external file, the --from-file flag must be utilized instead.

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

Why wrong: While this command successfully creates a Kubernetes resource from a file, it generates a Secret object instead of a ConfigMap. Secrets are intended for sensitive data like passwords or tokens and automatically Base64-encode the payload. For non-sensitive configuration data, the kubectl create configmap subcommand must be used instead.

hostPath

Why wrong: The hostPath volume type mounts a file or directory directly from the underlying host node's filesystem into your Pod. It does not have native integration with Kubernetes Secret objects stored in etcd. Using it for secrets would require manually provisioning the sensitive files on the host node, which exposes security risks and bypasses Kubernetes secret management.

configMap

Why wrong: The configMap volume source is specifically designed to inject non-sensitive configuration data stored in a Kubernetes ConfigMap resource into a Pod. It cannot reference or retrieve data from a Secret object. Attempting to mount a Secret using this volume type will result in a validation error when applying the Pod manifest.

emptyDir

Why wrong: An emptyDir volume is an ephemeral storage space created when a Pod is assigned to a node, starting out completely empty. While it can share temporary files between containers in the same Pod, it cannot automatically fetch or expose pre-existing Kubernetes Secret resources. It is entirely unsuited for securely mounting external sensitive data.

podManagementPolicy: OrderedReady

Why wrong: The podManagementPolicy field, along with its value OrderedReady, is exclusive to StatefulSets and is used to control the provisioning and scaling guarantees of stateful pods. Deployments manage stateless pods concurrently and do not support this field. Attempting to use it in a Deployment spec will result in a validation error.

scaleUp: 2

Why wrong: The scaleUp field is not a valid parameter within the Deployment's spec.strategy block. While scaling behavior can be configured under HorizontalPodAutoscaler (HPA) behavior settings, the Deployment rolling update strategy only recognizes maxSurge and maxUnavailable to control the rate of pod replacement.

type: Recreate

Why wrong: Although Recreate is a valid Deployment strategy type, the question specifically asks for parameters that define a rolling update strategy. Choosing Recreate terminates all existing pods before any new ones are created, which introduces downtime and does not utilize rolling update parameters like maxSurge or maxUnavailable.

0

Why wrong: 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 wrong: 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 wrong: 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.

kubectl apply configmap app-config config.properties

Why wrong: The kubectl apply command is used to manage resources defined in local or remote configuration files (typically YAML or JSON manifests) via the -f or --filename flag. It does not support direct imperative resource creation arguments like configmap app-config followed by a raw properties file.

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

Why wrong: The --from-literal flag expects a literal key-value pair in the format key=value (for example, special.type=charm). Passing a filename like config.properties directly to this flag is invalid syntax and will result in an error because it lacks the required key-value delimiter.

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

Why wrong: While --from-env-file is a valid flag, it is specifically designed to parse a file containing line-delimited key-value pairs and load them as individual environment variables. It is not appropriate for treating an entire configuration file as a single, multi-line data block under a single key.

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

Why wrong: 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 wrong: 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 wrong: 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.

Sidecar container

Why wrong: Sidecar containers are designed to run concurrently alongside the primary application container to extend or enhance its functionality, such as for logging or monitoring. Because they execute in parallel with the main container rather than completing beforehand, they cannot guarantee that database migrations are fully executed before the application attempts to connect.

PostStart hook

Why wrong: The PostStart handler executes immediately after a container is created, but there is no guarantee that it will run before the container's entrypoint is executed. Because it runs asynchronously and concurrently with the main container's startup process, it is unsafe for blocking tasks like database migrations which must finish before the application starts.

Job

Why wrong: A Kubernetes Job is an independent, top-level controller designed to run short-lived, batch tasks to completion. While a Job can execute migrations, it operates under its own lifecycle outside of the application Pod, meaning you would need external orchestration to prevent the application Pod from starting before the Job finishes.

spec.description: "non-preempting"

Why wrong: spec.description is purely informational metadata and has no functional impact on the scheduler or kubelet. The description string is never read by Kubernetes control plane components when making scheduling or preemption decisions. Therefore, adding "non-preempting" as a description simply labels the object but does not implement the required non-preemption behavior.

spec.globalDefault: true

Why wrong: spec.globalDefault: true makes this PriorityClass the default for all Pods that do not specify a priorityClassName. While this may cause more Pods to use the high-priority class, it does not control whether those Pods can preempt others. In fact, making it global default could unintentionally elevate many workloads to high priority, increasing preemption risk rather than preventing it.

spec.value: 1000

Why wrong: spec.value: 1000 sets a numeric priority score used for scheduling order and, by default, to decide which Pods may preempt lower-priority Pods. A higher value actually makes the Pod more likely to preempt others when preemptionPolicy is not set to Never. Thus, setting a high value alone does not make the PriorityClass non-preempting; it does the opposite unless combined with the correct preemptionPolicy.

The HPA is using the wrong metric.

Why wrong: 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 wrong: 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 wrong: 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.

volumes: - name: secret-volume secretName: my-secret

Why wrong: This syntax is invalid because 'secretName' is not a direct child of the volume list item. Kubernetes requires the 'secret' block to be explicitly defined first, and then 'secretName' must be nested inside that block to properly identify the target Secret.

volumes: - name: secret-volume configMap: name: my-secret

Why wrong: This configuration attempts to mount a ConfigMap instead of a Secret. While both are configuration resources, a ConfigMap cannot retrieve or expose sensitive data stored in a Secret resource, making this schema incorrect for mounting secrets.

volumes: - name: secret-volume hostPath: path: /etc/secret

Why wrong: This option uses the 'hostPath' volume source, which mounts a directory or file from the host node's filesystem into the pod. It does not reference or retrieve any Kubernetes Secret resource managed by the control plane.

kubectl set image deployment/web-app web-app=image:v1

Why wrong: While this command updates the container image of the deployment to `image:v1`, it creates a brand new rollout revision rather than reverting to an existing historical revision. It does not utilize the deployment's revision history to restore previous configurations like environment variables or resource limits that might have changed.

kubectl rollout history deployment/web-app --revision=1

Why wrong: This command is used purely for inspection, displaying the detailed configuration, annotations, and pod template metadata of revision 1. It is a read-only operation that does not trigger any state changes, replica set scaling, or rollbacks within the cluster.

kubectl rollout undo deployment/web-app

Why wrong: Without the `--to-revision` flag, this command defaults to rolling back only to the immediately preceding revision (revision N-1). If the deployment has undergone multiple updates, this will not target revision 1 unless it happens to be the direct predecessor.

Memory requests and limits are both compressible.

Why wrong: Unlike CPU, which is a compressible resource that can be throttled when limits are reached, memory is an incompressible resource. If a container attempts to allocate more memory than is available or exceeds its defined limit, the kernel cannot throttle its memory usage and will instead terminate the process via the Out-Of-Memory (OOM) killer.

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

Why wrong: Throttling is a mechanism applied exclusively to compressible resources like CPU by CFS bandwidth control. When a container attempts to allocate memory beyond its configured limit, the Linux kernel's OOM killer immediately terminates the container's processes with an Exit Code 137, rather than slowing down its execution.

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

Why wrong: While a Pod without defined limits can theoretically consume all available resources on its host node, its consumption is physically bounded by the node's hardware capacity. Additionally, default LimitRanges applied to the namespace may automatically inject default limits, preventing truly unrestricted resource consumption.

NeverSchedule

Why wrong: NeverSchedule is not a recognized Kubernetes taint effect. The core API defines taint effects as an enumerated set of string constants, and 'NeverSchedule' does not appear in that set. Although it sounds like a plausible synonym for 'NoSchedule', the scheduler will treat it as an invalid value, causing taint validation errors. The only hard scheduling taint effect is NoSchedule.

PreferSchedule

Why wrong: There is no taint effect called 'PreferSchedule'. The valid soft taint effect is 'PreferNoSchedule', and 'PreferSchedule' would imply a preference to schedule pods on the node, which is the opposite of a taint's purpose. Taints are used to repel pods, not attract them, so a 'PreferSchedule' effect would be semantically contradictory. Kubernetes only allows PreferNoSchedule for the 'soft' avoidance behavior.

DaemonSets are typically managed by a parent Deployment.

Why wrong: DaemonSets are independent API objects managed by their own controller in the kube-controller-manager. They are not subordinate to Deployments; a Deployment owns ReplicaSets, which own Pods with a maintained replica count. A DaemonSet directly creates and manages Pods on targeted nodes without any Deployment parent, so this statement contradicts Kubernetes ownership and controller mechanics.

DaemonSets do not support rolling updates.

Why wrong: DaemonSets fully support rolling updates via the `.spec.updateStrategy` field, with `RollingUpdate` as the default strategy. The DaemonSet controller replaces Pods node-by-node, honoring `maxUnavailable` and `maxSurge` to control disruption; the alternative `OnDelete` strategy updates Pods only after manual deletion. Thus, claiming no rolling update support is incorrect.

DaemonSets have a desired number of replicas that the scheduler tries to maintain.

Why wrong: DaemonSets have no `spec.replicas` field or desired replica count; instead, the DaemonSet controller calculates the desired number of pods from the nodes selected by the DaemonSet's node selector, node affinity, and tolerations. The controller creates a pod for every selected node, and if a node is added or removed, the pod count adjusts automatically. The scheduler is not maintaining a static replica count; rather, the DaemonSet controller ensures per-node pod placement.

Pods web-3 and web-4 are created in parallel, both sharing the same PVC

Why wrong: The StatefulSet controller defaults to OrderedReady pod management, which creates pods sequentially by ordinal, not in parallel; parallel creation would require .spec.podManagementPolicy: Parallel. Additionally, each pod in a StatefulSet has its own PVC provisioned from the volumeClaimTemplates section, so the two new pods would not share a single PVC. Sharing a PVC across pods would violate the one-to-one binding between a StatefulSet pod and its volume, and is not how StatefulSet scaling works.

The existing pods are recreated with new PVCs

Why wrong: Scaling a StatefulSet from 3 to 5 replicas only adds new pods for the new ordinals (web-3 and web-4); it does not recreate the existing web-0, web-1, and web-2 pods. Existing pods keep their stable identity, networking, and PVCs because StatefulSet guarantees that pod names and volume bindings are sticky across scale-up and scale-down. Pod recreation would only happen during an update strategy like RollingUpdate, not during a simple replica count change.

Only web-3 is created because the StatefulSet cannot exceed 4 replicas

Why wrong: There is no upper bound of 4 on StatefulSet replicas; the ordinal index can increase indefinitely as long as cluster resources are available. Scaling from 3 to 5 replicas is a valid operation and the controller will create both web-3 and web-4. The only reason web-4 might not appear is if it fails the readiness check or if there are insufficient resources, not because of a hidden replica limit.