Skip to content

Quiz: Kubernetes Core

← Back to quiz index

10 questions

L1 (6 questions)

1. A pod is in CrashLoopBackOff. What are your first three commands?

Show answer 1. kubectl describe pod (check Events).
2. kubectl logs --previous (see crash output).
3. kubectl get events --sort-by=.lastTimestamp (cluster-wide context).

2. What is the difference between liveness and readiness probes?

Show answer Liveness: is the container alive? Failure = container restart. Readiness: can it serve traffic? Failure = removed from Service endpoints. Never make liveness depend on external deps.

3. What happens when you delete a pod managed by a Deployment?

Show answer The ReplicaSet controller creates a new pod to maintain desired count. The Deployment is self-healing. To actually remove it, scale the deployment to 0 or delete the deployment.

4. A pod is stuck in CrashLoopBackOff. Walk through your diagnostic steps.

Show answer 1. kubectl describe pod — check Events for pull errors, OOM kills, probe failures.
2. kubectl logs --previous — see the crash output from the last container run.
3. Check exit code: 137 = OOM/SIGKILL, 1 = application error.
4. Verify resource requests/limits are adequate.
5. Check if liveness probe is killing a slow-starting container (increase initialDelaySeconds).
6. If image issue, verify imagePullPolicy and registry access. *Common mistake:* Delete the pod immediately — it will just restart with the same crash if the underlying cause is not fixed.

5. What is the difference between a Deployment, StatefulSet, and DaemonSet, and when do you choose each?

Show answer Deployment: stateless workloads, interchangeable pods, rolling updates. StatefulSet: stateful workloads needing stable network identity ({name}-0, -1), ordered deployment/scaling, and persistent volume claims per replica. DaemonSet: exactly one pod per node (log collectors, monitoring agents, storage drivers). Choose based on whether pods need identity, ordering, or per-node scheduling. *Common mistake:* Use StatefulSet for everything because it is the most capable — StatefulSets add complexity (ordered updates, PVC management) that is unnecessary for stateless workloads.

6. A namespace is stuck in Terminating state. What is causing this and how do you investigate?

Show answer Kubernetes waits for all resources in the namespace to be deleted, including finalizers. Check: kubectl get all -n for remaining resources. Check for stuck finalizers: kubectl get ns -o json | jq '.spec.finalizers'. Common causes: CRDs with finalizers whose controller is already deleted, or PVCs waiting for pod termination. Fix: remove the stuck finalizer (edit the namespace resource), but understand what it was protecting first. *Common mistake:* Force delete with kubectl delete ns --force --grace-period=0 — this does not remove the finalizer and the namespace will remain stuck.

L2 (4 questions)

1. How do you debug a pod that's running but not receiving traffic?

Show answer 1. Check service selector matches pod labels.
2. kubectl get endpoints (should list pod IPs).
3. Check readiness probe (failing = removed from endpoints).
4. Check NetworkPolicy.
5. Check if pod is on a cordoned node.

2. What happens when etcd loses quorum in a 3-node cluster, and how do you recover?

Show answer With 2 of 3 nodes down, etcd becomes read-only — no writes, no new pods, no config changes. The API server returns errors for mutating requests. Recovery: bring at least one failed node back to restore quorum. If data is lost, restore from etcd snapshot (etcdctl snapshot restore). Last resort: recreate the cluster from a single-node snapshot with --force-new-cluster, then re-add members. *Common mistake:* Increase replicas to 5 to prevent this — adding members to a cluster that already lost quorum is impossible without recovery first.

3. Explain the difference between resource requests and limits in Kubernetes. What happens when a container exceeds each?

Show answer Requests: the guaranteed minimum — used by the scheduler for placement. A container can use more than requested if available. Limits: the hard ceiling. Exceeding CPU limit causes throttling (CFS quota). Exceeding memory limit causes OOM kill (exit code 137). Best practice: set requests to actual usage, limits to 1.5-2x requests for CPU, and equal to requests for memory (to avoid OOM surprises). *Common mistake:* Set limits equal to requests always — this wastes resources for CPU (throttling is preferable to over-provisioning).

4. What is the purpose of the Kubernetes admission controller chain, and name three important built-in admission controllers?

Show answer Admission controllers intercept API requests after authentication/authorization but before persistence. They can mutate (add defaults) or validate (reject bad requests). Important built-ins:
1. LimitRanger: enforces default resource requests/limits.
2. PodSecurity: enforces Pod Security Standards (baseline, restricted).
3. ResourceQuota: enforces namespace resource caps. Webhook controllers (MutatingAdmissionWebhook, ValidatingAdmissionWebhook) allow custom policies. *Common mistake:* Admission controllers run on the kubelet — they run in the API server, not on nodes.