DevOps engineer interview questions and answers (UK, 2026)
The incident, pipeline and infrastructure questions UK DevOps interviews really ask, and how to show judgement beyond tool checklists.
What interviewers are really assessing
The interviewer, usually a platform lead or engineering manager, is testing what you do when production is down and when it is quietly rotting: the 3am incident question is near-universal because it exposes diagnostic method, composure and honesty at once, and the follow-ups probe whether your post-mortems actually changed anything. Tool questions (Kubernetes, Terraform, your CI system) are entry stakes; the differentiators are judgement questions: what you would not automate, when you would say no to a deploy, how you balance developer velocity against the blast radius you are enabling, and whether you treat cost as an engineering dimension. Expect scepticism toward buzzword fluency: claiming Kubernetes depth invites a probing question about debugging a CrashLoopBackOff or a node pressure eviction, and claiming IaC discipline invites questions about state file disasters and drift. Security-in-the-pipeline questions (secrets handling, image scanning, least privilege) are now standard, and the team-fit round tests the trait the discipline exists for: whether you make other engineers faster and safer rather than becoming the bottleneck with root access.
DevOps Engineer interview questions and model answers
For each question: why it is asked, and the structure of a strong answer. Adapt the worked examples to your own experience; interviewers follow up, so never borrow a story.
1. Tell me about a production incident you owned: detection to resolution to post-mortem.
Why they ask it: Incident behaviour is the job's core competency, and the story's specifics reveal your real depth faster than any tool quiz.
Pick an incident with diagnostic meat and walk the timeline: how it was detected (an alert on error rate or saturation, ideally, a customer report, honestly, if that is the truth), triage: establishing blast radius and communicating early (status channel, stakeholders told what you know and when the next update comes), the diagnosis path with the actual tools (logs correlated by request ID, metrics dashboards, a recent deploy as first suspect), mitigation before root cause: rollback, feature flag off, scale up, and the fix. Then the post-mortem: blameless, with actions that shipped: an alert added, a runbook written, a deploy gate introduced. Numbers (time to detect, time to mitigate) and the honest mistake in the middle make it credible.
2. Design a CI/CD pipeline for a service from commit to production. Where does it break, and what guards what?
Why they ask it: Pipeline design shows whether you think in failure modes and feedback loops or just chain tools together.
Structure the stages with purpose: fast feedback first (lint, unit tests, build, in minutes because slow pipelines get bypassed), then integration tests against real dependencies where feasible, artefact built once and promoted (never rebuilt per environment), security gates woven in (dependency and image scanning, secrets detection), deploy to staging, then production with progressive delivery: canary or rolling with automated rollback on error-rate regression, and observability confirming the deploy rather than hoping. Name the failure modes you design against: flaky tests destroying trust in the pipeline, environment drift making staging a lie, the emergency bypass path that becomes the normal path. The closing judgement: the pipeline's job is making the safe path the fastest path, and any gate that costs more confidence than it buys gets rethought.
3. How do you run infrastructure as code with discipline: state, drift, review, and the disaster stories?
Why they ask it: IaC claims are universal; the interviewer probes for the operational discipline and scars that prove production experience.
Show the working practices: everything in code with review (infrastructure changes as pull requests with plan output attached, so reviewers see the blast radius), remote state locked and backed up (and the story of why that matters: a corrupted or conflicting state file is a genuinely bad day), drift detection because console cowboys exist, modules for the repeated patterns with versioning, and environments from the same code with different variables, not divergent copies. Include a real scar: the terraform apply that wanted to destroy a database because of a resource rename, caught in plan review, or a state surgery you performed with sweat. The judgement layer: what you deliberately do not codify (one-off investigation resources, break-glass changes with a paper trail) and how manual changes get reconciled rather than accumulating as drift.
4. What does good observability look like, and tell me about a problem your monitoring caught before customers did.
Why they ask it: The discipline's promise is finding problems before users report them, and the interviewer tests whether your setup ever actually did.
Show the layered model: metrics for the system's vital signs organised around what users experience (latency, errors, saturation: SLO-shaped rather than a dashboard of everything), logs structured and correlated (request IDs threading a transaction across services), traces for the "which hop is slow" question, and alerts designed against fatigue: paging only on symptoms customers would feel, with everything else as tickets or dashboards. Then the required story: a disk filling trend caught days out, an error rate creeping after a dependency update, a certificate expiry alert that prevented an outage, with what the alert was and why it existed. Include the anti-pattern honestly: an alert channel everyone muted, and how you pruned it. Alert quality over alert quantity is the judgement being tested.
5. A team wants to deploy fast and often; you can see their service has no tests worth the name and no rollback story. What do you do?
Why they ask it: Velocity versus safety is the discipline's central negotiation, and the answer reveals whether you are an enabler, a blocker, or a doormat.
Show the enabling posture with a line: the goal is their velocity made safe, not their velocity prevented, so you meet them where they are: rollback capability first because it converts every future mistake from an incident into a blip (automated rollback on the deploy path, feature flags for risky changes), a minimal test gate that catches the embarrassing failures without demanding a testing culture transplant overnight, and progressive rollout so blast radius is contained while confidence builds. Name your actual line: no production deploys without a rollback path, stated as protecting them, with the incident math to back it. A real example of taking a team from scared monthly deploys to confident daily ones, with what you built and what you insisted on, is the strongest possible answer.
6. How do you handle secrets and pipeline security: what does a compromised CI system get access to in your world?
Why they ask it: CI systems are a prime attack path, and supply-chain incidents have made pipeline security a standard screen.
Show threat-aware practice: secrets in a vault or the platform's secret store, never in code, config files or pipeline logs (and masked in output), short-lived credentials over long-lived keys (OIDC federation from the CI system to the cloud provider beats a stored admin key), least privilege per pipeline (the docs site's pipeline cannot touch the production database), and the supply chain layer: dependencies and base images scanned, artefact provenance, and third-party actions or plugins treated as the attack surface they are. Answer the question's scenario directly: map what your current CI could reach if popped, and the blast-radius reductions you have made or would make. A story of rotating everything after a leaked credential, and what the post-mortem changed structurally, demonstrates the paranoia the role now requires.
7. Your cloud bill grew 40 percent in six months. Walk me through what you would actually do.
Why they ask it: Cost has become an engineering dimension, and interviewers increasingly test FinOps instincts alongside reliability ones.
Show the method: visibility first (cost allocation by tags, team and service, because an unattributed bill cannot be managed), find the drivers (the usual suspects: over-provisioned compute, orphaned resources and unattached volumes, data transfer surprises, logging and observability ingestion growing quietly, non-production environments running nights and weekends), then the actions ranked by effort against saving: scheduling non-prod down, right-sizing from actual utilisation data, storage lifecycle policies, and commitment discounts (reserved instances, savings plans) once usage is understood, not before. The cultural layer matters: cost visible to the teams spending it, in their dashboards, so it self-corrects. A real number ("I cut a client's bill 30 percent, mostly dev environments and log retention") beats methodology recitation.
8. Why platform and DevOps work rather than pure development, and why this company's stack and stage?
Why they ask it: Motivation and fit questions test whether you understand the service nature of the role and whether their environment will hold you.
Ground the role motivation honestly: liking the force-multiplier position (your work makes every engineer faster), the systems thinking, the production reality where architecture meets 3am truth, and if you came from development or ops, what pulled you across. For the company: their actual context: stack (their cloud, their orchestration, what you know of it from the advert or engineering blog), stage (a scale-up building platform foundations offers different problems from an enterprise migrating legacy), and team shape: are you the first platform hire or joining an established team? Asking about their current pain (deploy frequency, incident load, what the platform roadmap looks like) shows you are evaluating the problems, which is exactly what strong platform engineers do.
Questions to ask them
Asking nothing reads as low interest. These three work because they show you understand the role’s reality, and their answers tell you whether you want the job:
- What does the incident load actually look like: pages per week, and what did the last serious post-mortem change?
- What is the current deploy story: frequency, confidence, rollback, and what is the platform roadmap trying to fix first?
- How does the on-call rota work, how is it compensated, and how is out-of-hours load trending?
Practise out loud, not in your head
Reading model answers feels like preparation, but interviews are spoken: the first time you say an answer aloud should not be in the room. Rehearse each story out loud until it flows without sounding scripted. If you want a realistic run-through, Vouch’s AI coach Maya runs voice mock interviews built from a real job advert and your own CV, and gives feedback per question, which is the closest thing to the actual experience you can do from your sofa.
And since a strong interview starts with getting invited: the free cover letter generator writes a UK-format letter from your real experience, and the UK personal statement guide covers the 50-80 words at the top of your CV that decide whether it gets read.
Frequently asked questions
How should I prepare for a DevOps engineer interview?
Prepare three war stories with timelines and numbers: a production incident you owned end to end, a pipeline or infrastructure improvement with measurable impact, and a security or cost win. Refresh the debugging paths for your claimed tools (Kubernetes failure modes, Terraform state issues) because claims get probed. Read the company's engineering blog and job advert for their stack, and have honest answers about what you have not run in production.
What format do UK DevOps interviews take?
Typically three or four stages over two to four weeks: a screen, a technical deep-dive on your experience and scenarios (incidents, pipeline design, infrastructure decisions), often a practical element: a take-home exercise, a live troubleshooting scenario, or whiteboard architecture, then a team and manager round covering on-call, collaboration and fit. Some companies test live in a sandbox environment; others rely on depth of follow-up questioning against your stories.
How do I answer the salary question in a DevOps interview?
Benchmark by market and depth: London, fintech and contract rates run well above regional permanent norms, and genuine production Kubernetes, cloud architecture and security-adjacent skills command premiums. Give a researched range anchored to your evidence: the scale you have operated (traffic, cluster count, team size served), and incidents and migrations owned. Ask how on-call is compensated separately, because a salary that silently includes a heavy rota is a lower salary than it looks.