The 2,624 entries work better as prompts than lessons
DevOps Exercises opens with a claim of 2,624 exercises and questions across Linux, networking, cloud providers, containers, Kubernetes, CI/CD, databases, security, observability, and soft skills. That breadth makes it useful when you need to test recall across a job description. It also makes the repository a poor place to begin at page 1 and read straight through. The README itself says becoming a DevOps engineer does not mean learning every tool listed.
Many entries use expandable question-and-answer blocks, while others stop at the question. The FAQ explains that missing answers are partly a contributor shortage and partly an invitation to search documentation or ask a community. That can produce good practice for an experienced engineer. A beginner who cannot judge the sources may simply replace one unknown with an unchecked answer from a search result.
Interview practice comes with an explicit accuracy warning
The README says most of its questions and exercises do not represent an actual interview. That warning is unusually useful. A bank this large can help you rehearse subnetting, container behavior, failure diagnosis, or design tradeoffs, but no hiring team will sample all 2,624 prompts. The separate interview guide tells candidates to start with the job description, their resume, and the employer's process.
That makes the collection strongest as a gap detector. Pick a topic you claim to know, answer without opening the disclosure, and note where the explanation turns vague. Then check vendor documentation or reproduce the behavior. The FAQ favors practical work, reading, community participation, and sharing. Its own Flask challenge turns that advice into a small repair task instead of another definition to memorize.
What happened when we ran it
Our sandbox targeted topics/flask_container_ci/, not all 429 files in the repository. Installation succeeded in 6 seconds with 42 packages and 40 MB on disk. The measured build step then completed in 1 second. Pip-audit found 0 known vulnerabilities in that installed Python environment.
The test command failed after 2 seconds with exit code 5. Pytest reported 0 passed, 0 failed, and 0 collected, ending with no tests ran in 0.00s. That is a discovery result, not evidence that the Flask behavior is broken. The exercise README tells learners to run python tests.py, and the repository supplies a unittest file under that name. Our generic pytest step did not execute it.
The checkout at commit 9e49ef9 occupied 7 MB and contained about 1,015 lines classified as source by the lab. We found 1 CI workflow, no Dockerfile, and a tests directory signal. The lack of a Dockerfile matches the assignment, which asks the learner to create one and test it in CI. Treating that absence as a project defect would miss the point of the exercise.
The Flask task gives you requirements, not a finished reference
The challenge asks for a running Flask API with /users and /users/<username> routes, ordered usernames, and responses without internal user IDs. After repairing the app, the learner must containerize only what is needed at runtime, add an automated test for the Dockerfile, and contribute another application test. A notes.md file is suggested for explaining decisions.
This is closer to a take-home assignment than a tutorial. The repository does not walk through the repair or choose a CI provider for you. That freedom is useful if you already understand Python packaging, containers, and pipelines. Someone learning all 3 at once may spend more time guessing the expected environment than examining the tradeoffs. A finished solution branch or grading script is not presented in the challenge README.
Missing answers and restrictive reuse terms limit classroom use
The main FAQ is candid that many questions lack answers. It also says repeated questions may be intentional when they test the same idea from another angle. That creates useful spaced recall, but it complicates automated importing or deduplication. Instructors should curate a smaller set and verify each answer rather than treating the repository as a ready-made syllabus.
The license deserves the same attention. GitHub reports no recognized SPDX identifier, while the checked-in Creative Commons text requires attribution, bars use aimed at commercial advantage, and restricts adaptations. The FAQ reinforces that users may copy questions with credit only for noncommercial use. A company can study the material internally, but anyone packaging it into paid training should obtain legal advice or separate permission.
Default-branch work stopped in December while submissions continued
The last push to the default branch was December 27, 2025, and the repository has no GitHub release record. On September 26, 2026, GitHub showed 84,660 stars and 56 open issues and pull requests. Issue and pull-request activity continued into September, but the recent queue also contained off-topic titles and contributions that had not reached the default branch.
That combination is more precise than calling the project dead or healthy. The material remains widely used, and people still submit changes, yet the published branch had gone about 9 months without a push. Use the questions as prompts, verify claims against current product documentation, and keep your own notes. If you want a guided sequence, 90DaysOfDevOps or DevOps Roadmap is easier to follow. For a narrower knowledge check, Test Your Sysadmin Skills cuts the scope to Linux operations.