DevOps Interview Questions for SRE and Platform Roles
On this page
Hiring for DevOps, SRE, or platform engineering is hard because the title means something different at every company. The best DevOps interview questions cut through the buzzwords and probe how a candidate actually reasons about pipelines, clusters, infrastructure, and failure. This guide gives you a curated, evaluator-grade bank of questions with model answers you can ask in real interviews.
TL;DR: Thirty-six DevOps interview questions across CI/CD, containers and Kubernetes, infrastructure as code, observability, networking and security, and SRE practices — each with a model answer and difficulty rating. Skip to the end to import the whole set into Intervy in one click.
A good interview measures depth of reasoning, not trivia recall. Use these questions as conversation starters, then follow the answer wherever it leads — the model answers below are what a strong candidate covers, not a script to read aloud. A few principles for running a fair, structured technical interview: probe for trade-offs rather than definitions (anyone can recite what a canary deployment is; a senior candidate explains when it is the wrong choice), mix difficulty deliberately, and ask the same questions across every candidate so you can actually compare them. If you are also hiring application engineers, pair this with our backend developer interview questions and the broader complete guide to technical interviews.
CI/CD and automation questions
Pipelines are where DevOps candidates either shine or reveal they have only ever clicked "deploy." Start with definitions, then push into the operational reality of keeping a pipeline fast and safe.
Key takeaway: The strongest signal here is not tool knowledge — it is whether the candidate treats the pipeline as a product with its own reliability, speed, and security requirements.
Sample question — continuous delivery vs. deployment. Ask the candidate to distinguish continuous integration, continuous delivery, and continuous deployment, then where they would put a regulated product. A strong answer separates the automated path (CI through delivery) from the human gate, and ties continuous deployment to a hard prerequisite: high test confidence plus fast rollback.
Sample question — keeping pipelines fast. What a strong answer covers: caching dependencies and build layers, parallelism and test sharding, running only the projects affected by a diff in a monorepo, failing fast on cheap checks, and treating pipeline duration as a tracked metric rather than a one-off fix.
A practical hands-on question is to have them sketch a minimal pipeline:
name: ci on: push: branches: [main] jobs: build-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 cache: npm - run: npm ci - run: npm run build - run: npm test
The follow-up — "now publish a versioned artifact" — separates the candidates who gate the publish step on a successful build and scope its credentials to least privilege from those who would happily publish from a red pipeline.
Containers and Kubernetes questions
Containers are table stakes; Kubernetes is where you find out whether someone has operated a cluster or only read about one. Push past definitions into debugging and resource behavior.
Sample question — images vs. containers. A warm-up. What a strong answer covers: the image is an immutable layered template, the container is a running instance with a thin writable layer, and container state is ephemeral unless persisted with volumes.
Sample question — liveness vs. readiness probes. What a strong answer covers: liveness restarts a hung container; readiness pulls a pod out of the Service endpoints without restarting it; you need both because a pod can be alive but not ready. The killer follow-up is what happens with a too-aggressive liveness probe:
readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: httpGet: path: /livez port: 8080 initialDelaySeconds: 30 periodSeconds: 15
A candidate who has felt the pain will tell you an over-eager liveness probe creates restart loops under load — the app is fine but slow, gets killed, and the restart makes everything worse — and will reach for a startupProbe.
The best Kubernetes signal of all is a debugging question. Ask how they would investigate a pod stuck in CrashLoopBackOff:
kubectl describe pod <pod> # events: image pull, OOMKilled, probe failures kubectl logs <pod> --previous # logs from the crashed instance kubectl get pod <pod> -o yaml # last state, exit code, restartCount
Key takeaway: Strong operators lead with evidence — the previous container's logs and the exit code — and distinguish a config problem (fix the manifest) from a code problem (fix and redeploy). Weak ones start guessing and restarting things.
Infrastructure as code questions
Infrastructure as code is where you separate people who have run terraform apply on a team from those who have only done it solo. The danger areas are state, drift, and environment isolation.
Tip: Listen for whether the candidate talks about who else runs the tooling. Solo IaC and team IaC fail in completely different ways, and only one of those matters for the job.
Sample question — Terraform state. What a strong answer covers: state maps configuration to real resource IDs so the tool can compute a diff; on a team you need a remote, versioned, encrypted backend with state locking. The follow-up — two engineers running apply at once — should immediately produce the words "state locking," because without it the two runs race and corrupt the state file.
Sample question — configuration drift. What a strong answer covers: drift is the gap that opens when someone fixes production by hand instead of through code, and the fix is enforcement plus detection — IaC as the single source of truth, regular plan runs that alert on any diff, immutable infrastructure, and restricted console access.
For multi-environment structure, a strong candidate avoids copy-paste and reaches for modules plus isolated state:
terraform apply -var-file=prod.tfvars
They will also warn you that workspaces alone are weak isolation for production — same code path, one typo away from applying to the wrong environment — and that prod should require review before any apply.
Observability, incident response, and SRE questions
This is the heart of an SRE interview: can the candidate keep a system healthy, and stay calm when it is not? Cover the measurement side, the human side of incidents, and the reliability math.
Sample question — the four golden signals. What a strong answer covers: latency, traffic, errors, and saturation — and the insight that you alert on symptoms users feel, not on every underlying cause.
Sample question — monitoring vs. observability. What a strong answer covers: monitoring watches known thresholds and tells you that something is wrong; observability lets you ask new questions and understand why, built on metrics, logs, and traces. Look for an appreciation that structured logs are what make logs queryable in the first place:
{"level":"error","ts":"2026-06-19T10:02:11Z","msg":"db query failed","request_id":"abc123","latency_ms":842}
Sample question — running an incident. What a strong answer covers: acknowledge and assess impact, establish an incident commander and a dedicated communicator, and — critically — mitigate before diagnosing. In the first five minutes the question is "what changed recently?", because most incidents trace to a deploy or config change and reverting it is the fastest fix.
The reliability vocabulary matters too. A candidate should connect SLIs, SLOs, and SLAs and explain the error budget that falls out of them — for example, expressing an availability target the way an SRE thinks about it:
// 99.9% over 30 days ≈ 43m of allowed downtime — the error budget. const monthlyBudgetMinutes = (1 - 0.999) * 30 * 24 * 60
Key takeaway: The senior answer is that 100% reliability is an explicit non-goal — the error budget turns "be more careful" into a number everyone can act on, and a blameless postmortem turns the incident into systemic fixes instead of blame.
Running these DevOps interview questions in Intervy
A question bank is only half the job. The other half is asking the same questions consistently and scoring answers the same way across every candidate and every interviewer — which is exactly what a technical interview platform is for.
Tip: The fastest way to make interviews fair is to stop reinventing them. Build the template once, reuse it for every candidate in the pipeline, and compare like for like.
Here is how this set maps onto Intervy as a structured interview tool:
- Question bank. Store every question with its Markdown model answer and syntax-highlighted code, organized by color-coded category and tagged by difficulty so you can filter to exactly the round you are running.
- Reusable interview templates. Assemble a "DevOps screen" or "SRE on-site" template, drag-and-drop to reorder, duplicate it per role, and filter by category as you build.
- 1–5 scoring, keyboard-first. In live interview mode each question shows a 1–5 rating scale from Strong No to Strong Yes with an auto-saving comments field — rate with the number keys and move with the arrows without breaking eye contact.
- Color-coded review. Afterward, each question's rating and comments roll up into green/yellow/red score cards, so a hiring panel can compare candidates at a glance instead of arguing from memory.
As an interview scoring tool it keeps the rubric attached to the question, so the bar stays the same whether it is you or a teammate in the room. Core interview management is free, and every account starts with 300 free AI credits if you later want an AI question generator or AI-drafted summaries. Prefer your own provider? Connect your own AI key and those requests go straight to it.
Getting started with these DevOps interview questions
Strong DevOps interview questions are wasted if every interviewer asks a different subset and scores on instinct. Put these into a shared template, agree on what a 5 looks like, and you will get comparable signal from every conversation.
Key takeaway: Curate once, reuse everywhere, and score on a consistent 1–5 scale — that is the whole difference between gut-feel hiring and a structured process.
Three quick steps to go from this page to your next interview:
- Import the set. Load the 36 questions below straight into your question bank — no retyping.
- Build a template. Pick the categories for the round you are running and drag them into order.
- Score live. Rate each answer 1–5 with comments, then review the color-coded cards as a panel.
All 36 questions are also available as a ready-to-import set in Intervy. Head to the Export / Import page, select "DevOps Interview" from the Sample Interview Data dropdown, and click Load — organized by category, tagged by difficulty, and ready to drop into your next interview template.