Interview guide · Technology roles
DevOps engineer interview questions
In short
Good DevOps engineer interview questions test how a candidate builds and secures CI/CD pipelines, manages cloud infrastructure as code, runs containers in production, designs monitoring and alerting, and handles incidents and blameless reviews. Below are 32 questions for DevOps, cloud and site reliability engineers, with what strong answers include, red flags, sample answers and a scorecard.
DevOps titles cover a wide range. In one company the DevOps engineer owns CI/CD pipelines and Terraform; in another they're effectively an SRE with an error budget and a pager; in a third they're the person who knows the cloud bill. Before interviewing, write down which of those jobs you're hiring for. The common thread is an engineer who removes manual work, makes deployments boring and safe, and treats infrastructure like software, with version control, review and tests.
Use these questions for DevOps engineers, cloud engineers and site reliability engineers. Pick six to eight across the groups for a 60-minute technical round, adjusting the depth to your stack (AWS, Azure or GCP; Kubernetes or a managed container service; GitHub Actions, GitLab CI or Jenkins). Ask the same core questions of every candidate for the role and score immediately against the scorecard. Push on trade-offs. Almost any DevOps question has a 'depends' answer, and strong candidates explain what it depends on.
What to look for in a devops engineer
- Automation by defaultThe value of the role is removing toil. Candidates should describe things they've automated, not things they do carefully by hand each time.
- Production ownershipEngineers who've carried a pager understand monitoring, rollback and incident response in a way that people who only built pipelines don't.
- Security built into deliverySecrets management, least-privilege IAM, dependency scanning and image hardening belong in the pipeline. Treating security as a later step creates real exposure.
- Cost awarenessCloud spend is often the second-largest technology cost. Engineers who right-size, tag and review spend save more than their salary in some teams.
- Collaboration with developersDevOps works through other teams. Good candidates build paved roads and self-service rather than becoming a ticket queue.
- Clear reasoning about trade-offsKubernetes or not, monorepo or not, canary or blue-green: the right answer depends on context. Strong engineers explain the factors, not their favorite tool.
Opening questions
Describe the delivery pipeline you work with today, from a developer's commit to production.
- Why ask it
- Shows real exposure and level of ownership.
- A strong answer
- Walks through source control, build, tests, artifact storage, security scans, deployment strategy, approvals, and post-deploy checks, naming the tools and what they built or changed.
- Red flags
- Can only describe one stage, or the pipeline someone else owns.
How do you define DevOps, in terms of what you actually do day to day?
- Why ask it
- Filters buzzwords from practice.
- A strong answer
- Talks about shortening feedback loops, automation, shared ownership of production, and measurable outcomes such as deployment frequency or recovery time, tied to their own work.
- Red flags
- Defines it as a toolset or a team that deploys for developers.
What's the most valuable piece of automation you've built?
- Why ask it
- Concrete impact.
- A strong answer
- Specific problem, tool, how it was tested and adopted, and measurable result, such as environment creation going from two days to 20 minutes.
- Red flags
- No measurable impact or no adoption by others.
Which cloud platforms have you run production workloads on, and which services do you know well?
- Why ask it
- Maps experience to your stack.
- A strong answer
- Honest depth on one or two platforms with specific services (compute, networking, IAM, managed databases, queues), and how they'd ramp on a different one.
- Red flags
- Long list of logos, no depth on any.
CI/CD and infrastructure as code
How would you design a CI/CD pipeline for a new web service with a database?
- Why ask it
- Core design question.
- A strong answer
- Build once and promote the same artifact, unit and integration tests, linting and security scans, environment parity, database migrations handled safely (backward-compatible changes), automated deploy with health checks and rollback, and fast feedback to developers.
- Red flags
- Rebuilds per environment or ignores database changes.
Compare blue-green, canary and rolling deployments. When would you choose each?
- Why ask it
- Deployment strategy judgment.
- A strong answer
- Blue-green for fast switch and rollback at double capacity cost; canary to test with a small share of traffic and metrics; rolling for simplicity when brief mixed versions are acceptable. Mentions feature flags as a complement.
- Red flags
- Knows only one approach.
How do you structure Terraform (or similar) for multiple environments and teams?
- Why ask it
- Infrastructure as code at scale.
- A strong answer
- Reusable modules, separate state per environment or component, remote state with locking, variables per environment, code review and plan output in pull requests, and pinned provider versions.
- Red flags
- One giant state file or local state on a laptop.
Someone changed a resource by hand in the console, and Terraform now wants to revert it. What do you do?
- Why ask it
- Drift handling and team process.
- A strong answer
- Finds out why, decides whether the change should be codified or reverted, imports or updates code accordingly, and addresses the access or process gap that allowed the change.
- Red flags
- Blindly applies and breaks something, or ignores drift.
How do you handle secrets in pipelines and applications?
- Why ask it
- Common source of breaches.
- A strong answer
- Secrets manager or vault, short-lived credentials and workload identity rather than static keys, no secrets in code or logs, scanning for leaks, rotation, and scoped access.
- Red flags
- Environment variables committed to the repo or long-lived keys shared across teams.
How do you keep builds fast as a codebase grows?
- Why ask it
- Developer productivity.
- A strong answer
- Caching dependencies and layers, parallel jobs, running only affected tests where safe, splitting slow suites, right-sized runners, and tracking build time as a metric.
- Red flags
- Accepts 45-minute builds as normal.
Containers, cloud and reliability
Explain what happens when you run kubectl apply on a Deployment.
- Why ask it
- Tests real Kubernetes understanding.
- A strong answer
- API server validates and stores the object in etcd, the deployment controller creates or updates a ReplicaSet, the scheduler places pods on nodes, kubelet pulls images and starts containers, and readiness probes gate traffic through Services.
- Red flags
- Only knows the command, not the control loop.
A pod is in CrashLoopBackOff. How do you troubleshoot?
- Why ask it
- Everyday Kubernetes debugging.
- A strong answer
- kubectl describe for events, logs including the previous container, checks config, secrets, resource limits (OOMKilled), probes that fail too early, and image or command errors.
- Red flags
- Deletes the pod and hopes.
When would you not use Kubernetes?
- Why ask it
- Judgment over hype.
- A strong answer
- Small teams or simple workloads where managed platforms, serverless or plain VMs are cheaper to run; Kubernetes adds operational overhead that needs skills and time.
- Red flags
- Kubernetes for everything.
How do you make a container image secure and small?
- Why ask it
- Supply chain basics.
- A strong answer
- Minimal or distroless base images, multi-stage builds, non-root user, pinned versions, vulnerability scanning in CI, signed images and regular rebuilds for patches.
- Red flags
- Uses latest tags and runs as root.
What are SLIs, SLOs and error budgets, and how have you used them?
- Why ask it
- SRE fundamentals.
- A strong answer
- SLIs measure user-facing behavior (latency, availability), SLOs set targets, error budgets allow a set amount of unreliability and guide whether to ship features or fix reliability. Gives a real example.
- Red flags
- Equates SLOs with uptime of servers.
What do you monitor and alert on for a web service?
- Why ask it
- Observability design.
- A strong answer
- User-facing signals first (latency, errors, traffic, saturation), logs and traces for diagnosis, alerts tied to symptoms and SLOs, runbooks linked from alerts, and pruning noisy alerts.
- Red flags
- Alerts on every CPU spike.
How have you reduced cloud costs?
- Why ask it
- Cost ownership.
- A strong answer
- Specific actions such as right-sizing, autoscaling, reserved or savings plans, spot for suitable workloads, storage lifecycle rules, deleting idle resources, and tagging for accountability, with numbers.
- Red flags
- Never looked at the bill.
How would you design for a region outage on your cloud provider?
- Why ask it
- Resilience thinking.
- A strong answer
- Defines recovery objectives first, then multi-AZ as baseline, backups or replication to another region, infrastructure as code to rebuild, DNS failover, and regular tests. Explains cost trade-offs.
- Red flags
- Assumes the cloud never fails or proposes active-active everywhere regardless of cost.
Incidents and behavioral questions
Walk me through an incident you led or took part in.
- Why ask it
- Real production experience.
- A strong answer
- Timeline, detection, mitigation before root cause, communication, roles (incident lead, communications), the blameless review and follow-up actions completed.
- Red flags
- No incident experience or a story focused on blame.
A deployment went out and error rates doubled. What do you do?
- Why ask it
- Mitigation instinct.
- A strong answer
- Rolls back or disables the feature flag first, confirms recovery, then investigates. Communicates status and records a timeline.
- Red flags
- Debugs in production for an hour before rolling back.
Tell me about a time you got developers to adopt a new tool or practice.
- Why ask it
- Influence without authority.
- A strong answer
- Understood developer pain, built a paved path that was easier than the old way, documented and supported it, and measured adoption.
- Red flags
- Mandated it and blamed developers for resisting.
Describe a time you disagreed with an architecture decision.
- Why ask it
- Constructive disagreement.
- A strong answer
- Raised concerns with evidence, proposed alternatives, accepted the outcome or escalated properly, and helped make the final choice work.
- Red flags
- Undermined the decision or never speaks up.
Tell me about something in production you broke and what you learned.
- Why ask it
- Ownership and learning.
- A strong answer
- Specific, honest, with the guardrail they added afterwards (tests, approvals, automation).
- Red flags
- Claims never to have broken anything.
How do you balance on-call and project work?
- Why ask it
- Sustainability.
- A strong answer
- Tracks toil, protects project time, rotates on-call fairly, fixes recurring pages, and pushes back when interrupt load is too high.
- Red flags
- Accepts constant firefighting as normal.
Situational questions
A team wants production database access to debug an issue. How do you respond?
- Why ask it
- Security versus speed.
- A strong answer
- Offers read-only, time-limited, audited access or a sanitized copy, follows the access process, and looks at better observability so this isn't needed next time.
- Red flags
- Shares admin credentials.
Your first week, you find no infrastructure as code: everything was built by hand. What's your plan?
- Why ask it
- Prioritization in a messy environment.
- A strong answer
- Documents what exists, protects backups, starts codifying new resources first, imports critical existing ones gradually, and avoids a risky big-bang rebuild.
- Red flags
- Proposes rebuilding everything immediately.
A vulnerability scanner reports 400 findings in your container images. Where do you start?
- Why ask it
- Risk-based prioritization.
- A strong answer
- Prioritizes by severity, exploitability and exposure, fixes base images first since one change clears many findings, sets policy for new builds, and tracks trends.
- Red flags
- Tries to fix all 400 in order or ignores them.
Leadership wants daily deployments; today you deploy monthly. How would you get there?
- Why ask it
- Transformation thinking.
- A strong answer
- Measures current lead time and failure rate, automates testing and deployment, reduces batch size, adds feature flags and monitoring, and moves step by step with one team first.
- Red flags
- Just increases release frequency without safety nets.
Questions for senior DevOps and SRE candidates
How would you build an internal developer platform without creating a bottleneck team?
- Why ask it
- Platform thinking.
- A strong answer
- Treats developers as customers, offers self-service templates and golden paths, measures adoption and satisfaction, and keeps escape hatches for special cases.
- Red flags
- Builds a ticket queue.
Which delivery metrics would you report to leadership?
- Why ask it
- Measuring outcomes.
- A strong answer
- Deployment frequency, lead time for changes, change failure rate and time to restore service (the DORA measures), plus reliability against SLOs and cost, with context rather than targets for their own sake.
- Red flags
- Reports number of tickets closed.
How do you approach compliance requirements such as SOC 2 in a DevOps environment?
- Why ask it
- Regulated environments.
- A strong answer
- Automates evidence (change approvals in pull requests, access reviews, logging), uses policy as code, and designs controls that don't slow delivery unnecessarily.
- Red flags
- Treats compliance as manual screenshots once a year.
How would you grow a junior engineer on your team?
- Why ask it
- Leadership and mentoring.
- A strong answer
- Pairs on real work, gives graded ownership, reviews code thoughtfully, involves them in on-call with backup, and sets clear learning goals.
- Red flags
- No interest in mentoring.
Sample answers
First I'd stop the bleeding. If the deploy is the obvious suspect, I roll back or switch off the feature flag right away instead of debugging live. I'd post in the incident channel that we've seen the spike, what we're doing and when the next update is. Once error rates are back to normal, I'd confirm with a couple of key dashboards and a synthetic check. Then the investigation starts: diff the release, check logs and traces for the failing endpoints, and reproduce in staging. Afterwards we'd do a blameless review. Usually the real fix is twofold: the bug itself, and whatever let it through, like a missing integration test or a canary step that wasn't watching the right metric.
At my last company we had shared modules in their own repository, versioned with tags, for things like a VPC, a service with load balancer and a database. Each environment had its own directory and its own remote state in S3 with DynamoDB locking, so a bad plan in dev couldn't touch prod. We split state by component as well, so networking, data and app layers changed independently and plans stayed fast. Every change went through a pull request that ran plan and posted the output as a comment, and applies to prod ran from the pipeline only after approval. Provider and module versions were pinned, and we had a weekly drift check that opened a ticket if anything changed outside Terraform.
When the team is small and the workload is simple. Kubernetes is great when you have many services, need consistent deployment and scaling, and have people who can run it, even with a managed control plane. But it brings upgrades, networking, security policies and a lot of YAML. For a company with three services and two engineers, a managed container service or serverless functions usually gets them to production faster with less to maintain. I'd look at the number of services, traffic patterns, team skills and growth plans before choosing. I've seen a startup spend half its infrastructure time on cluster upgrades that a simpler platform would have avoided.
Interview scorecard
| Competency | Weight | Strong (4–5) | Weak (1–2) |
|---|---|---|---|
| CI/CD and infrastructure as code | 25% | Designs pipelines that build once, test well and deploy safely; structures IaC with modules, remote state and review. | Manual steps, rebuilds per environment, local state or no IaC. |
| Cloud and container operations | 20% | Explains how platforms work underneath, troubleshoots containers and designs for failure and cost. | Tool names without understanding, no resilience or cost thinking. |
| Reliability, monitoring and incidents | 20% | Symptom-based alerting, SLOs, rollback first, blameless reviews with completed actions. | Noisy or missing alerts, debugs live before mitigating, blames people. |
| Security in delivery | 15% | Secrets management, least privilege, scanning and hardened images built into pipelines. | Static keys in repos, root containers, security left for later. |
| Collaboration and influence | 10% | Builds self-service paths developers want to use, disagrees constructively, mentors. | Gatekeeps, creates ticket queues, or dismisses developer needs. |
| Trade-off reasoning | 10% | Explains what a decision depends on and adapts to team size and context. | One favorite tool for every problem. |
Score each competency from 1 to 5 straight after the interview, before discussing the candidate with anyone else, then multiply by the weight.
How to structure a DevOps engineer interview
A practical loop for most DevOps, cloud and SRE roles:
- Recruiter screen (20 to 30 minutes). Confirm cloud platforms, on-call expectations, team model and salary range. A recruiter who understands the stack screens far better; our technical recruiter interview questions cover what to look for when hiring that recruiter.
- Technical interview (60 minutes). Pipeline design, one infrastructure-as-code question, one container or cloud question and one monitoring question, with follow-ups on trade-offs.
- Practical exercise (60 to 90 minutes, or a short take-home capped at two hours). Debug a broken pipeline or Kubernetes deployment in a sandbox, or review a Terraform pull request with deliberate problems. Reviewing is often more revealing than writing from scratch.
- Incident and behavioral round (45 minutes) with the hiring manager and a developer from a team the engineer would support.
Keep the whole process under three weeks; experienced DevOps engineers usually have several processes running at once. Online technical assessments on Linux, scripting or cloud basics can replace an early technical call for high applicant volumes.
Mistakes interviewers make
Hiring for a tool list. Requiring five years of a specific CI tool screens out strong engineers who used a different one. Test concepts and reasoning; tool syntax takes weeks to learn.
Skipping production experience. A candidate who has only built pipelines but never been paged may struggle in an SRE-style role. Ask about incidents directly.
Long unpaid take-homes. Eight-hour assignments drive away the best candidates. Keep take-homes short or do the exercise live.
Not involving developers. DevOps engineers succeed or fail on how developers experience them. Include a developer interviewer, and borrow a question or two from the software engineer interview questions if the role writes significant application code.
Confusing DevOps with systems administration. There's overlap, and many good DevOps engineers started as sysadmins, but the emphasis on code, review and automation is different. If the role is mostly server care and patching, our system administrator interview questions may fit better.
Interviewing cloud engineers and SREs
For cloud engineer roles, weight the cloud and infrastructure-as-code questions more heavily and add a design exercise, such as laying out networking and IAM for a three-tier application across environments. For site reliability engineers, weight SLOs, monitoring and incidents, and ask for a coding exercise relevant to operations, such as parsing logs or writing a small tool against an API.
Whichever title you use, write down in the job posting what the person will actually own in their first six months. It sets expectations, attracts the right applicants and gives interviewers a shared reference for scoring.
Frequently asked questions
What are common DevOps interview questions?
Expect questions about designing a CI/CD pipeline, deployment strategies such as canary and blue-green, infrastructure as code with Terraform, Kubernetes troubleshooting, secrets management, monitoring and alerting, incident response and reducing cloud costs.
What should I ask in a cloud engineer interview?
Ask about the cloud services they have run in production, networking and IAM design, infrastructure as code structure, cost optimization, high availability and disaster recovery, and how they would migrate a workload from on-premises.
How are site reliability engineer interview questions different?
SRE interviews focus more on SLIs, SLOs and error budgets, observability, incident command, capacity planning and coding to reduce toil, often with a coding exercise and a system design discussion.
Do DevOps engineer interviews include a coding test?
Often a light one: scripting in Python, Go or Bash, writing or reviewing Terraform, or debugging a pipeline or container setup. Full algorithm tests are less common than for software engineers.
What experience should a DevOps engineer candidate have?
Typically hands-on work with a major cloud platform, a CI/CD tool, infrastructure as code, containers, Linux and scripting, plus some production on-call or incident experience.