DevOps Interview Questions: The Honest 2026 Guide (180+ Questions Inside)

I’ve sat on both sides of a DevOps interview. As a candidate sweating through a whiteboard rollback scenario, and later as the person asking the questions. Here’s the part nobody tells you: most DevOps interviews aren’t really about tools. They’re about how you think when a deploy breaks at 2 AM and Slack won’t stop screaming.

This guide isn’t another copy-pasted list of 50 definitions. It’s the questions we actually hear from hiring managers at cloud-native startups, banks, and Canadian MSPs in 2026, grouped the way real interview loops are structured, with answers that sound like a human gave them, not a textbook.

If you only have 10 minutes before your call, scroll to the Scenario-Based and Troubleshooting sections. That’s where offers are won and lost. And if you’re still building the foundations these questions test, our live DevOps Engineer course is built around the exact skills hiring managers are asking about in 2026.

What you’ll get here: 80+ core questions in the article, plus a free 180+ question PDF at the bottom (the one that helped three of our students land offers last month). No fluff.

How DevOps Interviews Actually Work in 2026

Before the questions, let’s talk about the loop itself, because it’s changed.

Five years ago, a DevOps interview was a vocab quiz. “What is a container?” “What does Ansible do?” Today, companies have figured out that reading a roadmap.sh page doesn’t make you an engineer. So the loops look more like this:

Round	What They’re Testing	Typical Time
Recruiter screen	Story, salary, notice period	20 min
Technical phone	Fundamentals, tool depth	45 – 60 min
Live troubleshooting	Real broken pipeline or cluster	60 – 90 min
System design	Build a CI/CD or infra platform	60 min
Behavioural / on-call culture	Incidents, postmortems, disagreements	45 min

The live troubleshooting round is the newest and the one most candidates are unprepared for. You’ll share your screen, SSH into a container that won’t start, and narrate your thinking. If you freeze, you fail. If you say “let me check the logs” and actually know which logs to check, you pass.

That’s why memorising 200 flashcards doesn’t work anymore. You have to understand why things break. The questions below are written with that in mind.

If you’re still figuring out which skills to double down on, our DevOps trends 2026 breakdown shows what hiring managers are actually asking for this year (hint: it isn’t “another Jenkins plugin”).

Part 1: Fundamentals (Freshers + Mid-Level)

These are the warm-ups. Get them wrong and the rest of the interview doesn’t happen.

1. What is DevOps, in your own words?

Don’t start with “DevOps is a culture and philosophy…”, every candidate says that, and every interviewer tunes out.

Try this instead: “DevOps is how I shrink the distance between a developer pushing code and that code safely running in production. The tools are the easy part. The hard part is the handshake between teams.”

That answer shows you’ve lived it.

2. How is DevOps different from Agile?

Agile is about how you build software. DevOps is about how you ship and run it. Agile ends at “done.” DevOps starts there and keeps going until the user actually uses it, and keeps going after that, through monitoring and feedback.

3. What does a typical DevOps workflow look like?

Plan → Code → Build → Test → Release → Deploy → Operate → Monitor, and then the monitoring data flows back into planning. The infinite loop diagram is a cliché, but it’s a cliché because it’s true.

4. What’s the difference between Continuous Integration, Continuous Delivery, and Continuous Deployment?

Term	What It Means	Who Clicks Deploy
Continuous Integration	Every commit builds and runs tests	Nobody, it’s automatic up to the artifact
Continuous Delivery	Build is always release-ready	A human, when they’re ready
Continuous Deployment	Every green build goes to prod	Nobody, it’s fully automated

The trap: interviewers love when you mention that most regulated industries (banking, healthcare) stop at Continuous Delivery, not Deployment.

5. Explain the concept of “shift left.”

Shift left means moving testing, security, and quality checks earlier in the pipeline, ideally to the developer’s laptop. A linter in a pre-commit hook is shift-left security. Finding a vulnerability at PR time costs a cup of coffee. Finding it in production costs a weekend.

