DevOps exercises interview prep has a strange problem: there is too much of it, and most of it is shallow. The open-source repository devops-exercises is the exception that hiring managers keep bookmarking, because it is not a list of trick questions. With more than 86,000 stars and over 20,000 forks on GitHub, it is a working question bank of 2,624 exercises and questions covering the whole DevOps and site reliability landscape, from Linux and Git to Kubernetes, Terraform and observability. This guide explains what it actually contains, how to use it for hiring and upskilling, and where its limits lie, so you can get value from it without trying to learn every topic it mentions.
It is aimed at two audiences who often talk past each other: engineers preparing for a DevOps or SRE role, and the teams interviewing them. Both groups benefit, but they should use the repository differently. Candidates need a study plan with a cut-off point. Hiring teams need a source of realistic, discussable questions, not a script to read aloud. Used either way, the repository works best as a map of the territory, not as a syllabus to complete.
What devops-exercises actually is
The repository, maintained under bregman-arie/devops-exercises, describes itself plainly: it contains questions and exercises on various technical topics, sometimes related to DevOps and SRE. That honesty matters. It is not a course, it does not promise a job, and its own README warns readers that most of the questions do not represent an actual interview. What it does offer is breadth with structure. Topics are organised into folders, so you can go straight to the area you need rather than scrolling through thousands of unrelated questions.
The headline numbers tell you why it keeps trending. At the time of writing it carries about 86,368 stars, 20,579 forks and 1,329 watchers, and it was updated as recently as 2 November 2026, which is a strong sign of a living project rather than an abandoned list. The repository description alone reads like a DevOps job specification: Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network and Virtualization. If your role touches even half of those, the bank is relevant. If it touches only one or two, the folder structure is what saves you from the noise.
What it can do: the topics that matter most
The strongest sections are the ones where DevOps work is actually judged in practice: operating systems, containers, orchestration, infrastructure as code, continuous integration and delivery, and observability. A candidate who can work through the Linux, Git, Docker, Kubernetes, Terraform, Ansible and CI/CD folders has covered the core of most DevOps roles. The cloud folders for AWS, Azure and GCP, plus databases, networking, DNS and security, then let you specialise for the stack a particular employer runs.
- Foundations: Linux, networking, DNS, shell scripting and Git. These questions expose gaps quickly, because they test understanding rather than recall of a tool name.
- Containers and orchestration: Docker and Kubernetes, including how workloads are scheduled, exposed, scaled and debugged when they fail.
- Infrastructure as code: Terraform and Ansible, where the useful questions are about state, idempotency, drift and change safety, not syntax trivia.
- Delivery and operations: CI/CD pipelines, Jenkins, CircleCI, Argo, observability with Prometheus and Grafana, and SRE topics such as reliability and incident handling.
- Adjacent depth: databases, security, soft skills and questions you can ask the interviewer, which are often the most neglected part of preparation.
How it works: setup in under a minute
There is no installation, no paid tier and no account to create. The whole bank is Markdown files in a public repository, which is part of its appeal: you can read it in a browser, clone it for offline study, or fork it and annotate your own answers. To get a local copy, run:
git clone https://github.com/bregman-arie/devops-exercises.git
From there, the workflow is deliberately simple. Pick one topic folder, work through its README, try to answer before you look, and write your answer down rather than nodding along. For exercises that ask you to build something, build it: spin up the container, write the pipeline, break it on purpose and fix it. Reading about Kubernetes without touching a cluster teaches you vocabulary. Debugging a failed pod teaches you the job.
One practical note for teams: the repository lists its licence as “Other” on GitHub, with no SPDX identifier, so do not assume a permissive open-source licence before copying large sections into your own commercial training material. Linking to it, and using individual questions as interview prompts, is a different matter from republishing the bank. When in doubt, link rather than copy, and check the repository for any licence clarification before reuse.
Why it is trending: hiring has a signal problem
DevOps hiring is notoriously hard to assess. Job titles vary wildly, tool stacks change every year, and a CV that lists Kubernetes says nothing about whether the person has ever paged at 3 a.m. for a production outage. A shared, public question bank gives both sides a common reference point. Candidates can see the breadth employers expect. Employers can see which questions are common knowledge and which actually discriminate between levels.
How to use DevOps exercises interview prep without drowning in 2,624 questions
The repository’s own warning is the most important sentence in it: it is not about learning all the topics and technologies mentioned here. Trying to do so is the fastest way to burn out and learn nothing deeply. Instead, treat the bank as a diagnostic tool with a short, honest plan.
- Start from the job description, not the table of contents. Highlight the five to seven topics the role actually uses, and ignore the rest for now. A role that is 80 percent Kubernetes and Terraform does not need a week on OpenStack.
- Score yourself before you study. Attempt ten questions per chosen topic cold, mark them honestly, and study only the gaps. This turns 2,624 questions into a focused list of perhaps fifty.
- Answer in full sentences, out loud. Interviewers judge reasoning and trade-offs, not just the final answer. Practise explaining why you would choose one approach, what breaks, and what you would monitor.
- Pair every theory question with one hands-on task. If you answer a question about Docker networking, reproduce the scenario locally. If you answer one about Terraform state, test a state lock and a drift fix.
- Keep a “still weak” list. Revisit it after a week. Topics that stay weak after two passes are the ones worth a dedicated tutorial or lab, not another round of the same questions.
For hiring managers, the same discipline applies in reverse. Pick a small set of questions per topic, agree in advance what a good answer sounds like at junior, mid-level and senior, and use follow-ups to test depth: “What would you do if that failed?” and “How would you know it had failed?” reveal far more than the first answer. Never use the bank as a pass-or-fail script. A candidate who reasons well through an unfamiliar question is usually a better hire than one who has memorised fifty familiar ones.
From our experience: where this bank helps, and where it does not
Over more than nine years building web, mobile and AI systems, we have seen the same pattern in technical hiring again and again: the engineers who do well in production are not the ones with the longest tool lists, but the ones who can explain a system, reason about failure, and change it safely. A question bank helps with the first part. It does not replace a work sample, a systems-design discussion, or a reference check, and any hiring process that leans on it alone will filter for memorisation.
The honest limitations are worth stating plainly. First, breadth is not depth: a folder of questions cannot teach you how a production incident actually feels, or how to negotiate a risky deploy with a product team. Second, answers age: cloud services, Kubernetes releases and tooling defaults move fast, so verify any answer that depends on a specific version or console behaviour before you rely on it. Third, the bank is community-maintained, so quality varies between folders; the popular core topics are generally stronger than the long tail. Use it as a starting point for discussion, then confirm the details against official documentation for the tools you actually run.
Where it genuinely shines is as a shared checklist for teams that are growing. A small team hiring its first DevOps engineer, or upskilling developers into platform work, can use the folders to agree on what “good” looks like, spot the gaps in their own runbooks, and build a training plan that is grounded in real operations rather than a vendor course outline. That is the practitioner use case, and it is where the repository earns its stars.
Getting started: a one-week plan
- Clone the repository and read the README warning in full, so you start with the right expectations.
- Choose your five to seven topics from the actual role or project you are targeting.
- Attempt ten questions per topic cold, and record your score honestly.
- Study the gaps with official documentation and one hands-on lab per topic.
- Re-attempt the questions you missed, this time answering out loud as if in an interview.
- For hiring teams, add two follow-up questions per topic that test failure modes and monitoring, not just definitions.
- Repeat the weak-topic pass after a week, and retire topics you can now explain confidently.
If you are building internal tooling, automation or an AI-assisted operations workflow around this kind of knowledge, our AI integration and automation team can help you turn scattered documentation into a system your team actually uses. You can also browse related tools in our AI Tools Directory, or talk to us about a hiring or upskilling plan for your team.
Frequently asked questions
Is devops-exercises enough to pass a DevOps interview?
No, on its own it is not. It is an excellent diagnostic and practice bank, but interviews also test hands-on skill, systems reasoning and communication. Pair it with labs, a work sample and mock interviews for the best result.
How many questions should I study?
Far fewer than 2,624. Pick the topics your target role uses, attempt a sample cold, and study only the gaps. A focused set of fifty well-understood questions beats five hundred skimmed ones.
Can hiring managers use it directly in interviews?
Yes, as a source of prompts, not as a script. Choose a small set, agree what good answers look like at each level, and use follow-up questions about failure modes and monitoring to test depth.
Is the repository still maintained?
Yes. It was updated in November 2026, carries more than 86,000 stars and 20,000 forks, and remains one of the most forked DevOps resources on GitHub. Always verify version-specific answers against official documentation.
What should I learn first if I am new to DevOps?
Start with Linux, Git and networking, then Docker, then Kubernetes and Terraform. That sequence mirrors how real systems are built: an operating system, version control, a network, a container, an orchestrator and infrastructure as code.
The bottom line
DevOps exercises interview prep works when it is used with restraint: a public, community-tested bank that maps a huge field, diagnoses gaps quickly, and gives candidates and hiring teams a shared language. It fails when it is treated as a syllabus to memorise. Pick your topics, practise out loud, build the things you claim to understand, and let the repository do what it does best: show you where to look next. If you would like help turning that kind of operational knowledge into hiring rubrics, training plans or automation for your team, get in touch with MTD Technologies and we will talk through what fits your stack.