DevOps-Interviewfragen und Antworten (2026): CI/CD, Container und Vorfälle

DevOps-Interviews prüfen, ob du Software zuverlässig ausliefern kannst: wie Code vom Laptop in die Produktion gelangt, woran du erkennst, dass sie gesund läuft, und was du tust, wenn das nicht der Fall ist. Unten findest du 20 Fragen mit Antworten, von den Grundlagen bis zu den Szenario-Fragen, die die meisten Interviews entscheiden. Wo ein Befehl gezeigt wird, ist es ein Standardbefehl, den du in der Dokumentation des jeweiligen Tools nachschlagen kannst.

Grundlagen

1. Was ist DevOps?

Eine Arbeitsweise, die Entwicklung und Betrieb zusammenbringt, sodass Software durch denselben gemeinsamen Prozess gebaut, getestet, veröffentlicht und betrieben wird. Die Ziele sind schnellere, sicherere Releases und eine schnellere Wiederherstellung, wenn etwas kaputtgeht. Es ist eine Kultur und eine Sammlung von Praktiken, unterstützt durch Tools, nicht bloß ein Jobtitel.

2. Was ist der Unterschied zwischen Continuous Integration, Continuous Delivery und Continuous Deployment?

3. Was sind die wichtigsten Metriken für die Software-Auslieferung?

Vier sind weit verbreitet, aus dem DORA-Forschungsprogramm: Deployment-Frequenz, Durchlaufzeit für Änderungen, Änderungsfehlerrate und Wiederherstellungszeit. Die ersten beiden messen die Geschwindigkeit, die letzten beiden die Stabilität. Eine gute Antwort erklärt, dass du alle vier verfolgst, damit du nicht die Geschwindigkeit auf Kosten der Stabilität verbesserst.

4. Wie sieht eine gute CI-Pipeline aus?

1. Den Code auschecken und gecachte Abhängigkeiten wiederherstellen.
2. Bauen.
3. Zuerst schnelle Tests ausführen (Unit-Tests), dann langsamere.
4. Statische Prüfungen ausführen, etwa Linting und einen Schwachstellen-Scan der Abhängigkeiten.
5. Ein Artefakt (ein Container-Image oder Paket) einmal bauen und mit dem Commit taggen.
6. Es veröffentlichen und dasselbe Artefakt durch alle Umgebungen deployen.

Die Kernidee ist, einmal zu bauen und dasselbe Artefakt weiterzureichen, sodass das, was du getestet hast, auch das ist, was du auslieferst.

Versionskontrolle und Releases

5. Wie arbeitest du mit Branches und Releases?

Zwei gängige Ansätze. Trunk-based Development führt kleine Änderungen oft in den Hauptbranch zusammen, mit Feature Flags, um unfertige Arbeit zu verbergen. Branch-basierte Workflows wie GitFlow nutzen langlebige Branches für Releases. Trunk-based Development passt meist besser zu Continuous Delivery, weil die Merges klein und häufig sind.

6. Was sind Blue-Green- und Canary-Deployments?

Blue-Green kostet zusätzliche Kapazität. Canary braucht gute Metriken, weil du anhand der Daten entscheidest.

7. Was ist ein Feature Flag, und warum sollte man eines verwenden?

Ein Schalter in der Konfiguration, der ein Feature ohne Deployment ein- oder ausschaltet. Er trennt das Deployen von Code vom Veröffentlichen eines Features, lässt dich mit einer kleinen Gruppe testen und gibt dir einen schnellen Ausschalter, wenn etwas schiefgeht. Der Preis dafür ist, dass sich alte Flags anhäufen, also entferne sie, sobald ein Feature stabil ist.

8. Wie rollst du sicher zurück?

Halte das vorherige Artefakt verfügbar, mache Deployments wiederholbar und gestalte Datenbankänderungen abwärtskompatibel, damit die alte Version weiterhin mit dem neuen Schema funktioniert. Ein Rollback-Plan, der die Datenbank ignoriert, ist kein Plan. Bei riskanten Änderungen ziehe es vor, mit einem Fix vorwärtszurollen, wenn ein Rollback Daten verlieren würde.

Infrastruktur und Container

9. Was ist Infrastructure as Code?

Server, Netzwerke und Berechtigungen in versionierten Dateien definieren, statt in einer Konsole herumzuklicken. Das macht Umgebungen reproduzierbar, überprüfbar und leicht wiederherstellbar. Gängige Tools sind Terraform, Pulumi und die eigenen Templates der Cloud-Anbieter. Siehe unsere Terraform-Interviewfragen.

10. Was ist der Unterschied zwischen einem Container und einer virtuellen Maschine?

Eine virtuelle Maschine enthält ein vollständiges Gastbetriebssystem auf virtualisierter Hardware. Ein Container teilt sich den Kernel des Hosts und packt nur die Anwendung und ihre Abhängigkeiten ein, startet deshalb schneller und braucht weniger Speicher. Container bieten weniger Isolation als eine virtuelle Maschine.

11. Was gehört in ein gutes Dockerfile?

Ein kleines, spezifisches Basis-Image verwenden, die Layer so ordnen, dass die am seltensten geänderten zuerst kommen (um den Build-Cache zu nutzen), Abhängigkeitsdateien kopieren und installieren, bevor der Quellcode kopiert wird, als Nicht-Root-User ausführen und keine Secrets ins Image backen. Multi-Stage-Builds halten Build-Tools aus dem finalen Image heraus.

