DevOps engineering interviews are uniquely challenging because the role spans software development, infrastructure, automation, and organisational culture. Interviewers expect candidates to demonstrate technical depth across multiple domains and the ability to think about systems holistically — how code moves from a developer's laptop to production, and how that production environment stays reliable at scale.
According to the DORA State of DevOps report, elite-performing teams deploy on demand, recover from incidents in less than an hour, and have a change failure rate below 5%. AWS DevOps research shows that organisations adopting DevOps practices experience 60% faster time to market and 60% fewer failures. Glassdoor data consistently places DevOps engineering in the top ten highest-paying technical roles across major markets.
The 30+ questions below are organised by category so your recruitment guide and hiring panel can assess candidates systematically. Use our interview scorecard to rate responses consistently across dimensions.
General DevOps Concepts (5 Questions)
These questions assess whether a candidate understands DevOps as a culture, not just a toolchain.
1. How would you explain DevOps to a non-technical stakeholder?
Strong answers frame DevOps as practices that unify development and operations to shorten the delivery cycle while maintaining quality. Look for references to cultural change — shared ownership, feedback loops, and continuous improvement — rather than a list of tools.
2. What are the key principles of the DevOps methodology, and which do you consider most important?
Expect mentions of continuous integration, continuous delivery, infrastructure as code, monitoring, and collaboration. The best candidates prioritise feedback loops and cultural change over specific tooling and can argue why one principle is foundational.
3. Describe the difference between continuous integration, continuous delivery, and continuous deployment.
Precision matters. CI is merging and testing code frequently. Continuous delivery ensures code is always in a deployable state but requires manual approval. Continuous deployment automates the release to production. Many candidates conflate delivery and deployment — pressing on this reveals genuine understanding.
4. How do you measure the success of a DevOps transformation?
Look for the DORA State of DevOps metrics: deployment frequency, lead time for changes, change failure rate, and mean time to recovery. Candidates who cite only velocity without mentioning stability are showing an incomplete picture.
5. What is the relationship between DevOps and Agile? Are they the same thing?
They are complementary but distinct. Agile optimises how software is planned and built; DevOps optimises how it is delivered and operated. Strong answers explain how Agile without DevOps creates a bottleneck at deployment — working software piles up waiting for manual release.
CI/CD Pipeline Questions (5 Questions)
These questions evaluate hands-on experience building and maintaining automated pipelines.
6. Walk us through how you would design a CI/CD pipeline from scratch for a microservices application.
Expect a structured answer: source control strategy, automated builds, unit and integration testing, artefact storage, environment promotion, and deployment strategy (canary or blue-green). Senior candidates should mention security scanning and rollback mechanisms.
7. How do you handle database schema changes in a CI/CD pipeline?
This is a common pain point. Look for migration tools (Flyway, Liquibase), backward-compatible migrations, expand-and-contract patterns, and testing migrations against production-like data before promoting.
8. What strategies do you use for managing secrets in CI/CD pipelines?
Candidates should never store secrets in source control. Expect references to vault solutions (HashiCorp Vault, AWS Secrets Manager), environment variable injection, short-lived credentials, and the principle of least privilege.
9. How do you reduce build times in a large CI/CD pipeline without sacrificing test coverage?
Look for practical techniques: parallelising test suites, caching dependencies and Docker layers, running only affected tests on incremental changes, and separating fast feedback loops from comprehensive test suites.
10. Describe a situation where a CI/CD pipeline failure in production taught you something valuable.
Self-awareness and a blameless post-mortem mindset matter here. The best answers explain what broke, why existing safeguards missed it, and what systemic change was implemented to prevent recurrence.
Containers, Docker, and Kubernetes (5 Questions)
Containerisation is central to modern DevOps. These questions test practical understanding beyond the basics.
11. Explain the difference between a container and a virtual machine. When would you choose one over the other?
Containers share the host OS kernel and are lightweight; VMs include a full OS and provide stronger isolation. Strong answers discuss use cases — containers for microservices and rapid scaling, VMs for workloads requiring kernel-level isolation or different operating systems.
12. How do you optimise a Dockerfile for production use?
Look for multi-stage builds, minimal base images (Alpine, distroless), ordering layers for cache efficiency, avoiding running as root, removing build dependencies from the final image, and vulnerability scanning with tools like Trivy or Snyk.
13. Describe how Kubernetes manages self-healing and what happens when a pod fails.
Candidates should explain the control loop: desired state is declared, controllers continuously reconcile actual state with desired state. When a pod crashes or fails a liveness probe, Kubernetes restarts it. If a node fails, the scheduler places replacement pods on healthy nodes.
14. How do you handle persistent storage in Kubernetes, and what challenges does it present?
Expect PersistentVolumes, PersistentVolumeClaims, and StatefulSets. Key challenges include data locality (pods may move between nodes), backup and recovery, and network-attached storage latency. Senior candidates should evaluate whether managed cloud databases are more appropriate than self-managed Kubernetes deployments.
15. What is a Kubernetes Operator, and when would you build one rather than using standard resources?
An Operator extends Kubernetes with custom controllers that encode operational knowledge — scaling, backup, failover. You build one when lifecycle management is complex enough that manual runbooks are error-prone. For simpler applications, Helm charts suffice.
Infrastructure as Code (5 Questions)
These questions assess whether candidates can manage infrastructure reliably and repeatably.
16. What is infrastructure as code, and why is it critical for DevOps?
IaC means defining infrastructure through machine-readable configuration files rather than manual processes. It enables version control, peer review, automated testing, and reproducible environments. Candidates should emphasise idempotency and drift detection.
17. Compare Terraform and a cloud-native IaC tool such as AWS CloudFormation. When would you choose one over the other?
Terraform is cloud-agnostic with a rich provider ecosystem; CloudFormation is tightly integrated with AWS. Strong answers discuss multi-cloud strategy, state management trade-offs, and team expertise rather than declaring one tool universally superior.
18. How do you manage Terraform state in a team environment, and what problems can arise?
Look for remote state backends (S3 + DynamoDB, Terraform Cloud), state locking to prevent concurrent modifications, state file security (it may contain secrets), and strategies for handling state drift or corruption.
19. What testing strategies do you apply to infrastructure code?
Expect layered testing: static analysis (tflint, checkov), policy-as-code (OPA, Sentinel), integration tests in ephemeral environments, and running terraform plan in CI. Use skills mapping to ensure team members are trained on these practices.
20. Describe the immutable infrastructure pattern and how it differs from mutable infrastructure management.
Mutable infrastructure is patched in place; immutable infrastructure is replaced entirely with each change. Immutability eliminates configuration drift and simplifies rollback but requires a robust image-building pipeline. Strong answers articulate the trade-offs rather than treating immutability as universally correct.
Monitoring and Observability (5 Questions)
These questions test whether candidates can keep systems healthy after deployment.
21. What is the difference between monitoring and observability? Why does the distinction matter?
Monitoring tells you when something is wrong through predefined checks. Observability — built on structured logs, metrics, and distributed traces — lets you investigate novel problems in complex distributed systems where failure modes cannot be predicted in advance.
22. How would you design an alerting strategy that avoids alert fatigue?
Look for: alert on user-facing symptoms (error rates, latency) rather than internal causes, tiered severity levels, thresholds based on historical baselines, escalation policies, and quarterly alert review and pruning. Every alert should have a documented response procedure.
23. Explain distributed tracing and how it helps debug microservices architectures.
A distributed trace follows a single request across multiple services, with each service creating a span linked by a shared trace ID. When a request is slow or fails, the trace pinpoints which service contributed the latency or error.
24. What are SLIs, SLOs, and SLAs, and how do they relate to each other?
SLIs (Service Level Indicators) measure service behaviour. SLOs (Service Level Objectives) set target values. SLAs (Service Level Agreements) are contractual commitments. Strong answers also explain error budgets — the gap between current performance and the SLO that balances reliability investment against feature velocity.
25. Describe your approach to incident management from alert to post-mortem.
Look for a structured response: alert triage, incident commander designation, stakeholder communication, prioritising mitigation over root cause analysis, blameless post-mortems within 48 hours, and — critically — tracking follow-up action items to completion.
System Design and Architecture (5 Questions)
These questions assess a candidate's ability to think about large-scale systems and architectural trade-offs.
26. How would you design a deployment strategy for a globally distributed application requiring zero downtime?
Expect canary or blue-green deployments, geographic routing, automated rollback triggers based on SLO violations, and backward-compatible database changes so both application versions can run simultaneously during rollout.
27. How would you architect a disaster recovery strategy with a target RTO of 15 minutes and RPO of 5 minutes?
Look for multi-region deployments, synchronous or near-synchronous data replication, automated failover triggered by health checks, infrastructure as code for the standby region, and quarterly DR testing. Use salary benchmarking to ensure your team is resourced for this level of expertise.
28. How do you decide between a monolithic and microservices architecture? What are the DevOps implications?
There is no single right answer. Monoliths suit small teams and early-stage products. Microservices enable independent deployment but multiply operational complexity — requiring robust CI/CD, service discovery, distributed tracing, and container orchestration. Strong candidates advise starting monolithic and extracting services when justified.
29. What is GitOps, and how does it change infrastructure and application management?
GitOps uses Git as the single source of truth for declarative infrastructure. A reconciliation controller (ArgoCD, Flux) continuously compares actual state to the repository and corrects drift. Look for discussion of the audit trail and security benefits — direct cluster access is no longer necessary for routine changes.
30. How do you manage configuration across dozens of microservices and multiple environments without duplication?
Expect the twelve-factor methodology (configuration in the environment, not in code), hierarchical configuration systems (global defaults, environment overrides, service-specific overrides), central configuration stores, and feature flags for runtime behaviour changes.
Junior vs Senior Level Guidance
The same questions work at different levels, but expectations shift significantly.
Junior candidates (0-2 years) should demonstrate solid foundational knowledge and hands-on experience with at least one tool in each category. Assess learning velocity — probe for personal projects, home labs, and certifications that demonstrate initiative.
Mid-level candidates (2-5 years) should articulate trade-offs, not just implementation details. Expect experience with production incidents and evidence of blameless post-mortem culture.
Senior candidates (5+ years) should demonstrate systems thinking across the entire delivery lifecycle, discuss organisational design (Conway's Law), and reference DORA metrics and error budgets. They should show experience mentoring engineers and building team capability — use our skills mapping framework to assess this dimension.
Preparation Tips for Candidates
Build a portfolio of real work. Contribute to open-source projects, build a home lab with Kubernetes and Terraform, or document a personal CI/CD pipeline on GitHub. Demonstrated experience outweighs theoretical knowledge.
Understand principles before tools. Tools change; concepts persist. Invest more time understanding why a pipeline is designed a particular way than memorising specific tool configurations.
Prepare incident stories. Structure answers using the situation-action-result framework. Emphasise what you learned and what systemic change resulted, not just the heroic fix.
Study the DORA metrics. The DORA State of DevOps report is the industry standard. Understanding these metrics demonstrates maturity and data-driven thinking.
Research the company. Check Glassdoor for interview experiences, review the company's tech blog, and tailor your examples to their context and scale.
Practise system design. DevOps interviews increasingly include design rounds. Practise designing deployment pipelines, monitoring architectures, and disaster recovery strategies on a whiteboard.
Frequently Asked Questions
What is the difference between a DevOps engineer and a site reliability engineer (SRE)?
DevOps is a set of practices aimed at unifying development and operations. SRE, originated at Google, applies software engineering principles to operations problems. SRE emphasises reliability targets (SLOs, error budgets) while DevOps emphasises automation, CI/CD, and cross-team collaboration. The roles overlap significantly, and many organisations use the titles interchangeably.
How many DevOps interview rounds should we expect?
Most processes include three to five rounds: recruiter screen, technical phone screen, system design round, hands-on coding or infrastructure challenge, and cultural fit conversation. Senior roles may add an architecture review. Structure your process using our recruitment guide to ensure consistency.
Should DevOps interviews include live coding or hands-on labs?
Yes. Hands-on assessment is one of the strongest predictors of on-the-job performance. Consider a broken CI/CD pipeline to fix, a Dockerfile to optimise, or a Terraform configuration to review. Time-box the exercise (60-90 minutes) and pair it with your interview scorecard for structured evaluation.
What certifications are most valued for DevOps roles?
The most recognised are AWS Certified DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), HashiCorp Certified Terraform Associate, and Google Professional Cloud DevOps Engineer. Certifications demonstrate baseline competence but are not substitutes for hands-on experience. Ask candidates how they applied certification knowledge to real-world problems.