6. What are the core benefits of adopting DevOps?

Faster deployment frequency, lower change-failure rate, faster mean time to recovery, and, the one people forget, happier engineers who sleep through the night. These are the four DORA metrics, and if you drop “DORA metrics” in your answer, you sound like someone who’s read the Accelerate book instead of a blog.

7. What’s the difference between imperative and declarative infrastructure?

Imperative: “Create an EC2, then attach a volume, then install nginx, then start it.” You list the steps.

Declarative: “I want one EC2 running nginx with a 20GB volume.” The tool figures out the steps.

Terraform and Kubernetes manifests are declarative. A bash script is imperative. In 2026, declarative wins almost every time, but knowing why (idempotency, drift detection, reproducibility) is the actual answer.

8. What is a build artifact?

The compiled, packaged output of your build stage, a Docker image, a JAR file, a zipped Lambda bundle. The rule nobody breaks: build once, promote the same artifact through every environment. If you rebuild for staging and prod, you’ve lost reproducibility.

Free: The PDF That Got 3 People Hired Last Month

Before we go deeper, this is the part I promised.

The PDF That Got 3 People Hired Last Month ,180+ DevOps interview questions. Structured answers. Free.

We put together the full question bank, CI/CD, Docker, Kubernetes, Terraform, AWS, monitoring, scenario rounds, and senior system-design prompts, with the answer structures we drill in our mentorship calls. Three students who used this PDF in March 2026 walked into interviews and walked out with offers.

Drop your email below and we’ll send it to your inbox. No spam. No newsletter trap.

Part 2: CI/CD and Automation

9. Walk me through a Jenkins pipeline you’ve built.

This is a story question. They don’t want a definition of Jenkins, they want to hear you talk about a real pipeline. Pick one you actually shipped. Describe the stages, the artifact, where the tests live, and how you handled secrets. End with: “If I rebuilt it today, I’d move the shared libraries into a Git repo instead of the Jenkins filesystem”, showing you learned something.

10. What’s the difference between a Jenkins freestyle job and a declarative pipeline?

Freestyle jobs are UI-driven and die the moment the Jenkins server dies. Declarative pipelines live in a Jenkinsfile in your repo, so they’re versioned, reviewable, and survive disasters. In 2026, writing freestyle jobs for anything important is a red flag.

11. What is “Pipeline as Code” and why does it matter?

Your pipeline definition sits in your repo, next to the code it builds. A developer can change the build by opening a PR. The pipeline is reviewed like any other code, rolls back like any other code, and reproduces like any other code. This single idea is why Jenkinsfiles, GitHub Actions YAML, and GitLab CI exist.

12. What’s your take on Jenkins vs GitHub Actions vs GitLab CI?

Don’t pick a favourite, show judgment.

• Jenkins: maximum flexibility, maximum babysitting. Still everywhere in banks and enterprise.
• GitHub Actions: zero-ops for teams already on GitHub. Marketplace is huge. Self-hosted runners get weird at scale.
• GitLab CI: best out-of-the-box experience if your code is already on GitLab. Built-in container registry and security scanning.

The right answer is “it depends on where the code lives and who maintains it.”

13. How do you handle secrets in a pipeline?

Never commit them. Never echo them. Use a secrets manager, HashiCorp Vault, AWS Secrets Manager, GitHub Encrypted Secrets, or Kubernetes External Secrets. Inject them at runtime as environment variables and mask them in logs. If you say “I put them in an .env file and gitignore it,” you’ve just failed the interview.

14. What is Git branching, and which strategy do you prefer?

Three common strategies:

• Git Flow: feature, develop, release, hotfix, main. Heavy. Good for versioned products.
• GitHub Flow: main plus short-lived feature branches. Lightweight. Good for web apps on continuous delivery.
• Trunk-based development: everyone commits to main, behind feature flags. What high-performing teams use, according to every DORA report.

