DevOps in Practice and Module Review

Let us trace one complete scenario in full detail — this is exactly the kind of question that appears in the exam.

1. Alice fixes the bug and writes a test

   python — test and fix

   def 
   test_wrong_password_rejected
   ():
       result = 
   login
   ("alice"
   , "wrongpassword"
   )
       assert
    result == False
   

2. Commit and push

   bash

   git add .
   git commit -m "Fix login always returning True"
   git push origin fix/login-always-true
   

3. Pipeline triggers: GitHub detects the push. The workflow file in .github/workflows/ci.yml starts. A fresh Ubuntu VM is provisioned.
4. Checkout and setup: actions/checkout@v4 clones the repository. actions/setup-python@v5 installs Python 3.11.
5. Install: ./run.sh install runs pip install -r requirements.txt. The pip cache is used — this step takes 3 seconds instead of 30.
6. Lint: ./run.sh lint runs flake8. Alice's code is style-clean. The step exits 0.
7. Test: ./run.sh test runs pytest. All 15 tests pass, including Alice's new test. The step exits 0.
8. Docker build: docker build -t app:${{github.sha}} . builds the image. The pip install layer is cached (requirements.txt unchanged). Only the COPY layer is rebuilt.
9. Smoke test: docker run --rm -e APP_ENV=test app:${{github.sha}} python3 -c "import app" imports the application, confirming the container starts correctly.
10. Pipeline passes: All steps exited 0. GitHub marks Alice's commit with a green tick. The PR can now be reviewed.
11. Pull request review: Alice opens a PR. Bob reviews the code and approves it. The pipeline result appears as a green check on the PR.
12. Merge: Alice merges the PR. The fix is now in main. The pipeline runs again on main and passes.

The technology is half the story. Let us look at the cultural elements that make DevOps work — and fail.

What good looks like

• The team owns the whole delivery — Alice did not write a bug report and hand it to QA. She fixed it, tested it, and verified it herself.
• Small changes, tested frequently — the fix was one commit. The pipeline ran in under three minutes. The feedback was immediate.
• Automation replaced manual steps — nobody manually deployed. Nobody manually ran tests. Nobody manually built the image.
• Bob’s review was about logic, not style — flake8 caught style issues automatically. Bob spent his review time on the actual logic of the fix.

What failure looks like

• Large, infrequent merges — a team that merges once a week will have more conflicts, harder debugging, and slower feedback.
• CI bypass — if developers can merge without passing CI (or if CI is broken and ignored), the quality gate is meaningless.
• Fear of deploying — if the team is afraid to deploy because 'last time it broke something', the underlying problem is lack of automation and testing, not deployment itself.
• Blame culture — when something breaks in production, the team should ask 'how did this pass CI?' not 'who broke it?'. The answer is usually a gap in test coverage.

This module stopped before deployment. Here is a conceptual overview of what happens after the CI pipeline produces a verified image:

Once code is in production, you need to know if it is working. Observability is the ability to understand the internal state of a system from its external outputs. It has three pillars:

For this module, you should understand what observability means conceptually. You will build observability into production systems in Year 2 modules.

DevOps is a field, not a tool. Here is a map of the tooling you will encounter as you progress:

Over ten modules you have constructed a complete DevOps foundation. Here is the inventory:

• A Unix command-line toolkit: navigation, text processing, pipes, redirection
• Automation scripts with structured tasks, argument parsing, and error handling
• A Git repository with meaningful history, branches, and pull request workflow
• An automated test suite using pytest with fixtures and edge case coverage
• A CI pipeline in GitHub Actions with lint, test, and Docker build stages
• A Docker image with optimised layer caching and runtime configuration
• A smoke test verifying the container runs correctly in CI

This stack — Git + CI + Docker + Tests + Scripts — is the foundation of every production DevOps pipeline in the industry, from startups to large enterprises. The tools may differ; the pattern is universal.

The exam is two hours, invigilated, and covers all seven MLOs. It is worth 70% of the module mark. Here is a systematic revision strategy:

MLO-by-MLO revision

A complete glossary covering all ten modules:

• Arrive early — the exam starts promptly
• Read every question fully before writing anything
• For command questions: write exact syntax, flags included
• For explanation questions: two or three clear sentences are sufficient
• For scenario questions: identify the problem first, then describe the fix
• If stuck on a question, move on and return — do not lose time
• Check for marks — a 4-mark question expects four distinct points
• Re-read your answers if time allows