1. What does a Pod represent?
A Pod is the unit Kubernetes schedules, containing one or more containers that share a context. Do not confuse a Pod with the durable identity of your application. When discussing a service, explain how replacement instances are created and how clients find healthy instances without depending on a particular transient Pod.
For this practice scenario, imagine three API replicas. One disappears while the other two serve traffic. Your answer should separate maintaining the desired workload from routing requests and preserving application data. A replacement Pod does not magically recover data that existed only in a lost instance's ephemeral storage.
2. A Pod is Pending. What do you inspect?
Start with the Pod's events and scheduling constraints, then inspect resource requests, node availability, placement rules, and storage attachment or provisioning where relevant. Do not immediately increase the replica count: that may create more instances with the same unsatisfied requirements. Distinguish a scheduling problem from a container that has already started and failed.
Our hypothetical workload requests more memory than any eligible node can provide. Lowering the request might make scheduling possible, but only if it remains consistent with measured application needs. Otherwise the apparent fix moves the problem into runtime instability. Explain whether you would adjust workload requirements, placement, or cluster capacity, and what evidence supports the choice.
3. What does CrashLoopBackOff tell you?
It indicates repeated container failures with delayed restart attempts; it is not the underlying cause. Kubernetes documents several possible causes, including application errors, configuration problems, resource constraints, and failed startup or liveness checks. Examine logs, termination details, and events to identify which explanation fits.
A useful interview response preserves the previous failed instance's evidence before changing the workload. Compare the first failure time with the rollout and configuration history. If a required secret key was renamed, the correction is to restore a valid configuration contract, not to increase restart frequency. State how you would confirm that recovery persists beyond one successful start.
4. How are readiness and liveness different?
Readiness concerns whether an instance should receive traffic; liveness concerns whether a running container needs restarting. A startup check can protect slow initialization from premature health judgments. Choose checks that represent the intended behavior rather than blindly pointing every probe at the same endpoint.
Suppose a shared database is briefly unavailable. Restarting every API instance may add connection pressure without repairing the database. Discuss whether that dependency belongs in a restart-triggering check and how the service should degrade. For a slow initialization problem, use measured startup behavior instead of continuously increasing timeouts with no explanation.
5. Healthy Pods exist, but requests still fail. Why?
Follow the request path from entry point to Service selection to target port to the application listener. Inspect whether the intended instances are selected and eligible for traffic. Then consider network policy, name resolution, and application-level errors. A green process indicator does not prove that the client's entire request path works.
For our exercise, the deployment changes a label but the Service selector remains unchanged. The application is healthy in isolation, yet the routing configuration no longer connects clients to it. Explain a targeted correction and a test from the same network context as the failing caller. Avoid declaring success solely because a direct local request works.
A rollout diagnosis you can explain aloud
Describe the symptom, blast radius, latest change, strongest evidence, and safest recovery action in that order. If a rollback is appropriate, verify that configuration and database changes remain compatible with the prior version. A rollback command is not a complete recovery plan when the new release changed an external contract.
Practise a ten-minute incident briefing with a peer or with Cluegent during preparation. Ask the interviewer to reveal one new fact at a time. You should update your hypothesis rather than defend your first guess. Finish by naming the alert or deployment check that would catch the same failure before the next rollout.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
Is CrashLoopBackOff the root cause?
No. It describes repeated failure and restart backoff. Logs, events, termination information, and configuration provide evidence about the cause.
Should every readiness failure restart the container?
No. Readiness and liveness have different purposes. Restarting for a shared dependency outage can make the incident worse.