Pick trunk-based if you’ve used it. If you haven’t, say so honestly, honesty beats bluffing.

15. What’s the difference between git fetch and git pull?

git fetch downloads changes from the remote but doesn’t touch your working branch. git pull is fetch followed by merge. I fetch first when I want to see what’s changed before I commit to merging. Sounds small, but it’s the kind of detail that makes senior interviewers nod.

16. How do you do zero-downtime deployments?

Blue-green, canary, or rolling updates. Explain one you’ve actually done:

• Blue-green: two identical environments, switch traffic at the load balancer. Fast rollback, expensive.
• Canary: roll out to 1%, then 10%, then 50%, then 100%. Cheaper but slower.
• Rolling update: Kubernetes replaces pods gradually. The default for most teams.

Part 3: Containers and Kubernetes

17. What is Docker, and why do we use it?

Docker packages an application and its dependencies into an isolated, portable unit, a container. The value isn’t “it runs in a container.” The value is: the thing you tested on your laptop is bit-for-bit the thing running in production. That reproducibility is the whole pitch.

18. What’s the difference between a Docker image and a container?

An image is a blueprint. A container is a running instance of that blueprint. One image, many containers. Same idea as class vs object.

19. How would you optimise a slow, bloated Dockerfile?

Five things, and they ask this a lot:

1. Multi-stage builds, compile in a heavy image, copy the binary into a tiny final image.
2. Smallest base image possible, Alpine, distroless, or scratch.
3. Order layers by change frequency, COPY package.json then RUN npm install before COPY ., so the install layer is cached.
4. Combine RUN commands with && to reduce layers.
5. .dockerignore, keep node_modules, .git, and secrets out of the build context.

20. What are the core components of a Kubernetes cluster?

Control plane: API server (the front door), etcd (state), scheduler (decides which node runs which pod), controller manager (reconciles desired vs actual state).

Nodes: kubelet (pod lifecycle), kube-proxy (networking), container runtime (containerd these days, not Docker).

If you can draw this on a whiteboard in 90 seconds, you’re ahead of 80% of candidates.

21. What’s the difference between a Deployment, a StatefulSet, and a DaemonSet?

• Deployment: stateless pods, interchangeable, random names. Your web app.
• StatefulSet: stable identity, ordered startup, persistent storage per pod. Your database.
• DaemonSet: one pod per node. Your log collector or CNI plugin.

22. How does a pod get an IP, and how does service discovery work?

The CNI plugin (Calico, Cilium, Flannel) assigns each pod an IP from the cluster CIDR. Services create a stable virtual IP plus a DNS name inside the cluster, so pods can reach each other by name even as IPs change. kube-proxy (or eBPF in modern setups) handles the routing.

23. What are readiness and liveness probes, and when do you get them wrong?

• Liveness, “is this container alive? restart if not.”
• Readiness, “is this container ready to take traffic? pull it from the load balancer if not.”

The classic mistake: pointing liveness at /health and making /health check the database. Database blips → pod restarts → cascading failure. Keep liveness cheap and local. Put the heavy checks in readiness.

24. How would you troubleshoot a pod stuck in CrashLoopBackOff?

kubectl describe pod <name>     # look at Events
kubectl logs <name> --previous  # the logs from the dead container
kubectl exec -it <name> -- sh   # if you can get in

Then: check image tag, environment variables, secrets, resource limits (OOMKilled shows up here), and liveness probe config. 9 times out of 10 it’s one of those five.

If you want to see how container orchestration fits inside broader automation, our CCIE Automation course runs through Kubernetes for network engineers, a crossover role that pays exceptionally well in 2026.

Part 4: Infrastructure as Code (Terraform + Ansible)

25. What is Terraform state, and why does it matter?

Terraform state is the file that maps your .tf code to the real-world resources it created. Without state, Terraform would recreate everything on every run. With state, it knows what exists and what needs to change.

