🎁 Sign up now — get up to 30 minutes of online AI use free. No credit card required.

DevOps Interview Questions and Answers (2026): CI/CD, Containers, and Incidents

October 9, 2026
20 DevOps interview questions with answers: CI/CD, deployment strategies, infrastructure as code, containers, monitoring, SLOs, incidents, and how to prepare.
DevOps Interview Questions and Answers (2026): CI/CD, Containers, and Incidents
devops interview questions
devops interview
ci cd interview questions
blue green vs canary
sre interview questions

DevOps interviews test whether you can ship software reliably: how code gets from a laptop to production, how you know it's healthy, and what you do when it isn't. Below are 20 questions with answers, from the basics to the scenario questions that decide most interviews. Where a command is shown, it's a standard one you can check in the tool's own documentation.

Fundamentals

1. What is DevOps?

A way of working that brings development and operations together so software is built, tested, released, and run by the same shared process. The goals are faster, safer releases and quicker recovery when something breaks. It's a culture and a set of practices, with tools in support, not a job title alone.

2. What is the difference between continuous integration, continuous delivery, and continuous deployment?

PracticeWhat it means
Continuous integrationDevelopers merge small changes often, and each merge triggers an automated build and test run
Continuous deliveryEvery change that passes the pipeline is ready to release, and a person decides when
Continuous deploymentEvery change that passes the pipeline is released to production automatically

3. What are the key metrics for software delivery?

Four are widely used, from the DORA research program: deployment frequency, lead time for changes, change failure rate, and time to restore service. The first two measure speed, and the last two measure stability. A good answer explains that you track all four so you don't improve speed by sacrificing stability.

4. What does a good CI pipeline look like?

  1. Check out the code and restore cached dependencies.
  2. Build.
  3. Run fast tests first (unit tests), then slower ones.
  4. Run static checks, such as linting and a dependency vulnerability scan.
  5. Build an artifact (a container image or package) once and tag it with the commit.
  6. Publish it, and deploy the same artifact through every environment.

The key idea is to build once and promote the same artifact, so what you tested is what you ship.

Version control and releases

5. How do you branch and release?

Two common approaches. Trunk-based development merges small changes to the main branch often, with feature flags to hide unfinished work. Branch-based workflows such as GitFlow use long-lived branches for releases. Trunk-based development usually pairs better with continuous delivery, because merges are small and frequent.

6. What are blue-green and canary deployments?

StrategyHow it worksRollback
Blue-greenTwo identical environments. Deploy to the idle one, test it, then switch trafficSwitch traffic back
CanarySend a small share of traffic to the new version, watch the metrics, and increase graduallySend the share back to zero
RollingReplace instances a few at a timeRoll forward or reverse the roll

Blue-green costs extra capacity. Canary needs good metrics, because you decide on the data.

7. What is a feature flag, and why use one?

A switch in configuration that turns a feature on or off without a deployment. It separates deploying code from releasing a feature, lets you test with a small group, and gives you a fast off-switch if something goes wrong. The cost is that old flags pile up, so remove them once a feature is stable.

8. How do you roll back safely?

Keep the previous artifact available, make deploys repeatable, and make database changes backward compatible, so the old version still works against the new schema. A rollback plan that ignores the database isn't a plan. For risky changes, prefer rolling forward with a fix when a rollback would lose data.

Infrastructure and containers

9. What is infrastructure as code?

Defining servers, networks, and permissions in version-controlled files instead of clicking in a console. It makes environments repeatable, reviewable, and easy to rebuild. Common tools include Terraform, Pulumi, and the cloud providers' own templates. See our Terraform interview questions.

10. What is the difference between a container and a virtual machine?

A virtual machine includes a full guest operating system on top of virtualized hardware. A container shares the host's kernel and packages only the application and its dependencies, so it starts faster and uses less memory. Containers give less isolation than a virtual machine.

11. What goes in a good Dockerfile?

Use a small, specific base image, order the layers so the ones that change least come first (to use the build cache), copy dependency files and install before copying source code, run as a non-root user, and don't bake secrets into the image. Multi-stage builds keep build tools out of the final image.

12. Why Kubernetes?

It schedules containers across machines, restarts failed ones, scales them, and handles rolling updates and service discovery. It also adds a lot of complexity, so a good answer says when you wouldn't use it, such as a small app that fits on a few servers or a managed platform. See our Kubernetes interview questions.

13. How do you manage secrets?

Never put them in source control or images. Use a secrets manager or the platform's secret store, give each service the minimum access it needs, rotate secrets, and avoid printing them in logs. Say what you'd do if one leaked: revoke it, rotate it, and check the logs for use.

Reliability and operations

14. What are monitoring, logging, and tracing?

SignalTells you
MetricsHow the system is doing over time, such as error rate and latency
LogsWhat happened in a specific event
TracesHow one request moved through several services

Alert on symptoms users feel, such as errors and slow responses, more than on causes, such as high CPU on one machine.

15. What are SLIs, SLOs, and SLAs?

A service level indicator is a measurement, such as the share of requests that succeed. A service level objective is the target for it, such as 99.9 percent over 30 days. A service level agreement is a promise to customers, often with consequences if missed. The gap between 100 percent and the SLO is an error budget: the room you have for risk and change.

16. A production service is slow. What do you do?

  1. Check whether it's real and who's affected, using dashboards and error rates.
  2. Check what changed recently: a deployment, a configuration change, a traffic spike.
  3. Narrow it down: a specific endpoint, region, or dependency.
  4. Look at resources (CPU, memory, connections) and at downstream services.
  5. If a recent change is the likely cause, roll it back first and investigate afterward.
  6. Communicate status while you work.

Interviewers are listening for a calm, ordered approach and for mitigating before finding the root cause.

17. What is a blameless postmortem?

A written review after an incident that focuses on how the system and process allowed the failure, not on who made a mistake. It covers the timeline, the impact, the causes, and concrete follow-up actions with owners. The point is to learn and to make the same failure harder to repeat.

18. What is the difference between horizontal and vertical scaling?

Vertical scaling gives a machine more resources. Horizontal scaling adds more machines. Vertical is simple but has a ceiling and a single point of failure. Horizontal scales further and survives the loss of one machine, but needs stateless services or shared state.

Practical

19. How do you secure a pipeline?

Limit who can change the pipeline and who can deploy to production. Scan dependencies and images for known vulnerabilities, sign and verify artifacts, keep credentials short-lived and scoped, and review changes to pipeline files like code. A build agent with broad permissions is a favorite target.

20. Tell me about a deployment that went wrong.

This is a behavioral question inside a technical interview. Use a short story: what changed, how you noticed, what you did first (usually mitigate, often by rolling back), what you found, and what you changed afterward so it can't repeat. Blameless wording and a concrete follow-up are what interviewers look for.

How to prepare

  1. Build a small pipeline end to end: a repository, a build, a test run, a container, and a deployment to something you can reach.
  2. Be ready to explain one incident or failed release in your own experience.
  3. Practice the "service is slow" answer out loud until it's a calm, ordered list.
  4. Know one tool well in each area, such as CI, containers, infrastructure as code, and monitoring, rather than a long list of names.

For related practice, see our guides to AWS interview questions, Terraform interview questions, Kubernetes interview questions, and computer networking interview questions.

Practice aloud and in your own words. A transcript afterward shows where you rambled or skipped the point. Follow the employer's rules on AI tools in any live interview or assessment.

Practice your answers with YesToTheOffer

Rehearse out loud, get answers built from your own resume, and review your transcript afterward. 30 free minutes, no subscription.

iOS & Android — Coming Soon
See pricing