MidTroubleshooting

Service A cannot reach Service B inside the cluster. Give me your diagnostic order.

What they are really testing: Whether you can bisect a network path methodically instead of checking things at random. The order matters more than the individual commands.

A real interview question

Service A cannot reach Service B inside the cluster. Give me your diagnostic order.

What most people say

drag me

I would check the network policies since that is usually the cause.

It may well be right, but jumping to a favourite cause is not a method. If it is not policy, the candidate has no second step, and the interviewer is specifically asking for the order of investigation.

The follow-ups they ask next

  • Connection refused rather than timeout. What does that eliminate?

    Almost all of the network path and policy, since packets clearly arrived and got a response. Focus on the target: is the process listening, on the right port, and on the right interface.

  • It works from pod IP but not through the service. Where is the fault?

    The service layer: selector not matching labels, wrong targetPort, empty endpoints because readiness fails, or kube-proxy or CNI issues on that node.

What the interviewer is listening for

  • Treats the error type as the first clue
  • Splits DNS from connectivity deliberately
  • Knows egress and ingress policies are separate

What sinks the answer

  • Jumps to a favourite cause
  • Tests from their own machine
  • No awareness of localhost binding

If you genuinely do not know

Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.

First [what is the actual error: refused, timeout, DNS or TLS, since each means something different]. Then [from inside pod A: resolve the name, then connect to the pod IP, which splits DNS from connectivity]. Then [is B serving: endpoints, readiness, bound to 0.0.0.0 not localhost]. Then [network policy on both sides, egress and ingress separately].

Keep going with troubleshooting

All 87 devops engineer questions

Knowing the answer is not the same as recalling it under pressure

Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.

Start free