The follow-up that trips people up: “Where do you store it?” Answer: a remote backend (S3 with DynamoDB locking, or Terraform Cloud), never on your laptop, never in Git.

26. What’s the difference between count and for_each?

Both create multiple resources from one block. The difference is in how they’re tracked in state.

• count uses an integer index. Remove an item from the middle and everything after it gets recreated.
• for_each uses a map or set of strings. Remove a key and only that resource is destroyed.

Rule of thumb: use for_each unless you have a real reason not to.

27. How do you handle infrastructure drift?

Drift is when the real world no longer matches Terraform state, someone clicked something in the AWS console. You detect it with terraform plan run on a schedule, and you fix it either by importing the manual change into code or by reverting the console change. The long-term fix is locking down console access so nobody can drift it in the first place.

28. What’s the difference between terraform import and terraform taint?

• terraform import brings an existing resource under Terraform management.
• terraform taint (now terraform apply -replace) marks a resource for destroy-and-recreate on the next apply.

Getting this right is a classic senior filter.

29. How do you manage secrets in Terraform?

Never hardcode. Use variables marked sensitive = true, pull values from a secrets manager at runtime (Vault, AWS Secrets Manager), and for CI use environment variables (TF_VAR_*). The state file still contains the resolved value, which is why you encrypt your remote state backend.

30. Ansible vs Terraform, when do you use which?

• Terraform: provisioning, creating the VM, the VPC, the database.
• Ansible: configuration, installing packages on the VM, copying config files, restarting services.

They overlap but they’re built for different jobs. The smart answer is: “Terraform for Day 0, Ansible for Day 1 and Day 2.”

31. What is an Ansible inventory, and why do dynamic inventories matter?

An inventory is the list of hosts Ansible manages. Static inventories are text files. Dynamic inventories pull hosts from a source of truth, AWS tags, NetBox, vCenter, so they stay accurate as your infra changes. Static inventories rot the moment someone adds a server.

If you want to see this done right in the real world, our walkthrough on NetBox as an Ansible dynamic inventory is exactly what a lot of network-DevOps hybrid roles now ask candidates to build.

Part 5: Cloud (AWS-Heavy, But Portable)

32. Design a highly available web application on AWS.

Classic system-design prompt. Hit these points:

• Multi-AZ by default. Multi-region only if the SLA demands it.
• Application Load Balancer in front of an Auto Scaling group.
• RDS Multi-AZ for the database.
• S3 + CloudFront for static assets.
• Secrets in Secrets Manager.
• Route 53 with health checks for DNS failover.
• Everything provisioned by Terraform, deployed by a pipeline.

Bonus points: mention what you’d do differently for a startup (simpler, cheaper) vs an enterprise (stricter, more redundant).

33. What’s the difference between an ALB and an NLB?

• ALB (Application Load Balancer): layer 7, routes on HTTP paths and headers, supports WAF.
• NLB (Network Load Balancer): layer 4, handles millions of requests per second, preserves source IP, used for TCP/UDP workloads.

Use ALB for web apps. Use NLB for databases, game servers, or anything non-HTTP.

34. How do you secure an S3 bucket?

1. Block public access at the account level.
2. Bucket policy that enforces TLS (aws:SecureTransport).
3. Server-side encryption with KMS.
4. Access logging enabled.
5. Versioning + MFA delete for anything critical.

Don’t forget to say: “and I audit it with AWS Config, not just hope.”

35. What’s the difference between IAM roles and IAM users?

A user has long-lived credentials (access key). A role is assumed temporarily. Best practice in 2026: zero users for humans (use SSO), zero users for applications (use roles), and rotate everything.

Want a structured AWS path to back up your interview answers? The AWS Solutions Architect course walks through exactly these design decisions with real labs, and the full AWS certifications guide for 2026 maps which certs actually move the needle on your salary.

Part 6: Monitoring, Logging, and On-Call

36. What are the four golden signals?