12. Warum Kubernetes?

Es verteilt Container über mehrere Maschinen, startet fehlgeschlagene neu, skaliert sie und übernimmt Rolling Updates und Service Discovery. Es bringt aber auch viel Komplexität mit, deshalb gehört in eine gute Antwort, wann man es nicht einsetzen würde, etwa bei einer kleinen App, die auf ein paar Servern läuft, oder bei einer Managed Platform. Siehe unsere Kubernetes-Interviewfragen.

13. Wie verwaltest du Secrets?

Niemals in die Versionsverwaltung oder ins Image damit. Nutze einen Secrets Manager oder den Secret Store der Plattform, gib jedem Service nur die minimal nötigen Rechte, rotiere Secrets und vermeide es, sie in Logs auszugeben. Erzähl, was du bei einem Leak tun würdest: widerrufen, rotieren und die Logs auf Nutzung prüfen.

Zuverlässigkeit und Betrieb

14. Was sind Monitoring, Logging und Tracing?

Alarmiere eher auf Symptome, die Nutzer spüren, etwa Fehler und langsame Antworten, als auf Ursachen wie hohe CPU auf einer Maschine.

15. Was sind SLIs, SLOs und SLAs?

Ein Service Level Indicator ist eine Messgröße, etwa der Anteil erfolgreicher Anfragen. Ein Service Level Objective ist das Ziel dafür, etwa 99,9 Prozent über 30 Tage. Ein Service Level Agreement ist ein Versprechen an Kunden, oft mit Konsequenzen bei Verfehlung. Die Lücke zwischen 100 Prozent und dem SLO ist ein Error Budget: der Spielraum, den du für Risiko und Veränderung hast.

16. Ein Produktionsservice ist langsam. Was machst du?

1. Prüfen, ob es echt ist und wer betroffen ist, anhand von Dashboards und Fehlerraten.
2. Prüfen, was sich kürzlich geändert hat: ein Deployment, eine Konfigurationsänderung, ein Traffic-Spike.
3. Eingrenzen: ein bestimmter Endpoint, eine Region oder eine Abhängigkeit.
4. Ressourcen anschauen (CPU, Speicher, Verbindungen) und die nachgelagerten Services.
5. Wenn eine kürzliche Änderung die wahrscheinliche Ursache ist, sie zuerst zurückrollen und danach untersuchen.
6. Status kommunizieren, während du arbeitest.

Interviewer hören auf ein ruhiges, geordnetes Vorgehen und darauf, dass du zuerst entschärfst, bevor du die Grundursache findest.

17. Was ist eine blameless Postmortem?

Eine schriftliche Nachbetrachtung nach einem Incident, die darauf schaut, wie System und Prozess den Fehler ermöglicht haben, nicht darauf, wer einen Fehler gemacht hat. Sie umfasst den zeitlichen Ablauf, die Auswirkungen, die Ursachen und konkrete Folgeaktionen mit Verantwortlichen. Der Sinn ist zu lernen und denselben Fehler schwerer wiederholbar zu machen.

18. Was ist der Unterschied zwischen horizontalem und vertikalem Skalieren?

Vertikales Skalieren gibt einer Maschine mehr Ressourcen. Horizontales Skalieren fügt mehr Maschinen hinzu. Vertikal ist einfach, hat aber eine Obergrenze und einen Single Point of Failure. Horizontal skaliert weiter und übersteht den Ausfall einer Maschine, braucht aber zustandslose Services oder geteilten State.

Praxis

19. Wie sicherst du eine Pipeline ab?

Begrenze, wer die Pipeline ändern und wer nach Produktion deployen darf. Scanne Abhängigkeiten und Images auf bekannte Schwachstellen, signiere und verifiziere Artefakte, halte Credentials kurzlebig und eng begrenzt und behandle Änderungen an Pipeline-Dateien wie Code. Ein Build-Agent mit weitreichenden Rechten ist ein beliebtes Ziel.

20. Erzähl von einem Deployment, das schiefging.

Das ist eine Verhaltensfrage in einem technischen Interview. Erzähl eine kurze Geschichte: was sich geändert hat, wie du es bemerkt hast, was du zuerst getan hast (meist entschärfen, oft per Rollback), was du herausgefunden hast und was du danach geändert hast, damit es sich nicht wiederholt. Auf eine blameless Formulierung und eine konkrete Folgeaktion kommt es den Interviewern an.

Wie man sich vorbereitet

1. Baue eine kleine Pipeline von Anfang bis Ende: ein Repository, einen Build, einen Testlauf, einen Container und ein Deployment auf etwas, das du erreichen kannst.
2. Sei bereit, einen Vorfall oder ein fehlgeschlagenes Release aus deiner eigenen Erfahrung zu erklären.
3. Übe die Antwort auf „Der Service ist langsam" laut, bis sie eine ruhige, geordnete Liste ist.
4. Kenne in jedem Bereich ein Tool gut, etwa CI, Container, Infrastructure as Code und Monitoring, statt einer langen Liste von Namen.

Für verwandte Übungen sieh dir unsere Leitfäden zu AWS-Interviewfragen, Terraform-Interviewfragen, Kubernetes-Interviewfragen und Interviewfragen zu Computernetzwerken an.

Übe laut und in deinen eigenen Worten. Ein Transkript im Anschluss zeigt dir, wo du abgeschweift bist oder den Punkt verfehlt hast. Befolge die Regeln des Arbeitgebers zu KI-Tools in jedem Live-Interview oder Assessment.