Aufgaben CI/CD
Die finale Lektion von K55: 10 IHK-typische Aufgaben zu CI/CD. Sie decken alle vorherigen Lektionen ab – von Grundkonzepten über GitHub Actions und Jenkins bis hin zu Terraform und Monitoring. Manche sind reine Wissensfragen, andere fordern dich auf YAML zu lesen oder zu schreiben, manche fragen nach Best Practices.
CI/CD-Themen kommen in IHK-Prüfungen besonders im FIAE-Bereich vor, aber auch FISI begegnen Pipeline-Fragen – schließlich gehört der Betrieb der Pipelines oft zu den Operations-Aufgaben. Versuch jede Aufgabe erst selbst, bevor du die Lösung aufklappst.
1) Cheat-Sheet zur Vorbereitung
Bevor wir in die Aufgaben gehen, hier die wichtigsten Begriffe aus dem Kurs als kompakte Übersicht. Falls einer davon noch unklar ist, geh in die entsprechende Lektion zurück:
CI/CD-Cheat-Sheet
Grundbegriffe
CI
Continuous Integration: Code mehrmals täglich integriert + getestet
CD
Continuous Delivery: jeder Build deploy-ready, manueller Push auf Prod
CDeployment
Continuous Deployment: automatischer Deploy auf Prod
Pipeline
Automatisierte Abfolge von Build-Test-Deploy-Stages
Pipeline-Konzepte
Stage
Phase wie Build, Test, Deploy – Stages laufen sequentiell
Job
Aufgabe innerhalb einer Stage – Jobs oft parallel
Step
Einzelner Befehl/Aktion in einem Job
Trigger
Event das Pipeline startet (push, PR, schedule, manuell)
Artifact
Build-Output (JAR, dist/) zwischen Stages
Cache
Persistente Dependencies für nächste Runs
Runner / Agent
Server der Jobs ausführt
Quality Gate
Schwellenwert der erfüllt sein muss
Tools
GitHub Actions
Marktführer, Workflows in
.github/workflows/GitLab CI/CD
Enterprise, eine zentrale
.gitlab-ci.ymlJenkins
Selbst-gehostet, Plugins, Jenkinsfile
Ansible
Configuration Management, Playbooks
Terraform
Infrastructure as Code mit HCL
Test-Pyramide & Metriken
Unit Tests
75-80%: schnell, isoliert
Integration Tests
15-20%: Module zusammen
E2E Tests
5%: System aus Nutzersicht
DORA Metrics
Deployment Freq, Lead Time, CFR, MTTR
Diese Übersicht ist ein guter Startpunkt für Klausur-Vorbereitung. Die Aufgaben unten setzen das Wissen voraus.
2) Aufgabe 1: Grundlegende Definitionen
Klassische Einstiegsfrage. So etwas wird oft als Kurzantwort oder Multiple-Choice abgefragt. Die Unterscheidung zwischen den drei Begriffen ist absolutes Pflichtwissen.
AUFGABE #1
EASY
Was bedeuten die Abkürzungen CI, CD und Continuous Deployment? Erkläre kurz den Unterschied zwischen Continuous Delivery und Continuous Deployment.
✓ Lösung
Begriffe:
- CI = Continuous Integration: Code-Änderungen werden mehrmals täglich automatisch in den Hauptbranch integriert. Build und Tests laufen automatisiert.
- CD = Continuous Delivery: erweitert CI – jeder erfolgreich gebaute Stand ist jederzeit deploybar. Deployment auf Production passiert aber manuell auf Knopfdruck.
- Continuous Deployment: geht noch weiter – jede Änderung die alle automatischen Tests besteht, wird automatisch ohne menschliches Eingreifen in Production deployed.
Mehr in L1 Was ist CI/CD?
3) Aufgabe 2: Pipeline-Stages
Eine typische Frage zur Pipeline-Architektur. Hier sollst du die Stages benennen können und ihre Reihenfolge verstehen. Achte besonders darauf warum die Reihenfolge wichtig ist.
AUFGABE #2
EASY
Nenne mindestens fünf typische Stages einer CI/CD-Pipeline in der richtigen Reihenfolge. Was passiert in jeder Stage?
✓ Lösung
Typische Stages in Reihenfolge:
- Checkout: Code aus Git-Repository holen
- Build: Quellcode kompilieren / bundlen / Dependencies installieren
- Test: automatisierte Tests laufen lassen (Unit, Integration, …)
- Quality / Code Analysis: Linting, Code-Coverage, Security-Scans (SonarQube)
- Package: Artefakt erstellen (Docker-Image, JAR) und in Registry pushen
- Deploy: Artefakt auf Zielserver/Cluster ausrollen
Mehr in L2 Pipeline-Aufbau.
4) Aufgabe 3: GitHub Actions YAML schreiben
Eine praktische Aufgabe – du sollst eine GitHub Actions-Konfiguration schreiben können. Das wird in FIAE-Klausuren häufig abgefragt, da es eine konkrete Fähigkeit testet.
AUFGABE #3
MEDIUM
Schreibe eine einfache GitHub Actions Workflow-Datei für ein Node.js-Projekt. Sie soll bei jedem Push auf den main-Branch und bei jedem Pull Request laufen, Node 20 einrichten, Dependencies installieren, Tests laufen und das Projekt bauen.
✓ Lösung
Workflow-Datei (Pfad: .github/workflows/ci.yml):
name: CI Pipeline
on:
push:
branches: [main]
pull_request:
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
cache: npm
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Build project
run: npm run build
Bewertungspunkte:
- Korrekter Pfad
.github/workflows/✓ - Trigger
pushaufbranches: [main]undpull_request✓ - Runner
ubuntu-latest✓ actions/checkout@v4als erster Step ✓setup-node@v4mit Version 20 und Cache ✓npm cifür reproduzierbare Installs (besser alsnpm install) ✓- Tests und Build als separate Steps ✓
5) Aufgabe 4: CI/CD-Tools vergleichen
Eine Wissensfrage die in Bewerbungsgesprächen oft kommt. Du sollst die drei großen CI/CD-Tools einschätzen können und wissen wann welches passt.
AUFGABE #4
MEDIUM
Vergleiche kurz die drei großen CI/CD-Plattformen: GitHub Actions, GitLab CI/CD und Jenkins. Nenne für jedes Tool typische Stärken und Einsatzszenarien.
✓ Lösung
GitHub Actions:
- SaaS, direkt in GitHub integriert
- Marketplace mit 20.000+ vorgefertigten Actions
- Kostenlos für Public Repositories
- Workflows in
.github/workflows/*.yml - Stärke: einfacher Einstieg, sehr beliebt bei Open Source und kleineren Teams
- Wann: GitHub-Nutzer, Cloud-First-Strategie
- In GitLab eingebaut, alles-in-einem (Repo + CI + Registry + Issues)
- Self-hostbar mit Community/Enterprise Edition
- Eine zentrale Datei
.gitlab-ci.yml - Built-in DAST/SAST/Security-Scans (Ultimate)
- Stärke: Enterprise-Features, Compliance, Self-Hosting
- Wann: Unternehmen mit Self-Hosting-Anforderungen
- Open Source, selbst-gehostet, älter (seit 2005)
- Über 1.800 Plugins für alles
- Master/Agent-Architektur
- Pipelines als
Jenkinsfilein Groovy (Declarative/Scripted) - Stärke: extreme Flexibilität, riesiges Ökosystem, frei
- Wann: Enterprise mit existierender Infra, spezielle Integrationen
6) Aufgabe 5: Test-Pyramide
Theorie-Aufgabe zu Test-Strategie. Wer das Konzept der Test-Pyramide nicht parat hat, bekommt's in Klausuren schwer. Klassisches Pflichtwissen für jeden Entwickler.
AUFGABE #5
MEDIUM
Was ist die Test-Pyramide? Welche drei Schichten gibt es und in welchem Verhältnis? Warum ist diese Struktur sinnvoll?
✓ Lösung
Test-Pyramide: Konzept von Mike Cohn zur sinnvollen Verteilung von Testarten in einer Software:
- Unit Tests (~75-80%): testen einzelne Funktionen/Klassen isoliert. Sehr schnell (Millisekunden), präzise, einfach zu schreiben.
- Integration Tests (~15-20%): testen mehrere Komponenten zusammen. Z.B. API + Datenbank. Langsamer (Sekunden).
- End-to-End Tests (~5%): testen das ganze System aus Nutzersicht (UI-Klicks). Langsam (Minuten), flaky, aber prüfen kompletten Stack.
- Schnelles Feedback: viele schnelle Unit-Tests laufen in Sekunden
- Präzises Lokalisieren: Unit-Test-Failures zeigen genau wo der Bug ist
- Geringere Kosten: Unit-Tests sind günstig zu schreiben und ausführen
- Stabilität: E2E-Tests sind oft flaky, sollten daher sparsam sein
7) Aufgabe 6: Trigger erkennen
Eine konkrete YAML-Lese-Aufgabe. Du sollst verstehen wann der Workflow läuft – das ist eine fundamentale Fähigkeit beim Lesen von Pipeline-Files. Achte besonders auf die Cron-Expression.
AUFGABE #6
MEDIUM
Du siehst folgende GitHub Actions Workflow-Konfiguration. Wann läuft der Workflow? Beschreibe alle Trigger-Bedingungen.
on:
push:
branches: [main, develop]
paths:
- 'src/**'
- '!**.md'
pull_request:
branches: [main]
schedule:
- cron: '0 2 * * *'
workflow_dispatch:
✓ Lösung
Der Workflow läuft bei vier verschiedenen Triggern:
- Push: bei jedem Push auf
mainoderdevelop, aber NUR wenn Dateien insrc/geändert wurden und KEINE.md-Dateien (das!ist Negation). Praktisch: Markdown-Änderungen lösen keinen Build aus. - Pull Request: bei jedem PR der gegen
mainerstellt oder aktualisiert wird - Schedule (cron): jeden Tag um 02:00 Uhr UTC – das ist die Cron-Expression
0 2 * * *. Typisch für nightly Builds oder Security-Scans. - workflow_dispatch: manueller Trigger über die GitHub-Web-UI – jemand kann den Workflow „auf Knopfdruck" starten
0 2 * * * bedeutet:
- Minute: 0
- Stunde: 2 (UTC!)
- Tag des Monats: * (jeden)
- Monat: * (jeden)
- Wochentag: * (jeden)
8) Aufgabe 7: Secrets-Handling
Sicherheits-Frage. In jedem Pipeline-Kontext kritisch. Wer Credentials falsch handhabt, gefährdet die ganze Firma. In Klausuren und Bewerbungsgesprächen wird das oft abgefragt.
AUFGABE #7
HARD
Welche Anti-Patterns gibt es beim Umgang mit Credentials (API-Keys, Passwörter) in CI/CD-Pipelines? Was sind die Best Practices? Skizziere ein korrektes Beispiel.
✓ Lösung
Anti-Patterns (Verbote):
- Hardcoded Credentials im YAML: Passwörter im Klartext in der Pipeline-Konfig. Wer das Repo klont, hat alle Keys.
- Credentials in Git committen: auch in
.env-Dateien oder Test-Files - Credentials in Logs ausgeben:
echo $API_KEYmacht's für jeden mit Pipeline-Lese-Rechten sichtbar - Geteilte Credentials für alle Umgebungen: ein Key für Dev, Staging, Prod = großes Risiko
- Lange Token-Lebensdauer: Tokens die nie ablaufen sind ein Risiko
- Secrets-Manager nutzen: GitHub Secrets, GitLab Variables, AWS Secrets Manager, HashiCorp Vault
- Pro Umgebung separate Credentials: dev/staging/prod jeweils eigene Keys
- Least Privilege: Token darf nur was nötig ist (z.B. nur Read-Access)
- Rotation: regelmäßig austauschen (alle 90 Tage)
- Audit-Logs: wer hat wann welches Secret genutzt
- Masking: CI-Tools maskieren Secrets in Logs automatisch (durch
***)
# Secret in Repo unter Settings → Secrets anlegen
- name: Deploy
env:
AWS_KEY: ${{ secrets.AWS_ACCESS_KEY }}
AWS_SEC: ${{ secrets.AWS_SECRET }}
run: aws deploy ...
Mehr in L3 und K11 Secure Coding.
9) Aufgabe 8: IaC und Idempotenz
Infrastructure as Code ist ein wichtiges Konzept. Idempotenz ist das Schlüsselprinzip dabei, das oft in Klausuren abgefragt wird. Hier wird beides kombiniert.
AUFGABE #8
HARD
Was bedeutet „Infrastructure as Code" (IaC)? Was ist Idempotenz und warum ist sie wichtig? Nenne typische IaC-Tools und ihre Unterschiede.
✓ Lösung
Infrastructure as Code: Infrastruktur (Server, Netzwerk, Datenbanken) wird durch Code-Dateien beschrieben und automatisch erzeugt, statt manuell über Konsolen geklickt zu werden. Vorteile:
- Reproduzierbarkeit: gleicher Code = gleiche Infra in jeder Umgebung
- Versionierbar: Git-History für jede Änderung
- Code-Review: Änderungen werden vor Umsetzung geprüft
- Disaster Recovery: bei Ausfall Infra in Minuten wieder aufgebaut
Warum wichtig: ohne Idempotenz würden Pipelines chaotisch laufen – jedes Mal wird neu installiert, Configs überschrieben, Services unnötig neu gestartet. Idempotenz garantiert stabile, vorhersehbare Operations.
Typische IaC-Tools:
- Terraform: deklarativ, cloud-agnostisch, multi-cloud (AWS, Azure, GCP, …), HCL-Syntax, mit State-File
- Ansible: prozedural, Configuration Management (nicht Provisioning), agentless via SSH, YAML, idempotente Module
- AWS CloudFormation: nur AWS, JSON/YAML, in AWS-Konsole integriert
- Pulumi: IaC in echten Programmiersprachen (Python, TypeScript, Go) statt eigener Syntax
10) Aufgabe 9: DORA-Metriken
Modernes Pflichtwissen. DORA wird in DevOps-Bewerbungsgesprächen mit hoher Wahrscheinlichkeit abgefragt. Die vier Metriken sind die Industrie-Standard-KPIs für DevOps-Performance.
AUFGABE #9
HARD
Was sind die vier DORA-Metriken? Erkläre jede kurz und nenne die Werte die ein „Elite Performer"-Team erreicht.
✓ Lösung
DORA-Metriken: vier KPIs aus dem „State of DevOps Report" von Google, die High-Performing-Teams identifizieren:
- Deployment Frequency
- Wie oft das Team auf Production deployed
- Elite: mehrmals täglich
- Low: seltener als einmal im halben Jahr
- Lead Time for Changes
- Wie lange vom Code-Commit bis Production
- Elite: weniger als eine Stunde
- Low: mehr als 6 Monate
- Change Failure Rate
- % Deploys die zu Production-Problemen führen (Hotfix nötig)
- Elite: 0-5%
- Low: über 30%
- Mean Time to Recovery (MTTR)
- Wie schnell ein Production-Incident behoben wird
- Elite: weniger als eine Stunde
- Low: mehr als 6 Monate
Mehr in L9 Monitoring.
11) Aufgabe 10: Praxis-Szenario
Die finale Aufgabe – ein realistisches Szenario das alle Aspekte abprüft. So etwas könnte als Hauptaufgabe in einer Abschlussklausur stehen. Hier zeigst du, dass du das große Ganze verstehst.
AUFGABE #10
HARD
Ein Team möchte für seine Java-Webanwendung eine CI/CD-Pipeline aufsetzen. Welche Stages würdest du einbauen, welche Tools würdest du wählen und warum? Skizziere den Workflow vom Code-Commit bis zum Production-Deploy. Welche Best Practices solltest du beachten?
✓ Lösung
Tool-Wahl (Beispiel):
- Git-Hosting: GitHub (oder GitLab)
- CI/CD: GitHub Actions (kostenlos für viele Use Cases) oder Jenkins (bei Self-Hosting-Bedarf)
- Build-Tool: Maven (klassisch) oder Gradle (modern) für Java
- Test-Framework: JUnit 5 + Mockito
- Code-Quality: SonarQube für statische Analyse
- Container-Registry: Docker Hub, GitHub Container Registry, oder selbst gehostet
- Deployment-Ziel: Kubernetes-Cluster (z.B. EKS) oder klassische Server
- IaC: Terraform für Cloud-Provisioning, Ansible für Server-Config
- Monitoring: Prometheus + Grafana
- Checkout: Code aus Git holen
- Build:
mvn clean compile– Java-Code kompilieren - Unit Tests:
mvn test– schnelle Unit-Tests - Code-Quality: SonarQube-Scan, Coverage prüfen (≥ 80%)
- Integration Tests: mit TestContainers (echte PostgreSQL im Docker)
- Package: Docker-Image bauen, taggen mit Git-SHA, in Registry pushen
- Deploy Staging: automatisch bei Push auf
main - Smoke Tests: ein paar wichtige Funktionen testen
- Deploy Production: manuell bei Git-Tag (Continuous Delivery, nicht Deployment)
- Secrets in GitHub Secrets/Vault – niemals im Code
- PR-Builds: jeder Pull Request muss grün sein bevor Merge
- Branch Protection: main-Branch nur via PR änderbar
- Code-Reviews: mindestens ein anderes Team-Mitglied muss freigeben
- Tests-First: keine Production-Deploys ohne grüne Tests
- Quality Gate: SonarQube-Threshold (z.B. min. 80% Coverage)
- Multi-Environment: dev → staging → prod
- Rollback-Strategie: alte Image-Version behalten für schnellen Rollback
- Caching: Maven-Cache für schnellere Builds
- Monitoring: Deploy-Events ans Monitoring-System schicken
- Notifications: Slack-Channel bei Build-Failures
12) Bonus: Begriffs-Tabelle
Zum Abschluss eine Übersicht aller wichtigen Begriffe mit Lektions-Verweis. Falls etwas fremd vorkommt, geh dort zurück:
| Begriff | Bedeutung | Lektion |
|---|---|---|
| CI / CD / CDeployment | Continuous Integration / Delivery / Deployment | L1 |
| Pipeline | Automatisierte Abfolge von Build-Test-Deploy | L2 |
| Stage / Job / Step | Drei Hierarchie-Ebenen einer Pipeline | L2 |
| Trigger | Event das Pipeline auslöst (push, PR, …) | L2 |
| Artifact / Cache | Build-Output / persistente Dependencies | L2 |
| Quality Gate | Schwellenwert (Coverage etc.) für Pipeline-Fortgang | L2 |
| Workflow (GH) | YAML-Datei in .github/workflows/ | L3 |
| Marketplace Action | Vorgefertigte Aktion in GitHub Actions | L3 |
| Matrix Build | Job parallel gegen mehrere Versionen | L3 |
| .gitlab-ci.yml | Zentrale Pipeline-Datei in GitLab | L4 |
| GitLab Runner | Server der GitLab-Jobs ausführt | L4 |
| Jenkinsfile | Pipeline-Definition für Jenkins in Groovy | L5 |
| Master/Agent | Jenkins-Architektur: Controller + Worker | L5 |
| Test-Pyramide | Unit/Integration/E2E im Verhältnis 75/20/5 | L6 |
| Code Coverage | % Code der durch Tests durchlaufen wird | L6 |
| Flaky Tests | Instabile Tests (mal grün, mal rot) | L6 |
| Ansible Playbook | YAML-Datei für Configuration Management | L7 |
| Inventory | Liste der von Ansible verwalteten Server | L7 |
| Idempotenz | Mehrfache Ausführung ändert nichts mehr | L7 |
| Infrastructure as Code | Infrastruktur als Code-Datei beschrieben | L8 |
| HCL | HashiCorp Configuration Language (Terraform-Syntax) | L8 |
| Terraform State | Datei mit Mapping Code ↔ Realität | L8 |
| plan / apply / destroy | Terraform-Workflow-Befehle | L8 |
| DORA Metrics | 4 KPIs für DevOps-Performance | L9 |
| MTTR | Mean Time to Recovery (DORA) | L9 |
13) Prüfungs-Tipps
Prüfungs-Checkliste CI/CD
- CI vs. CD vs. CDeployment: Unterschiede sicher beherrschen
- Typische Pipeline-Stages: Checkout → Build → Test → Quality → Package → Deploy
- Tool-Vergleich: GitHub Actions, GitLab CI, Jenkins – Stärken kennen
- YAML lesen können: Trigger, Steps, Conditions
- Einfache Pipeline schreiben: für Node, Java oder Python
- Test-Pyramide: Schichten, Verhältnis, Beispiel-Tools
- Secrets-Best-Practices: nie hardcoden, Secrets-Manager nutzen
- IaC + Idempotenz: Konzepte verstehen, Terraform vs. Ansible
- DORA-Metriken: vier KPIs kennen mit Elite-Werten
- Realistisches Szenario: Pipeline für komplette Webapp skizzieren können
14) Wie geht's weiter?
Mit K55 hast du das Fundament für moderne DevOps-Praktiken gelegt. Was du als nächstes vertiefen kannst:
- Software Deployment: K56 – Blue/Green Deployments, Canary Releases, Rollback-Strategien
- Docker und Container: K32 – Container sind Pflicht in modernen Pipelines
- Kubernetes: Container-Orchestrierung im großen Stil
- Cloud Computing: K31 – AWS, Azure, GCP verstehen
- DevOps-Grundlagen: K53 – die Kultur hinter den Tools
- Eigene Pipeline bauen: bestes Lernmittel ist Praxis. Nimm ein altes Projekt, gib ihm eine CI-Pipeline. Sei kreativ.
- Bücher: „Continuous Delivery" von Jez Humble & David Farley ist die Bibel des Themas
Zusammenfassung
10 IHK-typische CI/CD-Aufgaben durchgegangen: von EASY (Definitionen, Stages) bis HARD (Praxis-Szenario, DORA-Metriken, IaC). Wichtigste Lehren: CI vs. CD vs. CDeployment-Unterscheidung sitzen. Pipeline-Stages in richtiger Reihenfolge nennen können. Tools vergleichen: GitHub Actions (Marktführer, einfach), GitLab (Enterprise, Self-Hosting), Jenkins (Plugin-Riese, flexibel). YAML-Syntax lesen und schreiben können. Test-Pyramide (75/20/5%) verstehen. Secrets-Handling Best Practices. IaC und Idempotenz als Schlüsselkonzepte. DORA-Metriken als DevOps-KPIs. Realistische Pipeline für Webapp skizzieren können verbindet alles. Übung schlägt Theorie – eigene Pipeline bauen ist der beste Weg.