Latency, traffic, errors, saturation. From Google’s SRE book. If you can only monitor four things, monitor these.

37. Explain the difference between metrics, logs, and traces.

• Metrics: numeric, aggregated, cheap to store. “Error rate is 2%.”
• Logs: text, verbose, expensive. “User 123 failed login at 14:22.”
• Traces: the path of a single request across services. “This request hit 7 services and spent 1.2s in the database.”

You need all three. Any monitoring story that only uses one is incomplete.

38. What is Prometheus, and why is it a pull-based system?

Prometheus scrapes metrics from HTTP endpoints on a schedule. Pull-based means Prometheus decides when and what to scrape, which makes it easier to detect dead targets (if you can’t scrape it, it’s probably down). Push-based systems flood the collector if a node goes crazy.

39. How do you define a good SLO?

Start from what the user feels. Not CPU, not memory, but “95% of checkout requests complete in under 2 seconds over any 30-day window.” Then set an error budget: 5% of the time we’re allowed to fail, and if we burn through the budget, we stop shipping features and fix reliability.

40. Describe your incident response process.

Detect → Acknowledge → Mitigate → Resolve → Postmortem.

The interviewer is listening for “mitigate before resolve.” Mitigation is “stop the bleeding” (roll back, failover, scale up). Resolution is “find the root cause.” You can’t find the root cause while the site is on fire.

Part 7: Scenario-Based Questions (Where Interviews Are Won)

These are the ones that matter. There’s rarely a single right answer, they want to hear your thinking.

41. “A deployment went to prod and now the error rate is 4x. What do you do?”

Out loud, in order:

1. Roll back first, debug second. Get the site healthy.
2. Confirm the rollback worked by watching error rates drop.
3. Now compare the old and new commit, read the diff, read the logs, reproduce locally.
4. Write the postmortem, what broke, why the tests didn’t catch it, what we’re changing.
5. Add the missing test before the next deploy.

If you start by saying “I’d SSH into the box and check the logs,” you’ve already lost points. Roll back first.

42. “Your Kubernetes cluster’s API server is unresponsive. Walk me through it.”

Check etcd health first, if etcd is down, nothing else matters. Then check the API server logs on the control plane nodes, then check certificate expiry (the silent killer), then check if a misbehaving controller is hammering the API. Don’t forget: kubectl talks to the API server, so if the API is dead, your usual tools are too.

43. “A developer says ‘the build is broken but it’s not my fault.’ What do you do?”

First, don’t get defensive. Pull up the failing build together. Read the error. 90% of the time it’s a flaky test, a dependency version, or a cache issue, fixable in 5 minutes. The other 10% is a real bug in their code. Either way, sit with them, don’t lecture them. The goal is to fix the pipeline, not to be right.

44. “How do you onboard a new service to your platform?”

Paved road answer: “We have a template repo. You fork it, fill in three config values, open a PR, and the platform wires up CI, monitoring, secrets, and a staging environment automatically.” If you can describe a paved road, you sound senior. If you describe a 40-step manual checklist, you sound like you’ve never worked somewhere healthy.

45. “Tell me about a time you disagreed with a developer about a deployment.”

STAR format, Situation, Task, Action, Result. Keep it short. The win is showing you can disagree without drama and end up in a better place than where you started.

Part 8: Senior + System Design

46. Design a CI/CD platform that supports 200 microservices.

Components to mention: a shared artifact registry, standardised pipeline templates, self-service onboarding, per-team namespaces, policy as code (OPA/Conftest), staged environments (dev → staging → prod), deployment approval gates, and a rollback button that actually works. Bonus: talk about how you’d keep build times under control as the monorepo grows.

47. How would you migrate a legacy VM-based app to Kubernetes?

Don’t lift-and-shift blindly. Start with: why are we migrating? Cost? Deployment speed? Reliability? Then:

