DevOps Interview Questions and Answers

A single DevOps loop can touch Linux internals, networking, containers, Kubernetes, Terraform, CI/CD, a cloud provider, and monitoring — and no interviewer expects mastery of all of it. Junior candidates are tested on fundamentals — Linux, git, basic scripting, what a container actually is — plus evidence they can learn fast. Mid-level candidates must wire systems together and debug them: read a pipeline, explain how a request reaches a pod, fix a broken deploy. Senior candidates are graded on judgment — architecture trade-offs, blast-radius thinking, incident command, and the ability to say what they would not build. The same question escalates cleanly: a junior defines a rolling update, a mid-level engineer explains how readiness probes gate it, and a senior explains when they would choose canary instead and which metric triggers the rollback.

The most reliable seniority tell is diagnostic order. Strong candidates state what they would check first and why, name the exact command, and interpret its output before moving on; weak candidates list every possible cause in no particular order. The second tell is honest scoping: "I have not run Istio in production, but here is how I would evaluate it" consistently outscores a bluffed answer, because interviewers probe one level deeper than whatever you claim.

Most loops follow the same shape. A recruiter screen checks logistics and rough fit. A technical phone screen of 45 to 60 minutes mixes rapid-fire fundamentals — Linux, networking, containers — with a small scripting exercise. Then comes some form of hands-on round: a live troubleshooting session in a deliberately broken environment, a take-home that builds a small pipeline, or pair-debugging with an engineer. Mid and senior loops add an infrastructure design round — "design the deployment platform for fifty microservices" on a whiteboard — and every loop ends with behavioral interviews with the hiring manager and future teammates.

The mix varies by company: startups lean on the hands-on round, larger companies weight design and behavioral more heavily, and a few add an algorithms round borrowed from their software loop. Ask the recruiter exactly what each session covers — they will tell you, and preparing for the actual format is worth more than another week of general review. The sections below map to the rounds: fundamentals for the screen, the domain sections for the deep dives, the scenario section for the hands-on, and the behavioral section for the close.

Every DevOps screen tests Linux, because everything else runs on it. Expect processes and signals (what SIGTERM versus SIGKILL means for graceful shutdown), filesystems and permissions, systemd (systemctl status, journalctl -u), networking basics (ss -ltnp, ip a, curl -v), and resource triage (top, df -h, free -h). The questions are rarely exotic; the bar is fluency — the interviewer watches whether ss or lsof comes out unprompted when they say "something is already listening on 8080".

Scripting is the other filter. You will parse a log, glue two APIs together, or automate a cleanup — in bash or Python, your choice, and the choice itself is a talking point: bash for short glue, Python once logic or error handling gets real. Safe-bash idioms (set -euo pipefail, quoted variables, trap for cleanup) mark practitioners. Write scripts during prep rather than reading about them; the muscle memory is the deliverable. The scripting questions below — the log pipeline, the pipefail question, cron debugging — are the exact shapes screens reuse.

Container questions start below Kubernetes: image layers and caching, CMD versus ENTRYPOINT, multi-stage builds, why PID 1 signal handling matters, and what namespaces and cgroups actually isolate. Get these right and the Kubernetes conversation goes better, because half of pod debugging is container fundamentals wearing YAML. The questions below cover that Docker layer plus cluster architecture — the control plane components and how they cooperate — which the deeper guides assume.

Kubernetes itself is deep enough that we keep two dedicated guides. Our guide to Kubernetes Interview Questions and Answers covers the full object model — Deployments, Services, probes, RBAC, requests and limits, multi-tenancy — with model answers pitched at each seniority level. Our Kubernetes Troubleshooting Interview Questions guide walks the fix-it-live round: CrashLoopBackOff, Pending pods, OOMKilled, broken Services, and the describe/events/logs workflow that senior interviews are won on. If the job description says Kubernetes, work both after this page.

IaC questions test two layers. The conceptual layer — why declarative beats imperative, what idempotency guarantees, why immutable infrastructure kills configuration drift — frames every answer and is covered in the questions below. The tool layer is almost always Terraform: state and locking, plan versus apply discipline, modules and environment layout, drift and import. Interviewers use Terraform as a proxy for whether you understand desired-state systems in general, which is the same mental model Kubernetes controllers run on.

Our Terraform Interview Questions and Answers guide holds the deep bank — state file internals, remote backends and locking, count versus for_each, import blocks, secrets in state, lock files, and running plan and apply safely in CI — each with model answers and current-version syntax. Work it if the JD names Terraform, OpenTofu, or infrastructure as code generally; the state-management questions in particular separate candidates who have run Terraform on a team from tutorial graduates.

Pipeline questions probe whether you can design safe, fast delivery: which stages a pipeline needs and in what order, why you build an artifact once and promote that same artifact through environments, how tests and security scanning gate promotion, and how deployment strategies — rolling, blue-green, canary — trade speed against risk. Git fluency is the substrate: merge versus rebase, branching strategy, and why trunk-based development pairs with continuous delivery all get tested directly.

