The network team applied a change last night. Since then roughly five percent of connections between your web subnet and your data subnet time out, the other ninety five percent are perfectly fine. It is intermittent and nobody can reproduce it on demand. Walk me through how you attack this.

The follow-ups they ask next

• Flow logs show nothing denied, yet connections still time out. Where do you look next?

  Look beyond NSGs: user defined routes, an appliance in the path, SNAT port exhaustion, or the destination refusing connections.

• The application team wants to add retries and move on. How do you respond?

  Agree retries buy time, but insist the fault is found, because five percent today is a hundred percent after the next change.

• How do you make this class of change safe next time?

  Network changes go through infrastructure as code with a plan diff, a canary subnet, and a synthetic connectivity test in the pipeline.

What the interviewer is listening for

• Treats five percent as a clue rather than acceptable noise
• Actively converts an intermittent fault into a deterministic one
• Knows subnet and NIC level rules combine into effective rules
• Leaves behind a synthetic probe so the next drift is caught early

What sinks the answer

• Papers over the failure with retries and moves on
• Asks what the change was supposed to do instead of reading flow logs
• Checks only one side of the connection
• Chases three hypotheses at once and cannot say which was disproved