yoklainterview sim

DevOps / Cloud K8s Observability Troubleshooting Interview Questions

75 verified DevOps / Cloud K8s Observability Troubleshooting interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

K8s Observability TroubleshootingDifficulty 1
In Kubernetes, what does the Pod phase Running actually guarantee?
  • aAll containers in the Pod have passed their readiness checks
  • bAt least one container has been created and is executing
  • cThe Pod has been added to every Service's Endpoints that selects it
  • dThe Pod's containers have never restarted since creation
Explanation:Running only means the Pod has been scheduled and at least one container is up; it says nothing about readiness — a Pod can be Running with READY 0/1 if a container fails its readiness probe.
K8s Observability TroubleshootingDifficulty 1
$ kubectl get pod crash-pod
NAME        READY   STATUS             RESTARTS      AGE
crash-pod   0/1     CrashLoopBackOff   4 (37s ago)   3m

What does the CrashLoopBackOff status mean here?
  • aThe Pod could not be scheduled onto any Node in the cluster
  • bThe container's image could not be pulled from the registry
  • cThe Pod is waiting for a PersistentVolumeClaim to be bound
  • dThe container keeps crashing shortly after each restart
Explanation:CrashLoopBackOff means the container has crashed repeatedly and restartPolicy is causing kubelet to retry, but with a growing back-off delay between attempts rather than restarting instantly each time.
K8s Observability TroubleshootingDifficulty 2
A Pod's only container is defined with command: ["sh", "-c", "exit 1"] and restartPolicy: Always (the default). What happens right after the Pod is created?
  • aIt exits immediately with a non-zero code; kubelet restarts it, showing CrashLoopBackOff
  • bThe Pod stays in Pending because the command is invalid
  • cThe container starts once, exits, and the Pod phase becomes Succeeded since the command ran to completion
  • dkubectl rejects the manifest at apply time because the command has no long-running process
Explanation:Exiting with a non-zero code counts as a failure regardless of how quickly it happens; with restartPolicy: Always kubelet keeps restarting the container, and after a few consecutive failures the status shown becomes CrashLoopBackOff.
K8s Observability TroubleshootingDifficulty 2
$ kubectl describe pod oom-pod
    ...
    Last State:     Terminated
      Reason:       OOMKilled
    Restart Count:  3

What does Reason: OOMKilled tell you about why the container was terminated?
  • aThe container's liveness probe failed three times in a row
  • bThe node ran out of disk space while pulling the container's image
  • cThe container exceeded its configured memory limit and was killed
  • dThe container's process exited on its own with code 0
Explanation:OOMKilled is reported when the container exceeds its memory limit; the kernel's out-of-memory killer terminates the process, and kubelet reports this specific reason rather than a generic non-zero exit.
K8s Observability TroubleshootingDifficulty 1
What happens when a container's liveness probe fails repeatedly (past its failureThreshold)?
  • aThe Pod is removed from all Service Endpoints, but the container keeps running unchanged
  • bkubelet kills the container and restarts it according to the Pod's restart policy
  • cThe Pod is deleted and rescheduled onto a different Node
  • dKubernetes marks the Node as unschedulable
Explanation:A failing liveness probe tells kubelet the container is unhealthy and should be restarted; kubelet kills the container and starts a new instance in place, which increments the Pod's restart count.
K8s Observability TroubleshootingDifficulty 2
A readinessProbe keeps failing on a Pod behind a Service:
$ kubectl get pod readiness-fail-pod
NAME                 READY   STATUS    RESTARTS   AGE
readiness-fail-pod   0/1     Running   0          40s

$ kubectl get endpoints readiness-demo-svc
NAME                 ENDPOINTS   AGE
readiness-demo-svc               40s

What best explains this output?
  • aThe container has crashed and kubelet is about to restart it
  • bThe Pod failed to be scheduled onto a Node
  • cThe Service's label selector does not match the Pod's labels at all
  • dThe container is running but removed from the Service's Endpoints
Explanation:A failing readiness probe only affects traffic routing: the Pod stays Running with RESTARTS 0, but kubelet marks it not-ready, so the endpoint controller removes it from the Service's Endpoints until it passes again.

Test yourself against the 3375-question DevOps / Cloud bank.

Start interview