These DevOps interview questions cover the work the job really involves: debugging systems under pressure, shipping changes safely, and keeping infrastructure in code. They're written for hiring managers and senior engineers running a technical round, and for candidates preparing for one. Each question notes what a strong answer includes, and some add a red flag. You don't need all 21. Pick a mix that fits your stack and level, and push on "how would you know?" after each answer, because measuring and verifying is half the job.
What a strong DevOps interview checks
- Systems debugging: a calm, ordered way to find where a problem lives, from the kernel to the load balancer.
- Containers and orchestration: how images, pods, probes and resource limits behave when things fail.
- Infrastructure as code: managing state, drift and reviews so changes are repeatable.
- Safe delivery: pipelines, rollout strategies and rollbacks that keep users unaffected.
- Observability and incidents: useful alerts, SLOs, and leading a response without panic.
- Security habits: secrets, least privilege and supply chain basics built in, not bolted on.
DevOps interview questions: Linux, networking and containers
1. A Linux server suddenly feels slow. What do you check first?
What good looks like: a method, not random commands. They check load average against CPU count (uptime, top), memory and swap (free -m, vmstat), disk wait (iostat), disk and inode space (df -h, df -i), open connections (ss), and the kernel log for the OOM killer (dmesg). Strong candidates mention a framework like USE (utilization, saturation, errors).
Red flag: "I'd reboot it" before looking at anything.
2. A user says the site won't load. Trace the request and tell me where it can break.
What good looks like: DNS resolution (and TTLs), the TCP or QUIC connection, the TLS handshake and certificate, the load balancer, the reverse proxy, and the app and its dependencies. For each step they name a check, such as dig, curl -v or openssl s_client.
3. How is a container different from a virtual machine?
What good looks like: containers share the host's kernel and are isolated with namespaces and cgroups, while a VM runs its own kernel on a hypervisor. Containers start faster and pack more densely, but the isolation boundary is weaker, which matters for untrusted workloads.
4. How do you keep a Docker image small and safe?
What good looks like: multi-stage builds, a slim or distroless base, pinned versions, a non-root user, and a .dockerignore. They order layers so dependency installs are cached (copy the lockfile and install before copying source), scan images in CI, and pass build secrets with --mount=type=secret.
Red flag: putting secrets in ENV or ARG, where they end up in the image history.
Kubernetes and infrastructure as code
5. A pod is in CrashLoopBackOff. Walk me through debugging it.
What good looks like: kubectl describe pod for events and the last state, then kubectl logs --previous for the crashed container. They read the exit code: 137 means the process got SIGKILL, often because it was OOMKilled. They also check failing probes, missing ConfigMaps or Secrets, and a wrong command or entrypoint.
Red flag: deleting the pod over and over and hoping.
6. What's the difference between liveness, readiness and startup probes?
What good looks like: a failing readiness probe removes the pod from Service endpoints but doesn't restart it. A failing liveness probe restarts the container. A startup probe holds off the other two until a slow app has started.
Red flag: a liveness probe that checks the database, so one database blip restarts every pod at once.
7. Explain resource requests and limits.
What good looks like: the scheduler places pods based on requests. Limits cap usage: a container over its CPU limit gets throttled, while one over its memory limit gets killed. Strong candidates discuss the trade-off of tight CPU limits causing latency from throttling, and why missing requests make autoscaling and scheduling unreliable.
8. How does the Horizontal Pod Autoscaler decide how many replicas to run?
What good looks like: it compares a metric to a target and scales by the ratio: desired replicas equal current replicas times current value divided by target value, rounded up. CPU utilization targets are a percentage of requests, so requests must be set. They mention custom metrics and the scale-down stabilization window that stops flapping.
9. What is Terraform state, and how do you protect it?
What good looks like: state maps your code to real resources. Keep it in a remote backend with locking so two applies can't collide, encrypt it, and restrict access, because it can hold secrets. Recent Terraform versions can lock state directly in an S3 backend, without a separate DynamoDB table. They may mention OpenTofu, the open-source fork, which works the same way.
Red flag: state files committed to git.
10. Someone changed a firewall rule by hand in the cloud console. How do you find and handle that drift?
What good looks like: a scheduled terraform plan in CI shows the difference. Then decide with the team whether the change was right (update the code) or wrong (apply to revert). Long term, limit console write access so code is the only path to change.
CI/CD and releases
11. Design a pipeline from commit to production for a web service.
What good looks like: build once and tag an immutable artifact with the commit SHA. Run linting, unit tests and security scans, deploy to staging, run integration tests, then promote the same artifact with a gradual rollout and automatic rollback if error rates rise.
Red flag: rebuilding the image separately for each environment.
12. Compare rolling, blue-green and canary deployments.
What good looks like: rolling replaces instances gradually and is cheap. Blue-green keeps two full environments and switches traffic at once, so rollback is fast but capacity doubles. Canary sends a small share of traffic to the new version and watches metrics before going further. All of them need backward-compatible database changes.
13. How do you change a database schema without downtime?
What good looks like: the expand and contract pattern. Add the new column or table, deploy code that writes to both, backfill, switch reads, and only then remove the old structure in a later release. Each step can be rolled back on its own.
14. Where should secrets live, and how should CI get them?
What good looks like: in a secrets manager, never in git. CI should get short-lived cloud credentials through OIDC federation instead of storing long-lived access keys. They know Kubernetes Secrets are only base64-encoded by default, so encryption at rest needs to be turned on.
Observability and incidents
15. Explain SLIs, SLOs and error budgets.
What good looks like: an SLI is a measure such as the share of requests that succeed fast enough. An SLO is the target, for example 99.9% over 30 days, which allows about 43 minutes of failure. The error budget is that allowance. When it runs low, the team slows releases and fixes reliability.
16. What makes an alert worth waking someone up for?
What good looks like: it signals real user impact (symptoms such as error rate or latency), needs human action now, and links to a runbook. Causes like high CPU go on dashboards, not pagers. They also mention metrics, logs and traces working together, often instrumented with OpenTelemetry.
17. You're paged at 2 a.m.: error rate jumped to 20% right after a deploy. What do you do?
What good looks like: mitigate first. Roll back or turn off the feature flag, confirm the error rate recovers, and post a status update. Investigation comes after users are safe. For a bigger incident they name roles: someone leads, someone communicates, someone digs.
Red flag: debugging live in production for an hour before rolling back.
18. What does a good postmortem include?
What good looks like: blameless language, a timeline, impact, contributing factors, and a small number of action items with owners and dates. Strong candidates care whether the actions actually get done.
Behavioral (STAR)
19. Tell me about an outage you caused or helped fix.
What good looks like: the Situation and impact, their exact role, what they did minute by minute, and a Result that includes a lasting change such as a new alert, test or guardrail. They own their part plainly.
20. Describe a time you automated away repetitive work.
What good looks like: they measured the toil first (hours a week, error rate), built something maintainable, got others to adopt it, and can show the time saved.
21. Tell me about a time you pushed back on a release.
What good looks like: they had specific evidence of risk, proposed a safer path (a smaller rollout, a fix first), and handled the disagreement without becoming the team's blocker.
Red flag: every story ends with them being the only one who cared about stability.
A simple scoring rubric
Running this interview with AI
A first DevOps screen is mostly about whether someone has done the work, and an adaptive AI interviewer can check that before your senior engineers spend an hour. NTRVSTA's exam library includes DevOps tools, and the interviewer raises or lowers the difficulty based on each answer, so a candidate who nails CrashLoopBackOff gets pushed on autoscaling and drift. System-design questions come with an interactive whiteboard, which suits "design a pipeline" prompts. Behavioral questions use STAR, and a hint system shows how a candidate reacts when nudged.
The report gives a score breakdown and video snippets of key moments, so the hiring manager can jump straight to the incident story. Read how AI interviews are scored and our roundup of AI interview software before choosing a tool. Related question sets: system design, backend developer, Python and data engineer.
Questions
Should a DevOps interview include a hands-on lab?
A short one helps, as long as it is realistic. A broken container or a failing pipeline that the candidate debugs while talking you through it shows more than trivia. Keep it under an hour and allow normal documentation, since nobody memorizes every kubectl flag.
Which cloud provider should the questions target?
Ask about concepts first: networking, identity, state, scaling and failure. Then ask how the candidate did it on whatever cloud they used. A strong engineer who knows one cloud well picks up another in weeks, so do not reject people over provider names alone.
How do DevOps, SRE and platform engineering interviews differ?
The core overlaps. SRE loops lean harder on reliability math, SLOs and incident response. Platform roles lean on building internal tools and paved paths other developers use. DevOps roles often sit in the middle, with more CI/CD and infrastructure as code. Weight the sections on this page to match.
Want to watch an AI interviewer push a DevOps candidate from basics to harder follow-ups? Grab a 20-minute demo slot, or run a sample interview on yourself.
