DevOps interviews rarely ask for tool trivia. They describe a system under stress and ask what you would do: a deployment fails halfway, a service slows down every afternoon, or a disk fills up on a Friday night. The interviewer watches how you narrow the problem, what you check first, and whether you think about users, not just servers.
Answering in a way that scores
- Start by stating what you would measure before changing anything, since blind changes hide the real cause.
- Separate symptoms from causes out loud, so the interviewer follows your reasoning.
- Mention rollback explicitly: every change needs a way back, especially under pressure.
- End with prevention, such as an alert or a check that would catch the same failure earlier next time.
Practise with real incidents from your own work, even small ones. A true story told clearly beats a textbook answer.