The Problem

Interview prep materials are usually static question lists. Tech Vault turns that into a hands-on lab: 40+ DevOps challenges that ask you to build, break, and fix real infrastructure, plus coding and DSA sections. The repo is a fork of moabukar/tech-vault (3,565 stars), so the content is community-tested.

What This Does

The devops-challenges/ directory is the core. Each q## folder is a self-contained scenario: q16 is a Flask app with a Dockerfile, q23 is a Terraform + OPA policy setup, q30 is an Ansible playbook for network config, q37 is a full-stack app with a Tiltfile and docker-compose. The misc/ folder has Python and Go utilities, including a random question picker (misc/py/randomiser.py).

How It Is Wired

There is no single entry point. Each challenge is independent, and the wiring is per-question. The import graph shows 8 internal modules with zero edges—no shared code, no cycles. That's by design: you're meant to treat each q## as a standalone exercise.

Trace q16 as an example: devops-challenges/code/q16/app.py is a Flask app. Its Dockerfile builds it, requirements.txt lists dependencies, and tests/test_app.py has unit tests. The app runs on port 5000 and serves a simple endpoint. q17 is a Lambda function (lambda/handler.py) with a serverless.yml and Terraform config, showing the same challenge in a serverless context.

The lack of shared modules means there's no blast radius across challenges—changing q16 cannot break q37. That keeps each exercise safe to experiment with, but it also means you can't reuse utilities or patterns across questions without copying them.

How To Use It

There's no root build system. Each challenge has its own instructions in its README.md.

Setup: Clone the repo, then pick a challenge. For q16:

git clone https://github.com/moses-y/tech-vault
cd tech-vault/devops-challenges/code/q16
docker build -t q16 .
docker run -p 5000:5000 q16

Configuration: Varies per challenge. q23 needs Terraform and OPA. q30 needs Ansible and an inventory. q37 needs Node for the frontend and Docker for the backend.

Running it: There's no unified runner. Each challenge is self-contained—read its README.md for the specific commands. The misc/ tools are standalone Python scripts you can run directly.

Real-World Use

This is a practical training ground. A junior DevOps engineer can work through q16 to learn containerization, q23 for policy-as-code, and q30 for configuration management. A team can use it for interview loops: give a candidate q32 (docker-compose) and ask them to fix a broken multi-service setup. The challenges mirror real production issues—a backup script in q39, a Chaos Monkey config in q27, a Helm chart in q34.

Code Health & Issues

Static analysis found 7 findings (0 critical, 3 high, 3 medium, 1 low):

  • High – No lockfile for the frontend (q37/frontend/src/package.json). Unpinned transitive dependencies mean the tested artifact may differ from production.
  • High – No CI workflow for the repo root. 13 source files with no automated build.
  • High – No build gate for the q16 Docker image. The deployable artifact has never been validated by CI.
  • Medium – No Dependabot/Renovate configured for the 4 manifests.
  • Medium – q16/Dockerfile uses python:3.8-slim, an unpinned base image.
  • Medium – q16/Dockerfile runs as root; no USER directive.
  • Low – Missing .editorconfig, .gitattributes, and formatter config.

The repo has tests (q16, q42), a license, and GitHub Actions in some subfolders (q30, q42), but no root-level CI.

The Bottom Line

Solid, practical content for DevOps interview prep and hands-on learning. The per-challenge isolation is a strength for experimentation but a weakness for consistency—no shared tooling, no root CI. Use it as a question bank and lab manual, not as a codebase to build on. The health issues are real but not blockers for a learning resource.