In this article
- Start here: the learning path
- Linux commands and the shell
- Continuous integration and Jenkins
- Deployment strategies
- Kubernetes
- Infrastructure as code
- Monitoring, reliability and incidents
- Incidents: what to check first
- Cloud architecture
- Questions interviewers ask on DevOps
- All 15 guides in DevOps and cloud
- Follow-up questions
- Sources
Start here: the learning path
DevOps questions are easiest to study in order, because each topic is easier once you know the ones before it. Amazon Web Services (AWS) describes DevOps as "the combination of cultural philosophies, practices, and tools" for delivering applications quickly, and lists continuous integration, continuous delivery, infrastructure as code, and monitoring and logging among the core practices (AWS, read October 2026). The path below covers that list and adds the command line, deployment strategies and Kubernetes, starting with the command line you will use every day and ending with cloud architecture, which draws on all the others. One line per step, in order:
- Linux commands: the shell you use every day, taught in Linux commands: what the basic ones do, and how to combine them.
- Build and test: the pipeline between a commit and a release, taught in what is Jenkins.
- Deployment: how a new version replaces the old one, taught in deployment strategies.
- Kubernetes: how containers are run and kept in shape, taught in Kubernetes interview questions and answers.
- Infrastructure as code: environments described in files, covered in the infrastructure-as-code section below.
- Monitoring and incidents: service targets and what to check first in an outage, covered in the reliability and incidents sections below.
- Cloud architecture: choosing and placing managed services, taught in cloud architect interview questions.
The sections that follow give one short answer per topic.
- DevOps
- DevOps is a way of working in which the people who build software and the people who operate it share responsibility for it, using automation and measurement to release changes often and recover from failures fast.
- Continuous integration and continuous delivery
- Continuous integration (CI) and continuous delivery (CD) together form an automated pipeline that builds and tests every merged code change and prepares it for release, so that a release is a routine action and not a special event.
- Infrastructure as code
- Infrastructure as code is the practice of describing servers, networks and other infrastructure in text files that are kept in version control and applied by a tool, so that an environment can be rebuilt the same way each time.
Text description of the diagram
- The path runs from Linux commands to monitoring and incident response.
- Deployment strategies sit between the automated pipeline and the cluster that runs the service.
- Kubernetes interview questions: pods, networking, storage, scheduling, security
- How does Terraform work, and why does state matter?
- What to do when a deploy broke production
Linux commands and the shell
Linux commands come first because many servers a DevOps engineer touches run Linux, and questions about a broken machine usually start at a terminal. An interviewer expects you to move around the file system, search logs, combine commands with pipes and read file permissions without looking anything up. The weak spots are the dangerous commands: one deletes with no confirmation, and one change of permissions can lock a service out of its own files. Learn the dozen commands that cover a working day, then practise chaining them on a real log file. The Linux commands guide teaches them one step at a time, with every example run in a container, and ends with the questions asked in DevOps interviews.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Continuous integration and Jenkins
A CI/CD pipeline is the second topic, and Jenkins is a long-established open-source pipeline server and a common interview example. In the AWS description, continuous integration means developers regularly merge code into a central repository where automated builds and tests run, and continuous delivery means changes are automatically built, tested and prepared for release (AWS, read October 2026).
Interviewers use these words to find out whether you know what a pipeline stage is, what happens when a test fails and who is told. If Jenkins is new to you, the page what is Jenkins explains the server, its jobs and its pipelines from the beginning. A good habit is to be able to draw your last pipeline from memory, stage by stage, and say where it can fail.
Deployment strategies
A deployment strategy is the plan for replacing the running version of a service with a new one, and it is a natural follow-up to a pipeline question. The four plans interviews ask about are recreate, rolling update, blue-green and canary (a Kubernetes Deployment has two of them built in, Recreate and RollingUpdate), and they trade downtime against cost against how many users a bad release reaches.
The Kubernetes documentation describes a rolling update as replacing pods (the smallest unit Kubernetes runs: one or more containers, which are packaged programs) gradually, controlled by a maximum number of unavailable and surplus pods (Kubernetes documentation, July 2026). The page on deployment strategies works through the same faulty release under each plan and counts the failed requests, and it gives a decision flow you can say aloud. Be ready for the question "how would you roll this out?"
Kubernetes
Kubernetes is the system that runs containers across a group of machines and keeps them in the shape you declared, and it is a common subject of DevOps interview questions. A container is a packaged program with everything it needs to run; Kubernetes starts them, restarts them when they fail, and moves traffic to the healthy ones. Interviews ask what a pod is, how a Deployment differs from a StatefulSet, what the control plane does and what happens when a node dies. The answered list at Kubernetes interview questions and answers covers these with sources from the official documentation. Learn the objects in the order a request meets them, and you can reason about questions you have not seen.
Infrastructure as code
Infrastructure as code is the fifth topic, and it answers a simple interview question: how do you know two environments are the same? When servers, networks and permissions are described in files under version control, a reviewer can read a change before it is applied, and a failed environment can be rebuilt from the files. Terraform is a widely used tool for it, with cloud-specific tools beside it. The tool keeps a state file, a record of which real resources it created from the files, and compares it with the files to decide what to change. Interviewers ask about state, what happens when two people apply at the same time, and how secrets are kept out of the files.
Monitoring, reliability and incidents
Monitoring turns "the service feels slow" into a number, and reliability engineering decides how much unreliability is acceptable, written as a service level objective (SLO), such as an availability target. The Google site reliability engineering (SRE) book says "100% is the wrong reliability target for basically everything" and defines an error budget as one minus the availability target, which a team can spend as long as it does not overspend (Google SRE book, 2017). In 30 days there are 43,200 minutes, so a 99.9% target allows 43.2 minutes of downtime and a 99.99% target allows 4.32.1 Interviewers use this to see whether you can connect a target to a release decision: a team near its budget slows down releases.
Text description of the diagram
- A 99.9% target allows 43.2 minutes of downtime in 30 days.
- A 99.99% target allows 4.32 minutes in 30 days.
The Google book also calls DevOps a generalisation of several core SRE principles to a wider range of organisations, and SRE a specific implementation of DevOps (Google SRE book, 2017). The DevOps Research and Assessment (DORA) programme at Google measures delivery with five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate (DORA, updated January 2026). Name two of them when asked how you would measure a team.
Incidents: what to check first
An incident question tests whether you restore service before you look for the cause. The Google SRE book warns that the first instinct in a major outage is to hunt for a root cause, and says to ignore it and make the system work as well as it can first (Google SRE book, 2017). The first thing to check is what changed: "Recent changes to a system can be a productive place to start identifying what's going wrong" (same source). If a release just went out, rolling it back is often the fastest repair. Then read the four golden signals, latency, traffic, errors and saturation (how full the service is), to find the failing part (Google SRE book, 2017).
Cloud architecture
Cloud architecture is the last topic, and it draws on all the others: choosing which managed services to use, how to place them across availability zones (separate groups of data centres within one region) and how to pay for them. The questions ask you to design a system on a cloud provider and to defend each choice on cost, reliability and security. Learn one provider deeply before comparing: the services have different names on AWS and Azure, but the ideas of compute, storage, network and identity map across. The page on cloud architect interview questions takes these design questions in turn, and the wider system design guide covers the whole-system version of the same problem.
Questions interviewers ask on DevOps
| Question (our wording) | Idea behind it | Where to learn it |
|---|---|---|
| Which commands would you use to find why a disk is full? | Shell and file system | Linux commands |
| What happens between a commit and production? | The pipeline | What is Jenkins |
| How would you release without downtime? | Deployment strategy | Deployment strategies |
| What does Kubernetes do when a node fails? | Declared state, reconciliation | Kubernetes questions |
| How do you keep two environments identical? | Infrastructure as code | Covered in the infrastructure-as-code section above |
| What would you check first in an outage? | Monitoring and incident order | Covered in the incidents section above |
Follow-up questions
How do I prepare for a DevOps interview?
Prepare in this order: shell commands, one pipeline you can draw, the four deployment strategies, the main Kubernetes objects, infrastructure as code and one reliability target with its error budget. Rehearse each answer aloud in under a minute. Then practise one scenario that crosses the topics, such as a bad release, and say what you check first; the interview loops overview shows how these rounds fit into a hiring process.
What are the most common DevOps interview questions?
They cluster around how you release, how you debug and how you keep things reliable: what a pipeline does, how a rolling update differs from a canary, what a pod is (the Kubernetes questions and answers list the common ones), what infrastructure as code gives you, and how you would handle an outage. The table above groups them by the idea behind each one.
What are the five pillars of DevOps?
There is no single official list, so say which one you use. The common answer is Culture, Automation, Lean, Measurement and Sharing (CALMS), an acronym Atlassian credits to Jez Humble (Atlassian, read October 2026); Google's Site Reliability Workbook gives another five: no more silos, accidents are normal, change should be gradual, tooling and culture are interrelated, and measurement is crucial (Google SRE workbook, 2018). AWS names six practices, including microservices, and does not call them pillars (AWS, read October 2026).
How should I study AWS and Azure interview questions?
Study one provider's core services in four groups, compute, storage, network and identity, and learn what each costs and how it fails. Then map the same four groups onto the other provider. Questions about either cloud usually test those groups and the design choices between them; the cloud architect questions practise them. Machine learning teams add one more layer, covered in the machine learning operations (MLOps) guide.
- Study DevOps in order: shell, pipeline, deployment, Kubernetes, infrastructure code, reliability; an incident question can touch all of them.
- Learn the idea behind each question, because the tool names change and the ideas do not.
- A 99.9% target allows 43.2 minutes of downtime in 30 days; know the arithmetic.
- Be able to draw a pipeline from memory and say where it can fail.
- Practise one scenario that crosses all the topics, then say what you check first.
Sources
- DORA's software delivery performance metrics — DORA (Google Cloud), 5 Jan 2026
- What is DevOps? — Amazon Web Services (date = read date; page undated), 24 Oct 2026
- Introduction (Site Reliability Engineering, chapter 1) — Google (O'Reilly Media), 1 Jan 2017
- CALMS framework — Atlassian (date = read date; page undated), 24 Oct 2026
- How SRE Relates to DevOps (The Site Reliability Workbook) — Google (O'Reilly Media), 1 Jan 2018
- Effective Troubleshooting (Site Reliability Engineering) — Google (O'Reilly Media), 1 Jan 2017
- Monitoring Distributed Systems (Site Reliability Engineering) — Google (O'Reilly Media), 1 Jan 2017
- Deployments (Kubernetes documentation) — The Kubernetes Authors, 7 Jul 2026