1. Containerise without changing behaviour.
2. Deploy to staging on Kubernetes, run both old and new in parallel.
3. Add readiness/liveness probes, resource limits, and monitoring.
4. Gradually shift traffic with a load balancer.
5. Decommission the old VM only when the new one has been stable for a month.

48. What’s your approach to cost optimisation in the cloud?

Tag everything, monitor spend per team, right-size instances monthly, use spot/preemptible for non-prod, set up savings plans for baseline load, and delete zombie resources (unattached EBS, old snapshots, idle load balancers). The real answer is “make cost visible to the engineers who create it”, a team that can see their bill manages their bill.

49. How do you think about security in a DevOps pipeline?

DevSecOps checkpoints: SCA (dependency scanning), SAST (static code analysis), secrets scanning pre-commit, container image scanning, IaC scanning (tfsec, checkov), runtime scanning (Falco), and a break-glass process for when you have to ship during an incident. Mention “defense in depth” and “shift left” without sounding like a buzzword generator.

50. What’s the biggest DevOps mistake you’ve made?

Everyone has one. Tell a real story. Own it. End with what you learned and what you’d do differently. The candidates who say “I don’t really make mistakes” are the ones who get filtered out. The candidates who laugh and tell a story about taking down production in 2022 are the ones who get the offer.

The 5 Mistakes That Kill DevOps Interviews

Before you walk in, avoid these:

1. Memorising definitions instead of understanding tradeoffs. Saying “Kubernetes orchestrates containers” isn’t useful. Saying “Kubernetes is overkill for a 3-service startup and I’d use ECS instead” is.
2. Not having a story. Every answer should be anchored to something you’ve actually done. “In my last role, we…” beats any definition.
3. Freezing on troubleshooting rounds. Narrate your thinking out loud, even when you’re stuck. “I don’t know yet, but I’d check logs first because…” scores points. Silence loses them.
4. Dismissing soft questions. The on-call / incident / conflict questions are not warm-ups. They’re filters.
5. Talking about tools, not outcomes. Interviewers don’t care that you used Jenkins. They care that you reduced deploy time from 45 minutes to 6 minutes and cut the rollback rate in half.

The Career Math Most Candidates Miss

One thing we tell every student before they start interviewing: the compensation band for DevOps in 2026 is wide. A mid-level DevOps engineer in Toronto can earn anywhere from $95K to $165K depending on cloud skills, Kubernetes depth, and interview performance. Senior roles push past $200K. We broke down the real numbers in our 2026 DevOps salary guide, worth a read before you quote a number to a recruiter.

If you’re still building the foundations, our live-instructor DevOps Engineer course is built around the exact skills in this guide, anzd the Automation Engineer track is the right fit if you’re coming from a network background and want to pivot. Both are live-taught, not video-only, so you can ask a real person “why does this work this way?” while you’re learning.

Get the Full 180+ Question PDF (Free)

You’ve read 50 questions here. The full list has 180+, including senior scenario rounds, Linux performance questions, Git advanced, Vault and secrets management, observability deep-dives, and 20 behavioural questions with the STAR-format answer scaffolds we drill with students.

Three students used this exact PDF in March 2026 and walked into offers, one at a Canadian bank, one at a SaaS startup, one at an MSP. I won’t claim the PDF was the only reason. But I will say this: every one of them told us “I finally stopped freezing, because I knew what shape the answer was supposed to look like.”

The PDF That Got 3 People Hired Last Month 180+ DevOps interview questions. Structured answers. Free. Drop your email.

Frequently Asked Questions

Final Word

DevOps interviews reward engineers who can think out loud under pressure, tell honest stories, and admit what they don’t know. If you take one thing from this guide, let it be that. The tools change every year. The ability to stay calm, narrate your reasoning, and learn from your last outage doesn’t.

Good luck out there. Go grab the PDF, run through a couple of mock interviews with a friend, and remember: the interviewer wants you to succeed. It’s cheaper to hire you than to keep looking.