DevOps interview questions

You will be asked which tools you have used, and those answers matter only as a filter. The round that decides the outcome is a scenario: a deployment is failing, a service is slow, a pipeline passed but production is broken. Work out why.

What is being assessed is method under ambiguity — whether you gather facts before theorising, and whether you know where to look. Candidates who jump to a suspected cause are the ones whose real incidents last for days.

Narrate the method rather than delivering an answer. The interviewer cannot score reasoning they did not hear, and a candidate who says what they would check and why is demonstrating exactly what the round exists to find.

Expect Linux and networking questions, because every diagnosis eventually lands there. A service cannot reach another service, a container will not start, a disk filled up. Tooling knowledge without this produces engineers who can build a pipeline and cannot fix it.

A common practical question: you have a shell on a machine running a failing service and no runbook — what do you check? Prepare an ordered answer covering process state, logs, ports, DNS resolution, disk and memory.

Have the order ready rather than the list. Checking whether the process is running before reading its logs, and whether the disk is full before suspecting the application, is the difference between a method and a set of commands.

• Reading logs and journald output under time pressure
• Which process holds a port, and whether it is listening where you expect
• DNS resolution end to end, including caching confusion
• Disk and inode exhaustion, and how they present
• Permissions and why a container cannot write where it expects

Questions here go beyond "have you used a CI tool". Expect: where do secrets live, how do artefacts move between environments, how do you roll back, and how do you know a rollback actually works.

The rollback question is the revealing one. Many teams have a documented rollback nobody has executed. Saying you test rollback deliberately — and describing a time it did not work — is a strong answer.

Expect a question about the deploy that passed CI and broke production. The answer worth giving is about what CI did not cover: real data volumes, a migration ordering, configuration that only exists in production, or a dependency that behaves differently there.

Expect state, drift and blast radius. What happens when someone changes a resource by hand, how you detect it, and how you apply a change safely to infrastructure that people are using.

A good preparation story is a change that destroyed and recreated something it should not have. Everyone who has used these tools seriously has one, and being able to explain how you now avoid it — plan review, targeted applies, lifecycle rules — shows the lesson landed.

The habit worth naming is treating any plan that proposes to replace rather than update a stateful resource as a stop condition. It is a small discipline that prevents the single most common self-inflicted outage in this discipline.

You will be asked what you monitor and how you know something is wrong. The weak answer is a list of metrics; the strong one connects metrics to user experience and describes an alert that would actually be acted on.

Be ready to talk about alert fatigue. An environment where everyone ignores alerts is a common real situation, and describing how you reduced noise — deleting alerts, tying them to symptoms rather than causes — demonstrates judgement more than any tool name.

Deleting alerts is the part candidates hesitate to say and the part interviewers want to hear. An alert nobody acts on is worse than no alert, because it trains the team to ignore the channel that the real one will arrive through.

If the employer runs Kubernetes, expect depth: scheduling, probes, resource requests and limits, why a pod is stuck in a particular state. If they do not, it may barely come up — so find out before over-preparing.

The question that separates users from operators is what happens when a pod fails a liveness probe under load, and how a too-aggressive probe can turn a slow service into a restart loop.

Resource requests and limits are the adjacent trap. Being able to explain that requests drive scheduling while limits drive throttling and termination, and what happens when a memory limit is hit versus a CPU one, marks out someone who has debugged a cluster rather than read about one.