Our CI/CD Interview Questions and Answers guide covers the deep end: GitOps and the pull-based model, Argo CD versus Flux, secrets in pipelines, supply-chain security, rollback design, and pipeline performance — the material platform-team loops spend most of their time on. On this page, the git and pipeline-design questions below cover the breadth layer that every DevOps loop touches even when the role is not pipeline-focused.

Nearly every JD names a cloud, and AWS is the most common. Interviewers test whether you can make provider-level judgments: which compute abstraction fits (EC2, ECS, EKS, Lambda), how IAM least privilege actually gets implemented, how a VPC is laid out and what security groups do, and how to reason about cost without hurting reliability. Provider-agnostic judgment — the shared responsibility model, horizontal versus vertical scaling, multi-AZ thinking — is tested even when the company runs GCP or Azure, and those questions are below.

Our AWS DevOps Interview Questions and Answers guide goes deep on the AWS-specific layer: ECS versus EKS, IRSA and Pod Identity, security groups versus NACLs, why iam:PassRole is dangerous, Auto Scaling groups, cost reduction, and worked scenario debugging like a post-deploy p99 spike. If the role is AWS-flavored, treat that guide as required reading; the judgment transfers to the other clouds with different nouns.

Reliability questions appear in every DevOps loop, not just SRE-titled ones. The baseline: what you would monitor on a new service (the four golden signals, below), the difference between paging on symptoms versus causes, what a reasonable alert threshold looks like, and how you behave in an incident — triage order, communication, and the postmortem afterwards. Behavioral rounds often double-dip here with "tell me about an incident you handled", so the same preparation serves twice.

For SRE-titled roles the bar rises to the formal framework: SLIs, SLOs, and error budgets, Prometheus metric types and PromQL, multi-burn-rate alerting, toil budgets, and capacity planning. Our SRE Interview Questions and Answers guide covers all of it with model answers, including a worked p99-latency debugging scenario that shows the method interviewers want to see. Read it even for generalist roles — error-budget vocabulary elevates ordinary monitoring answers.

The scenario round has the highest signal in the loop: "the site is down", "the deploy made it slow", "the disk filled overnight" — and the interviewer watches how you work, not whether you land the exact bug. A reliable method: clarify the symptom and scope first (all users or some? since when? what changed?), check recent changes because most incidents follow a deploy or config push, then walk the request path — DNS, load balancer, application, dependencies — verifying each hop with a command rather than an assumption. State hypotheses cheapest-first and test them in order.

Narrate continuously. "I would run kubectl get pods to see whether anything is crashlooping; if that is clean, ss on the app port; if that listens, the load balancer's target health" is a scoring answer even when the interviewer redirects you, because it exposes ordered thinking. Silence, or jumping to an exotic root cause before checking whether the process is even running, is how otherwise strong engineers fail this round. The best preparation is deliberately breaking a sandbox — kill a service, fill a disk, ship a bad image — and rehearsing the narration out loud.

DevOps sits on the boundary between development and operations, so behavioral rounds probe boundary skills: how you handled a developer pushing back on a pipeline gate, how you drove adoption of a practice without the authority to mandate it, how you balanced toil reduction against feature requests, and how you communicated during an incident with executives watching. Expect at least one failure question — an incident you caused, a project that slipped, a decision you reversed.

Prepare five or six real stories mapped to the recurring themes: incident ownership, cross-team conflict, automation that paid off, a trade-off under pressure, influencing without authority. Give each a crisp arc — situation, your action in the first person, measurable result, what changed afterwards — without reciting STAR so mechanically it sounds rehearsed. Quantify honestly (deploy time from forty minutes to eight, on-call pages halved) and never trash a former team; interviewers assume you will describe them the same way someday.

The questions you ask are scored too, informally: they reveal whether you have operated real systems. Ask about operational reality, not perks. "What does the on-call rotation look like, and how many pages did last week generate?" tells you about both the job and the system's health. "How does a change get from a laptop to production, and how long does that take?" surfaces the delivery maturity in one answer. "Walk me through your last significant incident and what changed afterwards" reveals whether postmortems produce fixes or blame.

Listen to how they answer as much as what they say. Hesitation on deploy frequency usually means manual releases; a laugh at the on-call question means a heavy pager. You are evaluating whether the systems you would inherit are a platform or a rescue mission — both can be good jobs, but they are different jobs, and knowing which one you are signing up for is the point of the final ten minutes.

Six weeks comfortably covers a full loop for someone with some experience; compress to three by cutting to your weakest areas. Weeks one and two: Linux and scripting daily — one text-processing kata and one debugging exercise per day — plus container fundamentals until image builds and signal handling are automatic. Weeks three and four: Kubernetes and your target cloud; alternate concept review with hands-on breaking-and-fixing in a sandbox cluster, then layer in Terraform and pipeline design. Weeks five and six: design-round practice on a whiteboard, behavioral stories written and rehearsed out loud, and full mock interviews under time pressure.

Two habits multiply the plan's value. First, practice out loud: the gap between knowing and articulating is where interviews are lost, and narration only improves by doing it. Second, prep against the actual job description rather than a generic syllabus — the JD tells you which of the sections above deserve your depth. That targeting is exactly what prepme automates: paste the JD and we generate hands-on labs, a graded design round, and a resume-based mock interview matched to the role's stack, so your reps land where the interview will.