DevOps Engineer interview questions
DevOps/SRE interviews test infrastructure, reliability, and incident response. Expect scenario questions on scaling, CI/CD and outages.
🎤 Practice these out loud with AceCoach →The questions
What devops engineers are tested on
What each round is really testing
A devops engineer loop is usually built from 5 kinds of question: System, Incident, Cost, Security, Behavioral. They are scored separately, which matters more than it sounds — being strong on the technical rounds does not offset a vague behavioural one, because a different interviewer writes that feedback against different criteria and never sees your other scores.
The framework under each question above is not a script to recite. It is the shape of a complete answer — the parts an interviewer is listening for and ticking off. Two candidates can give the same facts and score differently because one of them signposted the structure ("there were three constraints; let me take them in order") and the other produced the same content as an unstructured paragraph. Say the structure out loud; it is doing work.
Turning your own experience into answers
The most common preparation mistake is collecting questions and never building material. Your answers should come from your own work, and your resume is the index of it. Take a line like this one from the devops engineer resume example:
Architected Kubernetes migration (40 microservices, 200 pods) with canary deploys; deploy time 45min → 6min, rollback <2min, incident response 90min → 15min
A resume bullet is the result with everything else compressed out. An interview answer is the same story decompressed: what the situation was and why it mattered, what you specifically owned, what you tried that did not work, and only then the number. Expect the follow-up to go straight at the part the bullet omits — how you measured it, what you would do differently, who disagreed with you. Prepare the decompressed version of four or five bullets and you have covered most behavioural rounds.
A week of preparation that works
Days one and two: write the decompressed version of five pieces of your own work, each ending in something measured. Day three: rehearse them out loud — this is the step almost everyone skips, and it is where you discover that an answer clear in your head takes ninety seconds and three restarts to say. Days four and five: work the technical questions above, talking through your reasoning rather than solving silently. Day six: prepare your own questions, which are assessed whether or not anyone tells you so. Day seven: rest, and re-read your own notes rather than adding new material.
If you only have an evening, do the spoken rehearsal. It has the highest return per minute of anything on this list, and it is the part that cannot be improvised on the day. AceCoach will ask these questions aloud and score the structure of what you say back, which is the closest thing to the real conditions you can get on your own.
Before the interview
Check the company's format as well as the role's questions — the same devops engineer questions are asked very differently at a big-tech loop, an IT services process and a startup. See Big Tech, IT services & consulting or startups & finance. And make sure the resume that got you the interview can survive the questions it invites: everything on it is fair game, and the numbers attract the most scrutiny.
Earlier than the interview? How to become a devops engineer covers the routes into this role, what to learn in what order, and what it pays measured from live postings.
Frameworks are guidance, not scripts — the point is to make the answers your own. All roles →
Incident response: turning chaos into a story
Incident response questions are testing your thinking under pressure and how you prioritize when many things are failing at once. The question 'A service is down. Walk me through your first ten minutes' is structured to watch you make a series of quick calls without perfect information. The framework 'Acknowledge—assess blast radius—mitigate—communicate—root-cause' is the shape of a complete answer, and it's worth saying out loud because the interviewer is checking whether you've thought about the sequence. Most engineers jump straight to 'I'd restart the service' without first answering 'What's the blast radius? Is this impacting everyone or just some customers?' That skip costs time in a real incident.
What makes this concrete is specific language. Don't say 'I'd look at the logs'. Say 'I'd check our alerting dashboard to see which services triggered alerts in the last fifteen minutes, then tail the logs for the primary service to see error rates and traces'. That tells an interviewer you know your own stack. You've rehearsed this before. You know what your monitoring stack is and how to read it. If you hesitate or invent hypothetical tools during the interview, it signals inexperience. Rehearsing out loud before the interview catches this.
The ending matters as much as the beginning. After you've mitigated the immediate impact, what do you do? Do you declare it resolved? No. You commit to a postmortem—a blameless analysis of why it happened and what breaks it again. You might say 'We'd schedule a postmortem within 24 hours to understand the failure mode, then open tickets to prevent recurrence'. That tells an interviewer you've thought about learning from incidents, not just fighting fires. It also tells her you won't repeat the same outage three months later because you treated it as disposable.
Cloud cost thinking: from reactive to structural
The question 'You notice your cloud bill jumped 3x. How do you investigate?' tests whether you think about cost as a first-class problem or treat it as something to fix after it's alarmed. A DevOps engineer who thinks structurally says 'I'd check the cost breakdown by service and resource type first, because the driver matters. If it's compute, I'd look at instance count and size. If it's storage, I'd investigate unused snapshots and old buckets. If it's data transfer, I'd check egress patterns'. That process is not obvious—it requires having thought about where infrastructure costs actually hide. Most engineers assume compute, and that's the right instinct only half the time.
The specific tools and patterns matter because they show readiness. 'I'd use CloudTrail to find resource creation events and correlate them with the cost jump timestamp' is stronger than 'I'd look at what changed'. It names the tool, shows you know how to use it, and suggests you've debugged cost anomalies before. 'I'd check for unattached volumes and orphaned databases, because those are usually forgotten' is the pattern-matching an experienced engineer develops. That detail is what separates someone who's read about cost optimization from someone who's actually done it.
The follow-up is usually 'How would you prevent this in the future?'. The strong answer is structural, not reactive. Budget alerts, of course, but also autoscaling policies that trim unused resources, reserved instance planning, and spot instance usage for non-critical workloads. If you can name the levers available in your platform and have a theory about which ones matter most, you're showing cost discipline as a philosophy, not just a fix. That's the kind of thinking that lands you on teams where you own cost alongside reliability, not teams where you own reliability and apologize later.
On-call culture: what hiring managers are really listening for
When an interviewer asks 'Tell me about an outage you owned end-to-end', she's listening for three things that don't show up in your resume: whether you've actually been on-call and handled a production crisis, whether you learned something structural from it, and whether you communicate about post-mortems in a blameless way. The first is obvious—she needs to know you've been under pressure. The second is harder to fake: did you actually understand why it happened, or did you just restart a service and move on? The third separates healthy teams from unhealthy ones. If you blame a colleague, the interviewer hears 'this person doesn't learn from incidents; they protect themselves'.
A strong answer follows the STAR framework but emphasizes the learning. 'We had a database connection pool leak that manifested as intermittent timeouts. I recognized the pattern from connection pool monitoring, suggested reducing the connection limit as a short-term fix, and then built metrics and alerts for connection pool exhaustion so we'd catch it earlier next time'. That's the full cycle: immediate action, root cause, prevention. It also shows you were watching the right metrics, which is a DevOps skill often underdeveloped in teams that solve problems by restarting things. Anticipating failure is harder than fighting fire, and an interviewer listening for structural thinking hears the difference.
What you don't want to do is blame infrastructure, the previous team, or time pressure. 'We were under-resourced' is an explanation, not a solution. 'Our monitoring was insufficient' is an acknowledgment without action. The strong move is to own the outcome, name what you'd do differently, and show that you shipped the fix or learned something you brought to your next role. Saying 'I'd do the same thing again' or 'There was nothing I could have done' signals you haven't thought deeply. If you've really owned an incident end-to-end, you've almost always found something to improve.
Frequently asked questions
I've never owned a major outage. Should I invent one for my interview story?
No. Use a smaller incident you've handled well or a time you've owned a deployment that required careful rollback planning. The scale doesn't matter as much as showing you think through the sequence and learn from problems.
How detailed should I get when describing incident response?
Detail enough that an interviewer could follow you into a real incident. 'I'd check the logs' is too vague. 'I'd tail the application error log with a filter for the past 30 minutes' is useful. She's listening for whether you'd be calm and methodical under pressure.
What if my incident response involved a tool or service the company doesn't use?
Name the tool you used and the class of problem it solved. 'We used Datadog for observability and I'd correlate error rate spikes with service deployments' translates to any monitoring platform. The principle is portable; the tool is context.
Should I mention metrics or SLOs I helped set during incident response?
Yes, if you actually did. 'We set an SLO of 99.5% availability and used incidents to tighten our alerting thresholds' shows thinking beyond the immediate fix.
How do I answer if I haven't used the specific cloud platform they use?
Talk about the concepts (instance types, scaling policies, spot instances) and observe that the specifics vary by platform. Interviewers expect DevOps engineers to learn new platforms, so they listen for the principles.