DevOps interview questions I'd ask

DevOps interviews can feel unpredictable. One company asks you to reverse a linked list, another wants you to design a global infrastructure in 45 minutes, a third asks about your favourite Kubernetes feature.

If I were interviewing someone for a DevOps role, here's what I'd ask, and, more importantly, what I'd listen for. The goal isn't memorised definitions. It's understanding, experience and how you think.

How I think about interviews

I care about three things:

1. Fundamentals: do you understand how things work underneath the tools?
2. Troubleshooting: can you find a problem methodically, without panicking?
3. Judgement: do you understand trade-offs, risks and when "good enough" is right?

"I don't know, but here's how I'd find out" is a great answer. Confidently making things up is not.

Linux and networking

"What happens when you type a URL into a browser and press Enter?" A classic for a reason. I'm listening for DNS resolution, TCP connection, TLS handshake, HTTP request, load balancer, application, response. Bonus points for caching, CDNs, and where things can go wrong.

"A server is slow. How do you investigate?" Good answers have a method: check load and CPU (top, uptime), memory (free, OOM kills in dmesg), disk space and I/O (df, iostat), network, then the application's own logs and metrics. Start broad, then narrow down.

"The disk is full, but du doesn't show large files. What's going on?" Deleted files still held open by a process (lsof +L1), or running out of inodes (df -i). This separates people who've debugged real systems from those who haven't.

Containers and Kubernetes

"What is a container, actually?" I want to hear about Linux namespaces and cgroups, not just "a lightweight VM". And the difference between an image and a container.

"A pod is in CrashLoopBackOff. Walk me through debugging it." kubectl describe pod (events), kubectl logs --previous, check config and secrets, resource limits (OOMKilled?), probes killing it too early, image and command. A methodical answer matters more than the specific cause.

"What's the difference between requests and limits? What happens when a container exceeds its memory limit? Its CPU limit?" Memory: OOMKilled. CPU: throttled. Requests decide scheduling. Great candidates mention QoS classes or the CPU limits debate.

"How does a request from the internet reach a pod?" DNS, load balancer, Gateway or Ingress controller, Service, endpoints, pod. Bonus for kube-proxy or eBPF, and NetworkPolicies.

"How would you do a zero-downtime deployment?" Rolling updates with readiness probes, PodDisruptionBudgets, graceful shutdown handling, backward-compatible database changes, canary or blue-green for risky changes.

I don't hire for knowing every flag. I hire for knowing how to find out, and knowing when to be careful.

CI/CD and Terraform

"Describe a good CI/CD pipeline." Fast feedback first, build once and deploy the same artifact everywhere, automated tests and security scans, progressive rollout, easy rollback. Listen for "why", not just the stages.

"What is Terraform state and why does it matter?" The mapping between code and real resources. Remote, locked, encrypted, versioned. Contains secrets. Good candidates mention moved and import blocks, or what happens if state is lost.

"Someone changed a resource manually in the console. What happens next time Terraform runs?" Drift: Terraform tries to revert it. How to detect it, how to decide whether code or reality wins, how to prevent it.

"How do you handle secrets in a pipeline?" Not in Git, not in plain CI variables if avoidable. OIDC for cloud access, a secret manager, short-lived credentials, masking in logs.

Troubleshooting scenarios

I love open-ended scenarios, because they show how someone thinks:

"After a deployment, error rates jump to 10%. What do you do?" First: mitigate. Roll back if the deployment is the likely cause. Then investigate: what changed, which endpoints fail, logs, traces. Communicate to stakeholders. Afterwards, a blameless postmortem. The best candidates mention rollback early.

"Users in one region report the site is slow; others are fine." DNS and routing, CDN, regional infrastructure, a dependency in that region, network path. How would you confirm each hypothesis?

"Your cloud bill doubled this month. How do you find out why?" Cost explorer by service, account and tag, looking for new resources, data transfer, logs or a runaway autoscaler. Then prevention: budgets, alerts, tagging.

System design for DevOps

"Design the infrastructure for a web application that must survive the loss of an availability zone." I'm looking for: multiple AZs, load balancing, stateless app tier with autoscaling, managed database with multi-AZ failover, backups in another region, infrastructure as code, monitoring and alerts, a deployment strategy. And the candidate asking questions: how much traffic, what's the budget, what's the acceptable downtime?

Asking clarifying questions is one of the strongest signals in a design interview.

Behavioural questions

• "Tell me about an outage you were involved in. What did you learn?" Honesty, ownership without blame, and real learning.
• "Tell me about a time you automated something painful." Impact, and how you got others to adopt it.
• "How do you handle disagreement with a developer about a deployment?" Collaboration over gatekeeping.

Tips for take-home tasks

• Read the brief twice and do what's asked, not more.
• Write a README: how to run it, what you'd do with more time, trade-offs you made.
• Keep it clean: small commits, sensible structure, no secrets in the repo.
• Make it work end to end before making it fancy.
• Be ready to explain every line, especially if AI helped you write it.

So, how should you prepare?

Build things, break things, and be able to explain what happened. Practise talking through your debugging process out loud. And prepare two or three real stories from your experience: an outage, an automation, a disagreement. They're often what interviewers remember most.

My take: the best DevOps interviews feel like solving a problem together. Show how you think, admit what you don't know, and stay curious.

— Desly