Workloads and Scheduling

You maintain a Deployment for a payments service. The team stores 12 application settings in a ConfigMap named 'payments-config' and wants ALL of them injected as environment variables into the container without listing each key individually in the Pod spec. Which configuration achieves this?

You mount a ConfigMap named app-config into a Deployment's pod using a volume with a subPath reference (mountPath: /etc/app/config.yaml, subPath: config.yaml). After editing the ConfigMap with 'kubectl edit configmap app-config', you notice the running pods still see the old file contents even after several minutes. Other Deployments that mount the same ConfigMap as a full directory (no subPath) do receive the update automatically. What is the correct explanation and fix?

You maintain a monitoring DaemonSet that must run a node-exporter pod on every node in the cluster, including the control-plane nodes. After deploying, you notice the DaemonSet pods are running on all worker nodes but not on the control-plane nodes. Describing a control-plane node shows the taint 'node-role.kubernetes.io/control-plane:NoSchedule'. Which change to the DaemonSet pod spec will allow the pods to also be scheduled on the control-plane nodes without affecting scheduling elsewhere?

You manage a Deployment named 'billing-api' whose pods mount a ConfigMap named 'billing-config' as environment variables using envFrom. After a colleague updates several values in 'billing-config' with 'kubectl edit configmap billing-config', users report the application is still using the old configuration values. The pods are all Running and healthy. What is the correct explanation and remediation?

A Deployment named web has 10 replicas and uses the default RollingUpdate strategy with maxSurge: 0 and maxUnavailable: 25%. You trigger a rolling update with a new image. During the rollout, you observe that only some old pods are terminated at a time and no extra pods beyond 10 are ever created. What is the maximum number of pods that can be unavailable at any moment during this rollout?

You need to apply several changes to a running Deployment named 'web': update the container image, add a new environment variable, and increase the CPU request. You want to make all these edits without triggering a separate rolling update for each change, then roll them all out together as a single revision. Which sequence of commands achieves this?

A platform engineer manages a Deployment named 'payments-api'. After several rolling updates, they attempt to roll back two revisions using 'kubectl rollout undo deployment/payments-api --to-revision=3', but the command fails with an error stating that the revision was not found. Running 'kubectl rollout history deployment/payments-api' shows only the two most recent revisions. What is the most likely cause?

You deployed a new version of an application by updating the image on a Deployment named 'payment-api'. After the rollout completes, users report errors and you confirm the new image is broken. You need to quickly revert 'payment-api' to the exact configuration it had before this latest update, while preserving the ability to inspect what changed. Which command accomplishes this most directly?

A Deployment named 'payments' runs 10 replicas behind a Service that must never drop below full capacity during updates. The team also wants updates to proceed as fast as possible while guaranteeing that at no point are fewer than 10 Pods Ready. Which rollingUpdate strategy configuration satisfies these requirements?

You maintain a Deployment named `web` running 3 replicas. Marketing needs the app to handle a traffic spike, so you must temporarily scale it to 10 replicas without editing or reapplying the Deployment manifest and without triggering a new rollout of the pod template. Which command accomplishes this most directly?

You manage a payment-processing Deployment with an HPA targeting 60% CPU. During flash sales, the app receives sudden traffic spikes, but you observe that pods are added too aggressively — jumping from 4 to 40 replicas in a single scaling event, overwhelming the downstream database. You want the HPA to add at most 4 pods every 60 seconds regardless of how high the metric spikes. Which HPA configuration achieves this?

You are managing a Deployment named 'payments' with 3 replicas. The team wants each replica to run on a different node for high availability, but they notice all 3 pods have been scheduled onto the same node. Which addition to the pod template will BEST guarantee that the scheduler spreads the replicas across separate nodes?

An HPA managing a Deployment is configured with a target CPU utilization of 60%. During a short traffic spike the HPA scaled the workload from 3 to 10 replicas. After the spike ended, the pod count dropped back to 3 within about 15 seconds, but a follow-up spike a minute later caused rapid re-scaling, producing noticeable 'flapping' of replica counts. Which change to the HPA best prevents the aggressive scale-down and resulting oscillation?

You created a HorizontalPodAutoscaler targeting a Deployment named 'web' with 'kubectl autoscale deployment web --cpu-percent=50 --min=2 --max=10'. Metrics-server is installed and healthy, and 'kubectl top pods' returns CPU values for the web pods. However, running 'kubectl get hpa' shows the TARGETS column as '<unknown>/50%' and the HPA never scales beyond the minimum. What is the most likely cause?

You configured a HorizontalPodAutoscaler for a Deployment with a target of 50% average CPU utilization. Each pod has a CPU request of 200m. The Deployment currently runs 3 pods, and the metrics-server reports the pods are consuming 180m, 160m, and 200m of CPU respectively. Based on the standard HPA scaling algorithm, what will the HPA do?

You are scheduling a batch workload that must land only on nodes located in either the 'us-east-1a' or 'us-east-1b' zones, but must NOT run on nodes labeled 'disktype=hdd'. You write a Pod spec with a single requiredDuringSchedulingIgnoredDuringExecution nodeSelectorTerm containing two matchExpressions: one with key 'topology.kubernetes.io/zone', operator 'In', values ['us-east-1a','us-east-1b'], and one with key 'disktype', operator 'NotIn', values ['hdd']. The Pod schedules onto a node in us-east-1a that has 'disktype=ssd'. A node in us-east-1a labeled 'disktype=hdd' is available but the Pod avoids it. Which statement correctly explains the matching behavior?

You maintain a Deployment that should run on nodes labeled disktype=ssd whenever possible, but the Pods must still be scheduled even if no SSD nodes are available. Your current spec uses requiredDuringSchedulingIgnoredDuringExecution with a nodeSelectorTerm matching disktype=ssd, and Pods now stay Pending when all SSD nodes are full. Which change to the Deployment's Pod spec achieves the desired behavior?

You run a Deployment with 3 replicas of a stateless web service. During an incident, all 3 pods happened to be scheduled onto the same node, and when that node failed the entire service went down. You must ensure the scheduler spreads the replicas so that no two pods of this Deployment ever run on the same node, and scheduling should FAIL rather than co-locate pods if not enough nodes are available. Which pod spec addition achieves this?

You maintain a Deployment whose Pods consume a Secret named db-creds. The security team rotates the Secret in place with 'kubectl apply', updating the password key. Your application reads the password only at request time (re-reading the file on each request), and you want running Pods to pick up the new value WITHOUT triggering a rollout or restarting the Pods. Which method of consuming the Secret in the Pod spec meets this requirement?

A legacy Java application takes about 90 seconds to initialize before it can serve any traffic. You configured a livenessProbe with an httpGet on port 8080, initialDelaySeconds of 10, periodSeconds of 10, and failureThreshold of 3. The pod repeatedly enters CrashLoopBackOff during startup, but the application is otherwise healthy once running. Which change best resolves the restarts without weakening ongoing liveness detection?