DevOps Interview Questions Every Engineering Manager Should Ask
Most DevOps interviews test whether candidates can recite tool syntax. These questions test whether they can actually think through production problems, design systems under constraints, and make the kind of judgment calls your team needs.
By Subeesh Sivanandan, Founder & CEO, Stonetusker Systems · Updated October 2026 · Est. reading time: 14 minutes
Executive Brief
The biggest hiring mistake engineering managers make with DevOps roles is optimizing for tool knowledge (Kubernetes, Terraform, Jenkins) instead of systems thinking and operational judgment. Tools can be learned in weeks; the instinct to design for failure takes years to develop.
This article provides 20+ interview questions organized by competency area: systems design and architecture, CI/CD pipeline thinking, incident response and reliability, security and compliance, and team collaboration. Each question includes what to listen for and what signals a weak answer.
Scenario-based questions consistently outperform trivia questions at predicting on-the-job performance. Asking "what's a DaemonSet" tests recall; asking "your nodes are running out of disk because container logs aren't being rotated, walk me through how you'd fix it permanently" tests engineering.
The best DevOps candidates think in trade-offs, not absolutes. If someone answers every question with a single "correct" approach and no caveats, they're either inexperienced or telling you what they think you want to hear.
Use the DevOps maturity model to calibrate which questions matter most for your team's current stage. A team with no CI/CD at all needs different hires than a team optimizing deploy frequency from daily to hourly.
Why Most DevOps Interviews Fail
The standard DevOps interview at most companies looks something like this: a recruiter screens for keyword matches (Kubernetes, AWS, Terraform, Docker), a hiring manager asks "tell me about your experience with X," and a technical interviewer runs through a list of factual questions about how specific tools work. The candidate who can recite the most tool-specific details gets the offer.
This process reliably produces bad hires.
Here's why: the daily work of a senior DevOps or platform engineer is almost never "configure tool X." It's "figure out why deployments started failing on Thursdays," or "design a pipeline that works for 14 microservices owned by 4 teams with different release cadences," or "decide whether this outage warrants waking up the on-call or can wait until morning." Those are judgment problems. They require systems thinking, an understanding of trade-offs, and the ability to operate under ambiguity.
Tool knowledge is table stakes. You can verify it in 10 minutes with a practical exercise. What you can't easily verify, and what matters far more for day-to-day performance, is how a candidate thinks when things go wrong, how they communicate technical risk to non-technical stakeholders, and whether they design for the system they actually have or the one they wish they had.
The questions in this article are built around those competencies. Each one is designed to reveal how the candidate thinks, not just what they know.
Operational Test
Pull up the interview script your team used for the last DevOps hire. Count the questions. How many test tool-specific knowledge versus how many test judgment, trade-off analysis, or communication? If more than 60% are tool questions, your interview is optimizing for the wrong signal.
Systems Design and Architecture Questions
These questions test whether the candidate can think about infrastructure as a system rather than a collection of individual tools. You're looking for answers that consider failure modes, scaling behavior, cost, and operational burden, not just "how to set it up."
Question 1
"You're joining a 30-person engineering team that has 12 microservices, all deployed manually via SSH into EC2 instances. Walk me through how you'd approach modernizing this, starting from your first week."
Why ask this: This tests whether the candidate can resist the urge to immediately redesign everything. The right first step is always to understand, not to build.
Strong signal: They start with observation: talking to teams, mapping the current deployment flow, understanding what breaks and how often. They prioritize by pain, not by what's trendy. They mention getting a quick win first (maybe containerizing one service) to build trust before proposing bigger changes.
Weak signal: They jump straight to a target architecture ("we'd move everything to Kubernetes on EKS with ArgoCD"). No mention of understanding the current state or stakeholder buy-in.
Question 2
"Design a deployment pipeline for a monorepo with 5 services that share some libraries but deploy independently. Two of the services have strict uptime requirements (99.95% SLA). What does the pipeline look like?"
Why ask this: Monorepos are common and messy. This question tests whether the candidate can handle dependency management, selective builds, and differentiated deployment strategies within a single repository.
Strong signal: They ask clarifying questions about shared library versioning. They distinguish between the high-SLA services (which need canary or blue-green deploys, automated rollback, longer bake times) and the others (which might be fine with a simpler rolling deploy). They mention change detection to avoid rebuilding services that weren't affected by a commit.
Weak signal: A one-size-fits-all pipeline design that treats all 5 services identically, or no mention of the SLA implications.
Question 3
"Your company is spending $45,000 a month on AWS. The CEO wants to cut it by 30%. Where do you start?"
Why ask this: Cloud cost optimization is an increasingly central part of the DevOps role. This question tests whether the candidate approaches cost as an engineering problem or just suggests "use Reserved Instances."
Strong signal: They start with visibility (tagging, cost allocation, identifying which teams or services own what spend). They mention looking at utilization data before cutting. They differentiate between quick wins (right-sizing overprovisioned instances, killing unused resources, spot instances for non-critical workloads) and structural changes (re-architecting compute-heavy jobs, evaluating managed vs. self-hosted for databases). They acknowledge that some cuts carry reliability risk and quantify that trade-off.
Weak signal: Jumping to "buy reserved instances" without analyzing current usage, or proposing cuts without mentioning the reliability trade-offs.
CI/CD Pipeline Thinking
CI/CD is the backbone of DevOps. But "can you set up a pipeline" is a junior question. At the senior level, the questions that matter are about pipeline design under real-world constraints: conflicting priorities, legacy systems, compliance requirements, and teams that don't always follow the process.
Question 4
"Your CI pipeline takes 42 minutes. Developers have started skipping it by pushing directly to the deploy branch. How do you handle this?"
Why ask this: This is a two-part problem: a technical one (the pipeline is too slow) and a human one (developers are working around the process). Good candidates address both.
Strong signal: On the technical side, they profile the pipeline to find the actual bottleneck (is it tests? builds? artifact uploads?), and they mention strategies like parallelization, test splitting, caching, or selective test runs based on changed files. On the human side, they enforce branch protection rules to close the workaround, but they also recognize that enforcement alone doesn't solve the root cause. A 42-minute pipeline is a tax on developer productivity, and people route around taxes.
Weak signal: Only addressing one side. "Just add branch protection" without fixing the speed. Or "just make it faster" without addressing the governance gap that let people bypass it.
Question 5
"You're migrating from Jenkins to GitHub Actions (or any other CI system). There are 80 Jenkins jobs, some of which haven't been modified in two years. How do you plan this migration?"
Why ask this: CI migrations are common, messy, and full of hidden dependencies. This tests project management as much as technical skill.
Strong signal: They audit all 80 jobs first: which are active, which are orphaned, which have undocumented dependencies. They categorize by complexity and risk. They propose running both systems in parallel during the transition rather than a big-bang cutover. They flag the two-year-old jobs as candidates for deletion or archival, not automatic migration. For a deeper breakdown of this specific migration, see Stonetusker's Jenkins to GitHub Actions migration guide.
Weak signal: Proposing to convert all 80 jobs sequentially without triaging them first, or no mention of the parallel-run period.
Question 6
"A developer asks you to add a manual approval gate before production deploys. Another developer on the same team says manual gates slow everything down and wants fully automated deploys. How do you handle this?"
Why ask this: This is a judgment and communication question disguised as a technical one. There's no universally right answer; it depends on the team's maturity, the application's risk profile, and the regulatory environment.
Strong signal: They ask about context: what kind of application is this? What's the blast radius of a bad deploy? Is there a compliance requirement? They might propose a compromise (automated deploys to staging, approval gate only for production, with the ability to remove it once the team has enough confidence in their test coverage and rollback process). They recognize that the disagreement between the two developers is a symptom of missing alignment on risk tolerance, and they'd facilitate that conversation.
Incident Response and Reliability
How someone behaves during an outage tells you more about their DevOps skill than any whiteboard exercise. These questions simulate that pressure in an interview setting.
Question 7
"It's 2 AM. PagerDuty wakes you up. The primary database is responding but queries that normally take 50ms are now taking 12 seconds. The application isn't down, but it's unusable. Walk me through your first 15 minutes."
Why ask this: This tests the candidate's diagnostic methodology under pressure. Slow-but-not-down problems are harder to triage than complete outages because the symptoms are ambiguous.
Strong signal: They have a structured approach. Check recent deployments first (was anything released in the last few hours?). Look at database metrics: CPU, memory, active connections, lock contention, slow query log. Check if the issue is all queries or specific tables/queries. Look for obvious causes like a missing index after a migration, a runaway batch job, or a spike in connection count. They communicate early, even before they have answers: update the incident channel, notify the team lead if the issue persists past 10 minutes.
Weak signal: Starting with "I'd restart the database." That's a recovery action, not a diagnostic step, and it destroys evidence of what went wrong.
Question 8
"Tell me about a postmortem you wrote or contributed to. What went wrong, what did you learn, and did the action items actually get completed?"
Why ask this: The last part is the real question. Anyone can write action items. Following through on them is what separates teams that learn from teams that just document.
Strong signal: They describe a specific incident with technical detail. They own their part in it (not blaming others or external systems). They mention concrete follow-up: "we added a circuit breaker on the payment service call, and it prevented the same failure mode three months later." Or honestly, "we wrote five action items, completed two, and the other three got deprioritized because of a product launch."
Weak signal: Vague answers ("we had an outage, we fixed it, we wrote a postmortem"). No mention of what actually changed afterward. Or, worse, blaming a single person.
Question 9
"You've been asked to define SLOs for a service that currently has no formal reliability targets. The product team wants 99.99% uptime. How do you respond?"
Why ask this: 99.99% uptime means about 52 minutes of downtime per year, or about 4.3 minutes per month. Most teams that claim to want 99.99% haven't done the math on what it costs to achieve. This tests whether the candidate can have that conversation.
Strong signal: They translate the number into concrete terms: "99.99% means we can be down for 4 minutes a month total, including planned maintenance. That requires redundancy across availability zones, automated failover under 60 seconds, and zero-downtime deployments. Is the product team willing to fund that?" They suggest starting with a realistic baseline (measure current reliability first) and setting an SLO that's achievable, with a plan to improve it over time.
Security and Compliance
DevOps engineers increasingly own the security posture of the delivery pipeline. Even if you have a dedicated security team, the person managing CI/CD needs to understand the basics of supply chain security, secrets management, and compliance automation.
Question 10
"A developer has committed an AWS access key to a public GitHub repository. It was merged 20 minutes ago. What do you do?"
Why ask this: This is a real scenario that happens to real teams. The answer reveals whether the candidate understands the urgency (credential scanners find exposed keys within minutes) and has a mental playbook for credential rotation under time pressure.
Strong signal: Immediate: rotate the key in AWS IAM right now, before doing anything else. Then check CloudTrail for any unauthorized API calls made with that key in the last 20 minutes. Remove the commit from the repo's history (force push or BFG Repo-Cleaner). After the immediate response: set up pre-commit hooks or GitHub secret scanning to prevent this from happening again. Review whether the developer had MFA enabled and whether the key had the minimum necessary permissions.
Weak signal: Starting with "delete the commit" instead of rotating the key. The key is already compromised; removing it from the repo doesn't un-expose it.
Question 11
"Your company needs SOC 2 Type II certification. What does that mean for the CI/CD pipeline specifically?"
Why ask this: Many DevOps engineers treat compliance as someone else's problem. At the senior level, they need to understand how compliance requirements translate into pipeline controls.
Strong signal: They mention specific CI/CD-relevant controls: audit logging for all deployments (who deployed what, when, to which environment), separation of duties (the person who wrote the code shouldn't be the same person who approves the deploy to production), change management trails, access controls on production environments, and evidence of automated testing. They understand that SOC 2 is about demonstrating controls exist and work consistently, not just checking boxes once. For a detailed breakdown, see Stonetusker's SOC 2 compliance checklist.
Question 12
"How would you implement SBOM generation in an existing CI/CD pipeline? And who actually uses the output?"
Why ask this: SBOM (Software Bill of Materials) is increasingly required by regulation and enterprise customers. The second part of the question, "who uses it," tests whether the candidate understands the purpose or just knows the acronym.
Strong signal: They mention tools like Syft, Trivy, or CycloneDX for generation, integrated as a pipeline step that runs after the build. For the "who uses it" part, they name concrete consumers: the security team for vulnerability tracking, legal for license compliance, customers who require it as part of procurement, and auditors validating supply chain controls under frameworks like the Cyber Resilience Act or NIST guidelines.
Collaboration and Culture Fit
DevOps is, at its core, a collaboration practice. A brilliant engineer who can't work with developers, product managers, or security teams will create more problems than they solve.
Question 13
"A development team keeps requesting one-off infrastructure changes through Slack DMs instead of using your team's Terraform workflow. How do you handle it?"
Why ask this: This tests whether the candidate defaults to enforcement ("no, use the process") or empathy ("why are they routing around the process, and what can I fix about it?").
Strong signal: They investigate why the team is going around the process. Is the Terraform workflow too slow? Too complicated? Do they not have the permissions to run it themselves? The candidate fixes the root cause (maybe it's a self-service portal, maybe it's better documentation, maybe it's granting the team limited Terraform access) rather than just enforcing the rule.
Question 14
"How do you explain a 2-hour production outage to a non-technical CEO who wants to know why it happened and what's being done about it?"
Why ask this: Communication is a core DevOps competency. If the candidate can't translate technical events into business impact, they can't effectively advocate for reliability investments or infrastructure improvements.
Strong signal: They structure the explanation around impact (what customers experienced, how many were affected, for how long), cause (in plain language, not technical jargon), and prevention (concrete actions, with timelines, not vague promises). They avoid blame and jargon. They connect the outage to business metrics the CEO cares about: revenue impact, customer trust, support ticket volume.
How to Structure the Full Interview
A typical DevOps interview loop for a senior hire should include 3 to 4 rounds. Here's a structure that works:
Round
Duration
Focus
Interviewer
1. Systems design
60 min
Architecture, trade-offs, cost awareness
Engineering manager or senior engineer
2. Practical exercise
90 min
Debug a broken pipeline, or design a pipeline from requirements
DevOps/platform team member
3. Incident response scenario
45 min
Walk through a simulated outage, assess diagnostic thinking
Skip the LeetCode-style coding round. Unless the role involves writing significant application code, algorithm puzzles test the wrong thing. Replace it with the practical exercise, which simulates actual work.
The practical exercise is the most informative round. Give the candidate a broken CI/CD pipeline (or a set of requirements for a new one) and 90 minutes to work through it. Watch how they approach the problem, what they Google (yes, let them Google), and how they communicate their reasoning. The point isn't whether they finish. It's how they think.
Operational Test
After your next DevOps interview, ask each interviewer: "On a scale of 1 to 10, how confident are you that this candidate can handle an ambiguous, cross-team production problem at 2 AM?" If the interviewers can't answer that with confidence, the interview didn't test the right things.
Interview Anti-Patterns to Avoid
Anti-Pattern
Why It's a Problem
What to Do Instead
"What is Kubernetes?"
Tests recall, not ability. Anyone can memorize a definition.
"When would you choose not to use Kubernetes, and what would you use instead?"
Asking about tools the candidate listed on their resume
Confirms they used it; doesn't test depth or judgment
"Tell me about a decision you made with [tool] that you later regretted."
Asking the same questions to junior and senior candidates
Seniors need judgment questions, not knowledge questions
Calibrate questions to the level: seniors get ambiguous scenarios with no clean answer
Evaluating only technical skill
DevOps failures are more often communication failures than technical ones
Include at least one round focused entirely on collaboration and stakeholder communication
Expecting one "correct" answer
Real-world DevOps problems have multiple valid approaches
Evaluate the reasoning, trade-off awareness, and what questions the candidate asks
A Note on Take-Home Assignments
Some companies give DevOps candidates a take-home assignment: "set up a CI/CD pipeline for this sample app and deploy it to AWS." These can work, but only if you keep them short (3 to 4 hours maximum), you pay for the candidate's time if it takes longer, and the evaluation focuses on the design decisions (documented in a README) rather than whether the pipeline works perfectly.
Candidates at the senior level are interviewing at multiple companies. A 12-hour take-home that requires spinning up real cloud infrastructure and doesn't compensate for the time is a filter, but it filters out the best candidates (who have other options) rather than the worst.
Calibrating Questions to Your Team's Maturity
Not every team needs the same kind of DevOps hire. Use Stonetusker's DevOps maturity assessment framework to figure out what stage your team is at, and then weight your interview questions accordingly:
Team Maturity Stage
What You're Hiring For
Emphasize These Question Areas
No CI/CD (manual deploys)
Someone to build the foundation
Systems design, practical pipeline building, stakeholder communication (they'll need buy-in)
Basic CI/CD in place
Someone to improve reliability and speed
Pipeline optimization, incident response, monitoring and observability
Mature CI/CD, building a platform team
Someone who thinks about developer experience
Internal developer platforms, self-service tooling, collaboration across teams
DevOps InterviewEngineering HiringTechnical InterviewsDevOps SkillsPlatform EngineeringSRE HiringCI/CDTeam Building
Frequently Asked Questions
How many questions should I ask in a DevOps interview?
For a 60-minute round, plan 3 to 4 scenario-based questions. That leaves enough time for follow-up discussion on each. Rushing through 10 questions produces superficial answers. You learn more from exploring 3 questions deeply, with follow-ups and "what if" extensions, than from skimming across 10.
Should DevOps candidates do a coding exercise?
Only if coding is a significant part of the role. If they'll be writing Python or Go tooling daily, yes. If the role is primarily infrastructure design, IaC, and pipeline management, replace the coding exercise with a practical infrastructure or pipeline design exercise. A practical exercise where the candidate debugs a broken Dockerfile or optimizes a slow GitHub Actions workflow tests directly relevant skills. LeetCode-style algorithm problems are not relevant for most DevOps roles.
What's the difference between interviewing for a DevOps engineer versus an SRE?
DevOps engineers typically focus on CI/CD, infrastructure automation, and developer experience. SREs focus on reliability, incident response, capacity planning, and SLO management. In practice, the roles overlap significantly. For SRE interviews, put more weight on incident response scenarios, SLO definition, and monitoring architecture. For DevOps interviews, weight more toward pipeline design, infrastructure as code, and cross-team collaboration. Both roles need systems thinking and the ability to operate under ambiguity.
How do I evaluate a candidate's Kubernetes knowledge without asking trivia?
Give them a scenario: "You have a stateless web application that currently runs on 3 pods and gets unpredictable traffic spikes on Friday mornings. How do you configure it?" This tests HPA, resource requests/limits, pod disruption budgets, and readiness probes in context, without asking "what is an HPA?" directly. Then follow up with trade-off questions: "What happens if you set the CPU target too low? Too high?" The progression from basic configuration to trade-off analysis is where you separate the experienced candidates from the ones who memorized a study guide.
How important is cloud-specific knowledge (AWS vs. GCP vs. Azure)?
Less important than most job descriptions suggest. A strong DevOps engineer who's deep in AWS can get productive on GCP within a few weeks. The underlying concepts (VPCs, IAM, object storage, managed databases, container orchestration) are the same across providers. Prioritize someone who understands those concepts and has mastered at least one provider over someone with shallow experience across all three. The exception is if your environment uses highly provider-specific services (Aurora, BigQuery, Azure DevOps) that are central to your architecture.
Should I ask about specific DevOps tools in the interview?
Yes, but frame the question as "why did you choose this tool, what did you evaluate it against, and what are its weaknesses?" rather than "how does this tool work?" Tool selection is a judgment skill. Tool operation is a trainable skill. If a candidate chose Terraform over Pulumi for a specific project and can articulate why (state management maturity, team familiarity, community module ecosystem), that tells you more than whether they can write a Terraform module from memory.
Building your DevOps team and want help defining what "good" looks like for your specific engineering stage? Stonetusker's platform foundation engagement includes hiring framework design alongside pipeline and infrastructure work.
26+ years across platform engineering, DevOps, CI/CD, release engineering, and embedded Linux. Subeesh has built and scaled DevOps teams across startups and enterprises, and has conducted hundreds of technical interviews for infrastructure, platform, and SRE roles.
