Exercises and Case Studies
Table of contents
- Validation quiz
- Exercise 1: Situation analysis
- Exercise 2: Pipeline design
- Case study 1: Growing startup
- Case study 2: Traditional company
- Final project
1 - Validation quiz
Test your knowledge of DevOps concepts.
Questions
Q1. What does the acronym CALMS stand for in the DevOps context?
See the answer
Culture, Automation, Lean, Measurement, Sharing
The 5 pillars of DevOps according to the CALMS model.
Q2. What is the main difference between Continuous Delivery and Continuous Deployment?
See the answer
Continuous Delivery: The code is ready to be deployed at any time, but requires manual approval.
Continuous Deployment: The code is deployed automatically to production after passing all tests.
Q3. What are the 4 DORA metrics?
See the answer
- Deployment Frequency: Deployment frequency
- Lead Time for Changes: Time between commit and production
- Mean Time to Recovery (MTTR): Recovery time after an incident
- Change Failure Rate: Percentage of deployments causing incidents
Q4. What is "Shift Left" in DevOps?
See the answer
Shift Left consists of moving testing, security, and quality activities earlier in the development cycle (toward the left of the timeline).
Goal: detect problems as early as possible, when they are cheaper to fix.
Q5. Name 3 benefits of Infrastructure as Code (IaC).
See the answer
- Versioning: Infrastructure is versioned like code
- Reproducibility: Identical environments on every deployment
- Automation: Automatic provisioning, no manual errors
- Documentation: The code serves as documentation
- Auditability: Traceability of changes
🔝 Back to table of contents
2 - Exercise 1: Situation analysis
Context
You are a DevOps consultant called in by a company of 50 developers. Here is their current situation:
- Deployments: once a month, on the weekend
- Deployment time: 4-6 hours manually
- Post-deployment incidents: 40% of releases
- Tests: Manual, carried out by a separate QA team
- Infrastructure: Physical servers, manually configured
- Monitoring: Logs consulted manually when a problem occurs
- Communication: Emails and tickets between teams
Questions
1. Identify the 5 main problems of this organization.
2. For each problem, propose a DevOps solution.
3. Define an order of priority for the improvements.
4. Estimate the time needed for a complete transformation.
See the proposed solution
1. Identified problems:
- Rare and risky deployments
- Manual and slow process
- High failure rate (40%)
- Non-automated tests
- Non-reproducible infrastructure
- Reactive monitoring
- Organizational silos
2. Solutions:
| Problem | Solution |
|---|---|
| Rare deployments | CI/CD, frequent deployments |
| Manual process | Pipeline automation |
| Failure rate | Automated tests, progressive deployments |
| Manual tests | Test automation, shift left |
| Manual infra | Infrastructure as Code |
| Reactive monitoring | Proactive observability |
| Silos | Cross-functional teams |
3. Priorities:
- Version control and basic CI (quick win)
- Automated tests
- IaC and reproducible environments
- CD and automated deployments
- Monitoring and observability
- Reorganization of teams
4. Timeline:
- Quick wins: 1-3 months
- Complete transformation: 18-24 months
🔝 Back to table of contents
3 - Exercise 2: Pipeline design
Goal
Design a CI/CD pipeline for a web application (React frontend + Node.js backend + PostgreSQL database).
Constraints
- Hosting on AWS
- Unit, integration, and E2E tests required
- Environments: Dev, Staging, Production
- Manual approval for production
- Automatic rollback on failure
Task
1. Draw the complete pipeline (use a diagram).
2. List the tools chosen for each step.
3. Write a basic pipeline file (GitHub Actions or GitLab CI).
See the proposed solution
1. Pipeline diagram:
2. Tools:
| Step | Tool |
|---|---|
| CI/CD | GitHub Actions |
| Build | npm, webpack |
| Unit tests | Jest |
| E2E tests | Cypress |
| Deploy | AWS CDK / Terraform |
| Registry | Amazon ECR |
| Hosting | ECS Fargate |
| Monitoring | CloudWatch |
3. GitHub Actions pipeline:
name: CI/CD Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm run lint
- run: npm run build
- uses: actions/upload-artifact@v4
with:
name: build
path: dist/
test:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
- run: npm run test:e2e
deploy-staging:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: staging
steps:
- uses: actions/checkout@v4
- name: Deploy to Staging
run: ./deploy.sh staging
deploy-production:
needs: deploy-staging
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- name: Deploy to Production
run: ./deploy.sh production
🔝 Back to table of contents
4 - Case study 1: Growing startup
Context
TechStartup is a startup of 15 people (10 devs) that has developed a mobile application. They went from 1,000 to 100,000 users in 6 months.
Current situation
- Monolithic application on a dedicated server
- Manual deployments via SSH
- No automated tests
- Frequent downtime during usage spikes
- 2 developers spend 50% of their time on "ops"
Problems
- The application does not scale
- Deployments are risky
- Development time lost on ops
Questions
1. Propose a target architecture to support growth.
2. Define a migration plan in 3 phases.
3. Estimate the required resources (human and financial).
See the proposed solution
1. Target architecture:
2. Migration plan:
Phase 1 (Months 1-2): Foundations
- Containerize the application (Docker)
- Set up basic CI/CD
- Add automated tests
- Migrate to RDS
Phase 2 (Months 3-4): Scalability
- Deploy on ECS Fargate
- Configure auto-scaling
- Add CDN and cache
- IaC with Terraform
Phase 3 (Months 5-6): Optimization
- Complete monitoring
- Alerting
- Cost optimization
- Documentation
3. Resources:
| Resource | Estimate |
|---|---|
| DevOps Engineer (hire or consultant) | 1 FTE |
| Monthly AWS cost | €2-5K/month |
| Team training | €5-10K |
| Tools (monitoring, etc.) | €500-1K/month |
Expected ROI:
- 2 devs recover 50% of their time = 1 FTE
- Downtime reduction = better retention
- Ability to scale = business growth
🔝 Back to table of contents
5 - Case study 2: Traditional company
Context
TraditionalBank is a regional bank with 500 IT employees. Their core banking system is 20 years old.
Current situation
- Quarterly releases after CAB validation
- 2-month change freeze per year
- Dev team (100 people) vs Ops (50 people) vs Security (30 people)
- Major incidents: 2-3 per quarter
- Average MTTR: 4 hours
- Strict regulatory compliance (PCI-DSS, GDPR)
Specific challenges
- Regulatory: every change must be auditable
- Legacy: monolithic COBOL + Java system
- Culture: strong silos, resistance to change
- Risk: "if it works, don't touch it"
Questions
1. How can DevOps be adapted to this regulated context?
2. Propose a 3-year transformation strategy.
3. How to manage resistance to change?
See the proposed solution
1. DevOps in a regulated context:
DevOps is not incompatible with compliance. On the contrary:
| Requirement | DevOps solution |
|---|---|
| Auditability | Git history, pipeline logs, IaC |
| Traceability | Everything is versioned and tracked |
| Separation of duties | Approvals in the pipeline |
| Compliance tests | Automated in the CI |
| Documentation | Documentation as Code |
2. 3-year strategy:
Year 1: Foundations
- Train 20 DevOps ambassadors
- Pilot project: 1 non-critical application
- Set up basic CI
- Start test automation
Year 2: Expansion
- Extend to 5-10 applications
- IaC for new projects
- Automated CD to staging
- Reorganization into feature teams
Year 3: Maturity
- 50% of applications in CI/CD
- Weekly deployments
- Proactive monitoring
- Established DevOps culture
3. Change management:
| Action | Goal |
|---|---|
| C-level sponsorship | Legitimacy |
| Communication | Explain the "why" |
| Quick wins | Demonstrate value |
| Training | Build skills |
| Ambassadors | Relays within the teams |
| Celebrate successes | Motivation |
| Tolerate failure | Learning |
In a large organization, expect 3-5 years for a complete transformation. Patience is key.
🔝 Back to table of contents
6 - Final project
Goal
Create a complete DevOps environment for a simple application.
Deliverables
-
Git repository with:
- Application (simple API or website)
- Dockerfile
- docker-compose.yml
- CI/CD pipeline
- README documentation
-
Infrastructure:
- Terraform or Ansible for provisioning
- Test environment
-
Monitoring:
- Basic Grafana dashboard
- Configured alerts
Evaluation criteria
| Criterion | Points |
|---|---|
| Versioned and documented code | 20 |
| Containerized application | 20 |
| Working CI/CD pipeline | 25 |
| IaC for the infrastructure | 20 |
| Basic monitoring | 15 |
| Total | 100 |
Tip
Start simple and iterate. A working basic project is worth more than an ambitious incomplete one.
🔝 Back to table of contents
Congratulations!
You have completed the Introduction to DevOps course.
Recommended next steps
- Complete the final project
- Continue with the specialized courses:
- Docker and containerization
- Kubernetes
- CI/CD with GitHub Actions
- Terraform and IaC
- Monitoring with Prometheus
Resources to continue
- DevOps Roadmap
- DevOpsDays community
- Certifications: AWS, CKA, Terraform