Sample questions
K8s WorkloadsDifficulty 1
What is the smallest deployable unit in Kubernetes, and what happens to a bare Pod created without an owning controller if it is deleted or its Node fails?
- aIt is a container, and Kubernetes always restarts it on a different Node automatically
- bIt is a Node, and workloads are scheduled onto it without any wrapping object
- cIt is a Pod, and Kubernetes does not automatically recreate it on its own✓
- dIt is a namespace, and every Pod inside it is recreated together as a group
Explanation:A Pod is the smallest unit you can create and schedule directly. A Pod created without an owning controller (a 'bare' Pod) is not recreated if it is deleted or its Node fails — only a controller like a Deployment or ReplicaSet watches the desired count and replaces missing Pods. a describes controller behavior, not what a bare Pod does on its own; b and d misplace where scheduling and grouping actually happen.
K8s WorkloadsDifficulty 1
In the object hierarchy created by a Deployment, which controller is set as the direct owner of the running Pods (visible in each Pod's ownerReferences)?
- aThe ReplicaSet that the Deployment created✓
- bThe Deployment object directly, with no ReplicaSet in between
- cThe Service that routes traffic to the Pods
- dThe kubelet running on the Pod's assigned Node
Explanation:Each Pod's ownerReferences points to the ReplicaSet, not the Deployment — the Deployment owns the ReplicaSet, and the ReplicaSet in turn owns the Pods, forming a two-level chain. b skips the intermediate ReplicaSet that actually exists; c and d are unrelated to the ownership chain, a Service only selects Pods by label and a kubelet does not own objects in the API.
K8s WorkloadsDifficulty 2
Running kubectl get pod web-6cfbf48659-s2t7j -n wl-jr -o yaml for a Pod created by a Deployment shows this under metadata:
ownerReferences:
- apiVersion: apps/v1
kind: ReplicaSet
name: web-6cfbf48659
controller: true
What does this confirm about how the Pod is managed?
- aThe Deployment directly created and owns this Pod without any intermediate object
- bThis Pod was created manually and later adopted by a Service for routing
- cThe Pod's name is unrelated to any controller and was assigned randomly by the scheduler
- dA ReplicaSet named web-6cfbf48659 is the controller that owns and manages this Pod✓
Explanation:The ownerReferences entry with kind: ReplicaSet and controller: true confirms the ReplicaSet web-6cfbf48659 is the direct owner responsible for this Pod's lifecycle. a is wrong because the field explicitly names a ReplicaSet, not the Deployment; b and c invent scenarios not shown by this output at all.
K8s WorkloadsDifficulty 2
A Deployment web currently has spec.replicas: 2 and 2 Pods are Running. You run:
kubectl scale deployment/web --replicas=4 -n wl-jr
What is the direct effect?
- aA second Deployment named web is created running in parallel with 4 replicas
- bThe Deployment's replicas field becomes 4, adding 2 Pods from its ReplicaSet✓
- cThe command only updates the field, and Pods are added on the next
kubectl apply - dThe command fails because replicas cannot be changed after a Deployment is created
Explanation:kubectl scale patches spec.replicas on the existing Deployment; the ReplicaSet then reconciles immediately and creates the additional Pods from the same Pod template, without waiting for another apply. a invents a second object that is never created; c is wrong because reconciliation happens right away, not on a future apply; d is false, replicas is a mutable field.
K8s WorkloadsDifficulty 2
Instead of using kubectl scale, an engineer edits the Deployment manifest to change replicas: 2 to replicas: 4 and runs kubectl apply -f deploy.yaml. How does the resulting behavior compare to running kubectl scale deployment/web --replicas=4?
- aOnly
kubectl scale triggers the ReplicaSet, editing YAML and reapplying has no effect on Pod count - bEditing the YAML forces a full rolling restart of all existing Pods even though the image did not change
- cBoth update the same
spec.replicas field, so the ReplicaSet converges to 4 Pods either way✓ - d
kubectl apply after editing YAML deletes the old Deployment and creates a brand-new one from scratch
Explanation:Both paths end up patching the same spec.replicas field on the same Deployment object, so the outcome is identical: the ReplicaSet reconciles to 4 Pods. a is false since editing plus apply does update the live object; b is wrong because only the replica count changed, not the Pod template, so no restart of existing Pods is triggered; d misdescribes apply, which updates the existing object rather than recreating it.
K8s WorkloadsDifficulty 2
A Deployment web has replicas: 2 and both Pods are Running. You run kubectl delete pod web-6cfbf48659-gp9n7 -n wl-jr. A few seconds later you check kubectl get pods. What do you observe?
- aStill 2 Pods total: the deleted one is gone and a new Pod has taken its place✓
- bOnly 1 Pod remains, because the Deployment reduces
replicas to match the actual count - cThe Deployment is marked as failed and requires manual
kubectl rollout restart to recover - dThe same Pod reappears with the identical name it had before deletion
Explanation:The ReplicaSet continuously reconciles the actual Pod count toward the desired replicas value; deleting a Pod it owns just makes it create a replacement with a new generated name, restoring the count to 2. b inverts the reconciliation direction; c invents a failure state that does not occur from a routine Pod deletion; d is wrong because the replacement Pod gets a fresh name, not the deleted one's name.