Lernpfad
Containerisierung und Virtualisierung mit Docker und Kubernetes
13 Std.
DevOps ist für die moderne Softwareentwicklung echt wichtig geworden. Da Unternehmen immer öfter und zuverlässiger neue Funktionen rausbringen, steigt die Nachfrage nach erfahrenen DevOps-Ingenieuren weiter an.
Also ja: Es gibt echt viele Jobchancen da draußen.
Aber um einen Job zu kriegen, reicht es nicht, nur die richtigen Tools zu kennen. Du musst zeigen, wie du denkst, zusammenarbeitest und echte Probleme löst.
Ich hab schon beide Seiten erlebt. Ich war ein Bewerber, der knifflige Fragen zu Kubernetes beantworten musste, und ich war bei Vorstellungsgesprächen dabei, in denen wir geschaut haben, wie jemand mit Fehlern in der Produktion umgeht. Und ich hab gelernt, dass DevOps-Vorstellungsgespräche zeigen, wie du mit Komplexität umgehst, wie du unter Druck kommunizierst und ob du wirklich verstehst, warum bestimmte Tools benutzt werden.
Dieser Leitfaden soll dir bei der Vorbereitung auf ein DevOps-Vorstellungsgespräch helfen und deckt alles ab, von den Grundlagen bis hin zum fortgeschrittenen Systemdesign, sowie technische Fragen und Verhaltensszenarien. Egal, ob du gerade erst anfängst oder dich weiterentwickeln willst, diese Fragen helfen dir dabei, deine Fähigkeiten zu verbessern, selbstbewusst zu sprechen und gut vorbereitet zu sein.
Grundlegende DevOps-Interviewfragen
Diese Fragen checken, wie gut du die wichtigsten DevOps-Prinzipien verstehst. Lerne nicht einfach nur Definitionen auswendig. Zeig, dass du verstehst, wie diese Ideen in der Praxis funktionieren.
1. Was ist DevOps und warum ist es wichtig?
DevOps ist eine Reihe von Praktiken, die Entwicklungs- und Betriebsteams zusammenbringt, um die Softwarebereitstellung zu optimieren.
Das Ziel? Schnellere Releases, bessere Qualität und engere Feedback-Schleifen.
In der Praxis heißt das, dass man den Konflikt zwischen dem Schreiben und dem Ausführen von Code verringert. Es geht nicht nur um Tools, sondern auch um Kultur, Automatisierung und Eigenverantwortung.
In meinem alten Job haben wir DevOps eingeführt, um die Bereitstellung unserer ML-Modelle zu beschleunigen. Das hat unsere Bereitstellungszeit echt verkürzt und gleichzeitig die Stabilität verbessert.
2. Was ist der Unterschied zwischen DevOps und der klassischen IT?
Bei der traditionellen IT sind die Aufgaben geteilt: Entwickler schreiben den Code, und die Betriebsteams kümmern sich um die Bereitstellung und Wartung.
DevOps bringt diese Rollen zusammen und setzt auf gemeinsame Verantwortung und Automatisierung.
Mit DevOps:
- Entwickler schreiben oft Bereitstellungsskripte.
- Die Ops-Teams werden früher in den Entwicklungszyklus eingebunden.
- Veröffentlichungen kommen ständig raus und nicht nur mal im Quartal.
Stell dir DevOps so vor, als würde man die Mauer zwischen zwei Abteilungen einreißen, die früher nur über Tickets miteinander kommuniziert haben.
3. Was sind die wichtigsten Prinzipien von DevOps?
Die wichtigsten Prinzipien von DevOps sind:
- Zusammenarbeit: Die Trennung zwischen Entwicklung, Betrieb, Qualitätssicherung und Sicherheit aufbrechen.
- Automatisierungs: Automatisiere das Testen, die Bereitstellung und die Überwachung.
- en zu kontinuierlicher Integration und Bereitstellung (CI/CD): Oft kleine, sichere Änderungen machen.
- Überwachungs- und Feedback-: Lerne ständig dazu und passe dich an, basierend auf deinen Erfahrungen.
Diese Prinzipien sind nicht optional, weil sie zeigen, ob ein Team in einer DevOps-Kultur arbeitet oder nur DevOps-Tools mit alten Gewohnheiten nutzt.
4. Nenn mal ein paar beliebte DevOps-Tools und wofür man sie benutzt.
Hier sind ein paar beliebte Tools, von denen du oft hören wirst:
- Git-: Versionskontrolle.
- Jenkins/Gitlab CI-: CI/CD-Pipelines.
- Docker-: Containerisierung.
- Kubernetes: Container-Orchestrierung.
- ArgoCD: GitOps.
- Terraform: Infrastruktur als Code (IaC).
- Prometheus + Grafana-: Überwachung und Visualisierung.
Schau dir die DevOps-Konzepte an, wenn du mehr über DevOps und beliebte Tools erfahren möchtest.
5. Was ist CI/CD?
CI/CD steht für Continuous Integration und Continuous Delivery (oder Deployment).
Das ist das A und O der DevOps-Automatisierung.
CI/CD steht für:
- CI: Entwickler packen den Code mehrmals am Tag in ein gemeinsames Repo. Jede Zusammenführung löst automatische Builds und Tests aus.
- CD: Sobald der Code die Tests bestanden hat, wird er automatisch in der Produktions- oder Staging-Umgebung eingesetzt.
CI/CD macht weniger Fehler und macht Releases langweilig, was echt gut ist.
Wir haben CI/CD ausgiebig genutzt, um unsere ML-Modelle und den Code zu testen, der unsere Modelle hinter einer API laufen lässt. Jeder Push zu einem Feature-Branch hat die Unit-Tests gestartet, während ein Merge zum Main-Branch den Build eines neuen Container-Images ausgelöst und das Modell an die Kubernetes-Namespaces unserer Kunden verschickt hat.
Wenn du wissen willst, wie CI/CD im ML eingesetzt wird, empfehle ich dir den Kurs „CI/CD für maschinelles Lernen” und unseren Leitfaden zu CI/CD im maschinellen Lernen.
6. Was bringt die Automatisierung bei DevOps?
Automatisierung macht weniger manuelle Arbeit nötig, sorgt für mehr Zuverlässigkeit und hilft Teams, ihre Abläufe zu erweitern.
Zu den Vorteilen gehören:
- Schnellere Feedback-Schleifen
- Weniger Fehler beim Einsatz
- Wiederholbare Umgebungen
- Weniger Drama mit „Auf meinem Rechner läuft es“
Als Faustregel gilt: Wenn du was zweimal machst, automatisier es.
7. Was ist Infrastructure as Code (IaC)?
IaC ist die Praxis, Infrastruktur (Server, Datenbanken, Netzwerke) mit Code zu verwalten.
Anstatt die Infrastruktur manuell in Cloud-Konsolen einzurichten, legst du sie in Dateien fest (z. B. Terraform, CloudFormation).
Damit hast du deine Einrichtung fertig:
- Reproduzierbar
- Versionskontrolliert (wenn du Git benutzt)
- Einfach zu prüfen
Mit IaC kannst du ganze Umgebungen in wenigen Minuten bereitstellen, statt tagelang manuell daran zu arbeiten.
8. Wie passen Git und Versionskontrolle zu DevOps?
Versionskontrolle ist nicht nur für Code wichtig, sondern für fast alles.
In DevOps:
- Du versiehst deinen Code, deine Infrastruktur und sogar deine Dokumentation mit Versionsnummern.
- Git macht Zusammenarbeit, Rollback und Rückverfolgbarkeit möglich.
- Tools wie GitHub Actions oder GitLab CI/CD lassen sich direkt in Git-Workflows einbinden und sorgen so für eine nahtlose Automatisierung.
Versionskontrolle ist das Herzstück jeder DevOps-Infrastruktur.
9. Was ist die Aufgabe von Überwachung und Protokollierung in DevOps?
Ohne Überwachung und Protokollierung kann das Debuggen echt nervig werden. Ohne ordentliche Überwachung und Protokollierung kannst du nicht einfach sagen, ob sich Änderungen positiv oder negativ auf deine Anwendungen auswirken. Oder das Finden und Beheben von Fehlern wäre ohne angemessene Überwachung und Protokollierung fast unmöglich.
Sie lösen:
- Überwachung zeigt dir , was gerade los ist (CPU-Auslastung, Antwortzeiten, Betriebszeit).
- Die Protokollierung informiert dich darüber, was passiert ist (Fehler, Stacktraces und unerwartetes Verhalten).
Zusammen machen sie es dir einfach, zu beobachten und dich zu verbessern.
Ich empfehle, nicht nur bei Ausfällen, sondern auch bei Anomalien eine Benachrichtigung einzurichten. So kannst du Probleme erkennen, bevor sie auftreten.
10. Was ist ein einfaches Beispiel für eine CI/CD-Pipeline?
Hier ist ein Beispiel für einen ziemlich üblichen CI/CD-Ablauf:
- Entwickler zieht Änderungen in den Zweig „
main“ rein. - Die Pipeline startet und führt Unit-Tests, Code-Linting und statische Analysen durch.
- Wenn die Tests klappen:
- Erstell ein Docker-Image.
- Schick das Bild an eine Registrierungsstelle.
- Über Kubernetes in die Staging-Umgebung stellen.
- Ein manueller Genehmigungsschritt lässt die Bereitstellung in der Produktion zu, wenn die Staging-Umgebung okay ist.
Das kann man mit GitLab CI/CD, Jenkins oder GitHub Actions machen.
DevOps-Interviewfragen für Fortgeschrittene
Diese Fragen checken deine technischen Fähigkeiten, vor allem im Umgang mit Containern, CI/CD-Workflows, Infrastruktur-Tools und Bereitstellungen. Sei darauf vorbereitet, deine Designentscheidungen zu begründen und unter Druck Probleme zu lösen.
11. Was ist eine Bereitstellungsstrategie? Kannst du mir ein paar nennen?
Eine Bereitstellungsstrategie beschreibt, wie neue Softwareversionen an die Leute verteilt werden. Die richtige Wahl hängt davon ab, wie komplex dein System ist, wie viel Risiko du eingehen kannst und ob du Sachen rückgängig machen kannst.
Zu den gängigen Strategien gehören:
- Blau-grüner Einsatz: Lass zwei Umgebungen laufen (blau = aktuell, grün = neu) und schalte den Datenverkehr um, wenn grün stabil läuft. Diese Strategie macht schnelle Rollbacks möglich.
- Canary-Release-: Führ die Änderungen nach und nach für eine kleine Gruppe von Nutzern ein. Diese Strategie ist super, um Probleme frühzeitig zu erkennen, ohne zu viele Nutzer zu verärgern.
- Rolling Update-: Ersetze die Instanzen nacheinander, ohne dass es zu Ausfallzeiten kommt.
- Strategie neu aufsetzen: Schließ die alte Version komplett und starte dann die neue. Das führt zu Ausfallzeiten, ist riskanter und wird nicht oft gemacht.
Ich empfehle, mindestens rollierende Updates zu nutzen. Wenn du bereit bist, mehr Zeit zu investieren und über ein solides DevOps-Toolset verfügst, empfehle ich dir, mit Blue-Green- oder Canary-Deployments noch einen Schritt weiter zu gehen.
Manchmal ist die Strategie des Neuanfangs aber auch eine gute Option. Wir hatten ML-Modelle, die größere GPUs brauchten, die aber eingeschränkt waren. Deshalb mussten wir das gerade laufende Modell stoppen, um die GPU freizumachen, und konnten dann die neue Version hochfahren.
12. Wie funktionieren Container und Orchestrierung in DevOps?
Container (z. B. Docker) packen Anwendungen mit ihren Abhängigkeiten zusammen, damit sie überall gleich laufen.
Orchestrierungstools (wie Kubernetes) kümmern sich um:
- Container auf Knoten planen
- Apps je nach Auslastung skalieren
- Selbstheilungsanwendungen (z. B. Neustart ausgefallener Pods)
- Vernetzung, Dienstermittlung und Lastenausgleich
Zusammen sorgen sie für Konsistenz, Portabilität und Automatisierung in DevOps-Workflows.
Ich nutze sie jeden Tag bei der Arbeit, und sie haben echt geholfen, wie wir arbeiten und wie wir Apps entwickeln und einsetzen.
Mehr über Kubernetes erfährst du in der Einführung in Kubernetes .
Wenn du dich näher mit der Kombination von Docker und Kubernetes beschäftigen willst, empfehle ich dir den Kurs „Containerisierung und Virtualisierung mit Docker und Kubernetes” .
13. Wie würdest du Blue-Green-Deployment machen?
Blau-Grün-Bereitstellung heißt, dass man zwei gleiche Produktionsumgebungen hat (blau = aktuell, grün = neu). Die neue Anwendung wird erst mal in der Green-Umgebung eingesetzt, wo sie getestet wird. Sobald du zufrieden bist, wird der Datenverkehr von der blauen Umgebung auf die grüne Umgebung umgeschaltet.
Hier ist ein allgemeiner Ansatz:
- Mach mal 'ne grüne Umgebung, die genau wie blue (prod).
- Die neue Version auf Green bereitstellen.
- Mach Tests und automatische Überprüfungen.
- Wenn alles gut läuft, schalte den Traffic vom Load Balancer auf die grüne Umgebung um.
- Halte Blau kurz für Rollback am Leben.
Mit diesem Ansatz kannst du innerhalb von Sekunden ein Rollback durchführen, da du den Load Balancer einfach so anpassen kannst, dass er den Datenverkehr wieder an die blaue Umgebung sendet.
14. Was ist ein Rolling Update im Vergleich zu einem Canary Release?
Ein rollierendes Update ersetzt App-Instanzen nacheinander, sodass es zu keinen Ausfallzeiten kommt. Diese Option ist für dich, wenn du dir bei deiner Veröffentlichung sicher bist und sie sofort für alle Nutzer verfügbar machen willst.
Bei einer Canary-Veröffentlichung wird deine neue Version nur für einen kleinen Teil der Nutzer (z. B. 5 %) freigegeben. Schau erst mal, ob alles gut läuft, bevor du die Einführung auf mehr Leute ausweitest. Du kannst es nach und nach ausbauen, bis du es dann für alle Nutzer einführst.
Mit Canary kannst du in der Produktion testen, ohne dass das viele deiner Nutzer stört.
15. Wie schützt man eine CI/CD-Pipeline?
Sicherheit wird oft übersehen, ist aber echt wichtig.
Einige bewährte Vorgehensweisen sind:
- Verwende Tools zur Verwaltung von Geheimnissen (z. B. Vault, AWS Secrets Manager).
- Builds in isolierten Läufern ausführen
- Überprüfe Eingaben, um Injektionsangriffe zu vermeiden.
- Benutze signierte Container und überprüfe die Herkunft der Images.
- Statische und dynamische Analyse-Tools einbauen (SAST/DAST)
Zögere nicht, eine Pipeline wegen Sicherheitsbedenken scheitern zu lassen.
16. Was ist der Unterschied zwischen Docker und einer virtuellen Maschine (VM)?
Diese Frage wird oft gestellt, um zu sehen, ob du das Grundkonzept von Containern verstehst.
|
Feature |
Docker |
Virtuelle Maschine |
|
Ressourcenverbrauch |
Leichtgewichtig (nutzt den Betriebssystem-Kernel) |
Schwer (vollständiges Betriebssystem pro VM) |
|
Startzeit |
Sekunden |
Protokoll |
|
Isolation |
Prozessebene |
OS-level |
|
Anwendungsfall |
Mikroservices, CI/CD-Pipelines |
Vollständige Systememulation, Isolierung |
Docker ist schnell, portabel und super für moderne App-Workflows. VMs sind immer noch nützlich für strenge Isolierung und ältere Systeme.
Wenn du dich besser auf Fragen zu Docker im Vorstellungsgespräch vorbereiten willst, empfehle ich dir, Die 26 wichtigsten Docker-Interviewfragen und -Antworten für 2026.
17. Wie hilft Kubernetes bei DevOps-Arbeitsabläufen?
Kubernetes macht die komplizierten Teile beim Betrieb von Containern in großem Maßstab automatisch:
- Automatische Skalierung basierend auf CPU/Speicher
- Rolling Updates und Rollbacks
- Dienstermittlung und Lastenausgleich
- Ressourcenquoten und Pod-Prioritäten
Bei DevOps ist Kubernetes das Rückgrat für CI/CD, Überwachung und eine selbstheilende Infrastruktur.
18. Was sind Helm-Charts und wozu braucht man sie?
Helm ist der Paketmanager für Kubernetes. Helm-Charts definieren, installieren und aktualisieren K8s-Anwendungen mithilfe von YAML-Vorlagen.
Zu ihren Funktionen gehören:
- Einfachere Bereitstellungen
- Unterstützung für Versionierung und Wiederverwendung
- Hilfe bei der Konsistenz der Umgebung (Entwicklung/Staging/Produktion)
Wenn du schon mal riesige Mengen an YAML-Dateien immer wieder manuell bearbeiten musstest, ist Helm genau das Richtige für dich.
Ich benutze es für alle unsere Services, die wir unseren Kunden anbieten, bei denen sie immer wieder denselben Satz von YAML mit unterschiedlichen Konfigurationen installieren.
19. Wie gehst du mit Geheimnissen in DevOps um?
Schreib niemals Geheimnisse fest in Code oder Konfigurationsdateien.
Bessere Alternativen:
- Mit Tools zum Verwalten von Geheimnissen (z. B. HashiCorp Vault, AWS Secrets Manager)
- Verwendung von versiegelten Geheimnissen oder verschlüsselten K8s-Geheimnissen
- Zugriff über RBAC einschränken
- Regelmäßiges Rotieren von Anmeldedaten
Manchmal stellen wir fest, dass Kunden sensible Infos in ihren Git-Repositorys speichern, was zu ernsthaften Sicherheitslücken führen kann.
20. Wie behebt man Probleme bei fehlgeschlagenen Builds?
Das ist ein wichtiger Teil der Arbeit eines DevOps-Ingenieurs, weil es immer Fehler und fehlgeschlagene Builds geben wird.
Ein systematischer Ansatz wäre:
- Schau mal in die Protokolle Ihrer Builds an.
- Versuch mal, den Fehler den Fehler lokal zu reproduzieren, indem du die gleichen Schritte wie im CI-Schritt ausführst.
- Schau mal, ob es irgendwelche Unterschiede in der Umgebung (z. B. fehlende Abhängigkeiten, Umgebungsvariablen, Dateipfade).
- Die letzten Änderungen die letzten Änderungen Schritt für Schritt rückgängig machen.
Das häufigste Problem in meiner Geschichte waren fehlende Umgebungsvariablen, die ich beim lokalen Erstellen und Testen hatte, aber nicht zu meiner CI-Konfiguration hinzugefügt hatte.
Fragen für Vorstellungsgespräche im Bereich Advanced DevOps
Diese Fragen drehen sich um Architektur, Skalierbarkeit, Sicherheit und Führung. Rechne damit, dass wir über Kompromisse, Designentscheidungen und deinen Ansatz für DevOps in großem Maßstab reden werden.
21. Was ist GitOps und wie unterscheidet es sich von DevOps?
GitOps ist ein Teil von DevOps, das Git als einzige Quelle für die Infrastruktur und die Bereitstellung von Anwendungen nutzt.
Bei GitOps werden alle Änderungen an der Anwendung oder Infrastruktur über Pull-Anfragen an Git-Repositorys gemacht.
Ein GitOps-Operator (z. B. ArgoCD, Flux) checkt Änderungen und synchronisiert sie mit dem Cluster, sodass immer eine Eins-zu-Eins-Beziehung zwischen dem Git-Repository und dem Cluster besteht.
GitOps bringt also Versionskontrolle, Überprüfbarkeit und Rollbacks in die Infrastruktur-Workflows.
22. Erkläre „Policy-as-Code” anhand von Beispielen.
Policy-as-Code heißt, dass Sicherheits-, Compliance- und Betriebsrichtlinien als ausführbarer Code geschrieben werden, der automatisch in allen Systemen umgesetzt wird.
Beispiele sind:
- Mit OPA (Open Policy Agent) Kubernetes-Bereitstellungen blockieren, die öffentliche Dienste freigeben
- Sorg dafür, dass alle Terraform-Ressourcen ihren Besitzer und ihre Umgebung kennzeichnen.
- Verhindern, dass CI/CD-Pipelines ohne Genehmigung in die Produktion gehen
Ich hab mal Gatekeeper (die K8s-Integration von OPA) benutzt, um nicht gescannte Container-Images zu blockieren, was unsere Sicherheit verbessert hat.
23. Wie würdest du ein skalierbares CI/CD-System aufbauen?
Ein skalierbares CI/CD-System zu entwerfen ist echt wichtig, und Fragen zum Design sind beliebt, weil der Interviewer so sehen kann, wie du denkst und wie du deine Argumente rüberbringst.
Ein paar wichtige Teile deines Designs:
- Entkoppelte Phasen (Entwicklung, Test, Bereitstellung) mit klaren Zuständigkeiten
- Parallelisierung für mehr Geschwindigkeit (z. B. Tests über mehrere Knoten laufen lassen)
- Dynamische Runner auf Kubernetes für Flexibilität
- Zwischenspeicherung Ebenen für Abhängigkeiten und Artefakte
- Geheimnisse & Zugriffsisolierung zwischen Projekten
Für die Skalierung solltest du Tools wie Tekton oder Gitlab CI mit Kubernetes-Runners in Betracht ziehen.
24. Wie gehst du bei der Reaktion auf Vorfälle vor?
Das ist echt wichtig, weil der Interviewer sehen will, wie du mit Kunden umgehst, die meistens sauer sind, weil irgendwas kaputt ist. Das Lösen von Problemen ist ein wichtiger Teil der täglichen Arbeit eines DevOps-Ingenieurs.
Die wichtigsten Grundsätze sind:
- Bleib ruhig
- Schnell diagnostizieren (Netzwerkproblem? App-Ebene? Infra?)
- Kommuniziere klar und deutlich
- Alles dokumentieren
- Mach eine Nachbesprechung (finde die Ursache raus und lerne daraus)
Denk an eine wichtige Sache: Gib niemals anderen Leuten die Schuld.
Konzentrier dich lieber auf Systeme, Prozesse und Verbesserungen.
25. Wie schaffst du es, die Beobachtbarkeit über Microservices hinweg zu regeln?
Microservices sind echt wichtig in der heutigen DevOps-Welt. Deshalb solltest du auch grundlegende Fragen dazu beantworten können, weil das zeigt, dass du DevOps im Allgemeinen verstehst.
Für die Beobachtbarkeit brauchst du drei Sachen:
- Protokollierungs: Zentralisiert, strukturiert, durchsuchbar (z. B. ELK, Loki)
- Metriken-: Zeitreihen im Prometheus-Stil + Dashboards (z. B. Grafana)
- : Verteilte Tracing-Tools wie Jaeger oder OpenTelemetry
Verbinde alles mit Korrelations-IDs, um Anfragen über verschiedene Dienste hinweg zu verfolgen.
26. Wie würdest du langsame Pipelines verbessern?
Das passiert ziemlich oft, und es gibt ein paar typische Schritte, die du machen solltest:
- Zuerst messen: Nutze Pipeline-Metriken und Schritt-Timings, um deinen Arbeitsablauf zu optimieren.
- Cache smart: Abhängigkeiten, Docker-Layer, Testergebnisse.
- Split-Tests: Testsuiten nach Typ oder Modul parallelisieren.
- Verwende Pre-Commit-Hooks: Fang Fehler frühzeitig ab.
- Überspringe unnötige Schritte: Verwende bedingte Logik (z. B. Docker nur erstellen, wenn sich der Code an der entsprechenden Stelle geändert hat).
Manchmal reicht es nicht, einfach nur schnellere Hardware zu nehmen, um das Problem zu lösen, sondern man muss die Pipelines effizienter machen.
27. Wie gehst du mit Compliance in DevOps-Workflows um?
Compliance sollte von Anfang an proaktiv in den Softwareentwicklungszyklus eingebaut werden.
Schritte, die du machen musst:
- Alles mit Versionskontrolle verwalten (Code, Infrastruktur, Richtlinien)
- Audit-Trails über Git, CI/CD-Protokolle und Überwachungstools
- Automatische Compliance-Prüfungen (z. B. CIS-Benchmarks, Sicherheitsscanner)
- Zugriffskontrolle über RBAC und Prinzip der geringsten Privilegien
- Geheimnisverwaltung mit Rotationsrichtlinien
28. Kannst du Service Meshes im Zusammenhang mit DevOps erklären?
Ein Service Mesh (z. B. Istio, Linkerd) regelt die Kommunikation zwischen Services mit Funktionen wie:
- Verkehrssteuerung (z. B. Wiederholungsversuche, Zeitüberschreitungen, Weiterleitung)
- Sicherheit (mTLS zwischen Diensten)
- Beobachtbarkeit (Telemetrie pro Dienst)
Anstatt diese Logik in jede App einzubauen, kümmert sich das Mesh über Sidecar-Proxys darum.
29. Wie planst du Bereitstellungen ohne Ausfallzeiten?
Zero-Downtime-Bereitstellungen sind echt wichtig, weil du damit Änderungen machen kannst, ohne dass die Benutzererfahrung darunter leidet.
Strategien für eine Bereitstellung ohne Ausfallzeiten umfassen:
- Blau-grün oder canary Einsätze, um den Verkehr sicher umzuleiten
- Datenbankmigrationen mit Abwärtskompatibilität
- Lastenausgleich Zustandsprüfungen vor dem Hinzufügen neuer Instanzen
- Anständige Abschaltungen damit laufende Anfragen fertig werden
30. Was ist Chaos Engineering und hast du es schon mal benutzt?
Chaos Engineering bedeutet, absichtlich Fehler in deine Systeme einzubauen, um ihre Widerstandsfähigkeit zu testen.
Beispiel-Tools:
- Gremlin
- Chaos Monkey
- Litmus
Hier sind ein paar Szenarien, die wir simulieren, um zu sehen, wie stabil dein System ist:
- Das Töten von zufälligen Pods
- Netzwerkverzögerung simulieren
- DB-Verbindungen trennen
Chaos Engineering wird auch von Netflix oft genutzt.
Es hilft, verschiedene Szenarien durchzuspielen und zu sehen, wie dein System reagiert.
Verhaltens- und szenariobasierte DevOps-Interviewfragen
Diese Fragen checken, wie gut du in echten Situationen effektiv reagieren kannst. Der Interviewer will sehen, wie du mit echten Situationen umgehst, und checken, ob du dir nur Konzepte gemerkt hast oder DevOps wirklich verstehst.
Mach dich auf Fragen gefasst, die deine Erfahrung, dein Urteilsvermögen und deine Fähigkeit, unter Druck zu arbeiten oder teamübergreifend zusammenzuarbeiten, auf den Prüfstand stellen.
31. Erzähl mir mal von einer Situation, in der du ein Problem bei der Bereitstellung gelöst hast.
Hier ist deine Chance, dich mit einem echten Problem auseinanderzusetzen.
Interviewer wollen:
- Die Lage in der Region „ “: Was ist kaputt gegangen?
- Die Auswirkungen von „ “: Wie schlimm war es?
- Dein Ansatz: Was hast du gemacht?
- Die Lektion „ “: Was würdest du beim nächsten Mal anders machen?
Ein Beispiel könnte sein:
Ich hatte mal so ein Problem, wo ein Deployment schiefging und dabei eine wichtige Konfigurationsdatei im Produktionsumfeld einfach so überschrieben wurde. Unsere App war eine Stunde lang nicht erreichbar, bis ich sie manuell auf eine ältere Version zurückgesetzt habe. Insgesamt wurden 30 Leute für eine Stunde gesperrt. Ich habe das Problem mit Git-Diffs herausgefunden, einen Validierungsschritt zu unserer CI hinzugefügt und eine Rollback-Unterstützung eingebaut. Das Problem ist nie wieder aufgetreten.
32. Beschreib mal einen Konflikt mit einem Entwickler. Wie hast du damit umgegangen?
Da DevOps an der Schnittstelle mehrerer Teams angesiedelt ist, kommt es zu Konflikten. Der Interviewer will hier sehen, ob du ein bisschen emotionale Intelligenz hast.
Formuliere es so:
- Der Grund für den Konflikt (z. B. überstürzte Veröffentlichung, unklare Eigentumsverhältnisse)
- Wie du das Gespräch angegangen bist (Einfühlungsvermögen + Daten)
- Die Lösung (z. B. aktualisierter Prozess, klarere Zuständigkeiten)
Sei einfach ehrlich und lass die Schuld nicht auf den Entwickler fallen. Sag immer, dass du versucht hast, auf eine gute Zusammenarbeit zu setzen.
Und denk immer daran: Entwickler und DevOps-Ingenieure haben oft unterschiedliche Prioritäten. Entwickler wollen Funktionen schnell bereitstellen, während du dich vielleicht mehr auf Sicherheit, Stabilität und langfristige Wartbarkeit konzentrierst. Diese Spannung ist ganz normal, und wenn du ihre Sichtweise verstehst, kannst du Konflikte besser lösen.
33. Wie schaffst du den Spagat zwischen Geschwindigkeit und Stabilität bei Release-Zyklen?
Das ist eine nie endende Herausforderung für DevOps.
Du kannst dich auf Folgendes konzentrieren:
- Feature-Flags-: Funktionen in der Produktion aktivieren oder deaktivieren.
- Strategie für den Einsatz von: Canary- oder Blue-Green-Bereitstellungen
- Agile Methoden: Nutze agile Methoden, um schnell voranzukommen.
- Überwachungs: Gute Beobachtbarkeit, damit du schnell reagieren kannst, wenn was kaputt geht.
- Kommunikations: Schaff eine offene Feedback-Kultur und lerne immer weiter aus Fehlern.
- Automatisierungs: Automatisiere so viel wie möglich, wo es Sinn macht, um schneller und stabilere Ergebnisse zu kriegen.
Du musst dich nicht zwischen Geschwindigkeit und Sicherheit entscheiden, denn du kannst dein DevOps-System so gestalten, dass beides verbessert wird.
34. Kannst du mir mal erklären, wie du nach einem Produktionsausfall vorgehst?
Systeme können manchmal abstürzen. Deshalb ist es echt wichtig, dass man sie so schnell wie möglich wieder normalisieren kann.
Also kannst du die folgenden Schritte machen, um deine Systeme wieder zum Laufen zu bringen:
- Bestätige und schließeein: Sag den Leuten Bescheid und rede schnell mit ihnen.
- Diagnose schnell: Schau dir die Protokolle, Metriken und Dashboards an, um das Problem zu finden.
- Behebe das Problem „ “: Mach ein Patch, roll deine Anwendung zurück oder konfiguriere sie neu, um sie wieder online zu bringen.
- Post-mortem: Schreib auf, wie lange es gedauert hat, das Problem zu finden und zu beheben, was die Ursache war und was du tun musst, damit so was in Zukunft nicht mehr passiert.
Wenn du noch nie einen Notruf geleitet hast, probier's mal aus. Das ist eine Fähigkeit, die man von erfahrenen Ingenieuren erwartet.
35. Kannst du mal erzählen, wie du mit Teams aus verschiedenen Bereichen zusammengearbeitet hast?
Als DevOps-Ingenieur arbeitest du mit vielen verschiedenen funktionsübergreifenden Teams zusammen. Eine gute Zusammenarbeit ist daher super wichtig, und die Interviewer werden deine Teamfähigkeit genau unter die Lupe nehmen.
Du könntest über Folgendes reden:
- Wie du die Lücken zwischen Entwicklung und Betrieb geschlossen hast
- Wie du Datenwissenschaftlern geholfen hast, CI/CD einzuführen
- Wie löst man ein Problem zwischen den Sicherheits- und Produktteams (die streiten sich echt oft, glaub mir)?
Wenn du schon mal Unterlagen oder interne Tools erstellt hast, um anderen zu helfen, effizienter zu arbeiten, erwähne das auch, denn das zeigt, dass du Initiative zeigst.
36. Hast du dich schon mal aus einer Aufgabe raus automatisiert?
Das hier ist mein Favorit.
Mal ehrlich: Eines der Hauptziele von DevOps ist es, sich wiederholende Arbeitsabläufe zu automatisieren. Aber wenn du alles automatisierst, was bleibt dann noch zu tun? Es ist nicht ungewöhnlich, dass DevOps-Ingenieure ihre Aufgaben durch Automatisierung erledigen.
Trotzdem geht's um die Automatisierung. Du willst zeigen, dass es Teil deines Denkprozesses ist. Handarbeit sollte wie ein Warnsignal sein, etwas, das man loswerden sollte, nicht einfach hinnehmen.
Beispiel:
Früher habe ich unsere Staging-Umgebung jeden Montag von Hand eingerichtet. Ich hab ein Skript geschrieben, um das mit einem einzigen Befehl zu erledigen, und es dann in eine GitHub-Aktion gepackt, damit das Team es jederzeit auslösen kann.
Das Ziel ist, zu zeigen, dass du wie ein DevOps-Ingenieur denkst: Reibungsverluste reduzieren, Engpässe beseitigen und den Leuten den Rücken freihalten, damit sie sich um komplexere Probleme kümmern können.
37. Wie bringst du junge Ingenieure mit DevOps-Praktiken vertraut?
Diese Frage checkt deine Fähigkeiten als Führungskraft und deine Teamarbeit.
Ein paar Ideen für die Einarbeitung von Nachwuchsingenieuren:
- Eine „Erste Schritte“-Dokumentationsseite mit allen wichtigen Infos und Links erstellen
- Paarprogrammierung oder gemeinsame Debugging-Sitzungen
- Runbooks und Workflows dokumentieren
- Sandbox-Umgebungen für sicheres Experimentieren erstellen
- Wir machen interne Workshops zu den Grundlagen von Docker/Kubernetes.
Der Unterschied zwischen einem guten und einem super Ingenieur liegt in den Lehrfähigkeiten.
38. Erzähl mal von einem DevOps-Projekt, auf das du stolz bist.
Jetzt kannst du über einen deiner kreativen Erfolge reden. Such dir was aus, wo du was Tolles gemacht hast und worüber du viel erzählen kannst.
Du kannst über Folgendes reden:
- Das Problem, das du gelöst hast
- Die Auswirkungen (z. B. schnellere Freigabe, kürzere MTTR)
- Die Tools und die Architektur, die du benutzt hast
- Was du gelernt hast
Ich war mal in einem Team, das eine kleine MLOps-Plattform entwickelt hat. Diese Plattform wurde als Helm-Chart eingeführt. Zuerst haben wir es mit einem Bash-Skript auf die verschiedenen Namespaces in Kubernetes aufgesetzt. Dabei mussten wir immer erst checken, ob das Helm-Chart erfolgreich manuell aktualisiert wurde, und eine Veröffentlichung hat fast einen Tag gedauert. Dann hab ich GitOps mit ArgoCD eingesetzt, um unser Plattform-Chart mit nur einem Klick auf alle Namespaces zu übertragen, was die Release-Zeit auf ein paar Minuten verkürzt hat.
39. Was würdest du an deiner aktuellen DevOps-Pipeline verbessern?
Diese Frage zeigt, dass du selbstkritisch und vorausschauend denkst.
Sag lieber nicht „nichts“. Stattdessen könntest du:
- Erwähne einen Engpass (z. B. langsame Testsuite)
- Ein Tooling-Upgrade, das du planst (z. B. der Wechsel von Jenkins zu Tekton)
- Eine Lücke in der Beobachtbarkeit, die du gerade schließt
- Oder auch eine kulturelle Änderung (z. B. bessere Dokumentation)
Du wirst nicht nur danach beurteilt, was du weißt, sondern auch danach, wie du denkst.
40. Erzähl mir mal von einer Situation, in der du ein neues Tool oder eine neue Methode eingeführt hast. Wie hast du die Zustimmung bekommen?
Als DevOps-Ingenieur optimierst du Arbeitsabläufe und automatisierst Aufgaben. Das heißt, du änderst den Status quo, was oft dazu führt, dass Leute zögern, weil sie keine Veränderung wollen.
Du musst zeigen, dass du mit solchen Situationen ruhig und professionell umgehen kannst.
Du kannst in deiner Antwort Folgendes erwähnen:
- Warum hast du dich für das Tool/die Methode eingesetzt?
- Wie hast du es dem Team vorgestellt?
- Wie bist du mit Widerstand umgegangen?
- Was ist dabei rausgekommen?
Zum Beispiel: Ich habe vorgeschlagen, Terraform einzusetzen, um die manuelle AWS-Bereitstellung zu ersetzen. Einige Teamkollegen waren skeptisch, also hab ich einen wiederholbaren Arbeitsablauf gezeigt, Dokumentation hinzugefügt und beim Onboarding geholfen.
Strategien zur Vorbereitung auf Vorstellungsgespräche
DevOps-Vorstellungsgespräche prüfen mehr als nur technisches Know-how. Sie checken, ob du Probleme lösen, zusammenarbeiten und unter Druck kritisch denken kannst.
Die nächsten Abschnitte zeigen dir praktische Möglichkeiten, wie du deine Fähigkeiten verbessern und dich von anderen abheben kannst.
Technische Vertiefungen
Nur ein oberflächliches Verständnis von Systemen zu haben, reicht auf mittlerer oder höherer Führungsebene nicht aus. Du musst verstehen, wie Systeme intern funktionieren.
Du solltest dich intensiv mit folgenden Themen beschäftigen:
- Kubernetes: Lerne, wie du Cluster einrichtest, skalierst und Probleme behebst. Konzentrier dich auf Netzwerke, persistente Volumes und Helm.
- Terraform: Lerne, wie man den Status verwaltet, mit Modulen arbeitet und Remote-Backends nutzt.
- CI/CD-Muster: Lerne, wie du Phasen entkoppelst, Builds zwischenspeicherst und Pipelines sicher machst.
Wenn du deine Fähigkeiten von Grund auf neu aufbauen möchtest, fang mit DataCamps Einführung in Kubernetes und DevOps-Konzepte.
Ich empfehle auch immer, praktische Projekte zu machen, weil man dabei am meisten lernt. Du könntest eine App entwickeln, sie containerisieren und dann mit Terraform und Kubernetes über automatisierte Pipelines bereitstellen.
Empfehlungen zu Ressourcen
Du musst dich nicht aufs Selbststudium verlassen. Es gibt viele Online-Ressourcen, die dir beim Lernen helfen können.
Ein paar gute Quellen sind:
- Probeinterviews: Probier mal Dienste wie Pramp, Interviewing.iooder mach Peer-Interviews mit Freunden oder Kollegen.
- Bücher:
- Das Phoenix-Projekt (über Kultur und wie DevOps einem Unternehmen geholfen hat, besser zu werden)
- Site Reliability Engineering von Google (für mehr Details)
- Terraform Up & Running von Yevgeniy Brikman (für IaC-Kenntnisse)
- Spickzettel: Druck deine Kubernetes-CLI-Referenzen, Git-Workflows oder Linux-Befehle aus, die du jeden Tag benutzt.
- Gemeinden:
- DevOps-Discord-Gruppen
- r/devops auf Reddit
- Dev.to-, Medium- und DataCamp-Blogs
- Kurse:
- DevOps-Konzepte: Die Basis für Lieferpipelines und die Zuverlässigkeit des Systems.
- Containerisierung und Virtualisierung mit Docker und Kubernetes: Wichtig für Fragen zum Einsatz
- CI/CD für maschinelles Lernen und Vollautomatisiertes MLOps: Wenn du in einer hybriden ML+DevOps-Rolle bist.
- Weitere Artikel zur Vorbereitung auf Vorstellungsgespräche:
- Manchmal ist es sinnvoll, sich auch andere Artikel zur Vorbereitung auf Vorstellungsgespräche in verwandten Bereichen genauer anzuschauen. Beispiele sind:
- 31 Top-Fragen für Vorstellungsgespräche zu Azure DevOps für alle Niveaus
- Die 24 wichtigsten Fragen im Vorstellungsgespräch für AWS DevOps
- Die 34 wichtigsten Fragen und Antworten für Vorstellungsgespräche für Cloud-Ingenieure im Jahr 2026
- Die 30 wichtigsten Fragen und Antworten zum Thema Cloud Computing (2026)
- Die 30 wichtigsten MLOps-Interviewfragen und Antworten für 2026
Wenn du auffallen willst, musst du mehr machen, als dir nur Sachen zu merken. Mach was, mach es absichtlich kaputt und mach es dann besser.
Vorbereitung auf Fragen, die auf realen Szenarien basieren
Hier stolpern die meisten Leute. Es ist eine Sache, zu erklären, was CI/CD ist. Es ist was anderes, ruhig über einen Produktionsausfall um 2 Uhr morgens zu reden, den du gemeistert hast (oder meistern würdest).
So machst du's:
- Schau dir alte Vorfälle noch mal an: Was ist schiefgelaufen? Was hat das Problem gelöst? Was würdest du jetzt ändern?
- Machst du Nachbesprechungen?: Auch für deine eigenen Projekte. Übe, eins im STAR-Format zu schreiben.
- Denk wie ein Stakeholder: Wenn du einem Produktverantwortlichen eine fehlgeschlagene Veröffentlichung erklären müsstest, wie würdest du das klar und ohne Schuldzuweisungen machen?
- Übe das Abwägen von Vor- und Nachteilen: Blau-grün oder kanariengelb? Terraform oder Pulumi? Jenkins oder GitHub Actions? Was sind die Vor- und Nachteile?
Die beste Vorbereitung ist Erfahrung, aber simulierte Szenarien kommen dem schon ziemlich nahe. Denk mal über deine Geschichten nach, und wenn du nicht viele hast, schau dir doch mal Open-Source-Projekte, Fallstudien oder deine Labore an.
Fazit
DevOps ist mehr als nur ein cooler Jobtitel. Es ist eine Frage der Einstellung.
Es geht nicht darum, Befehle auswendig zu lernen oder Tools in deinem Lebenslauf aufzulisten. Es geht darum, zu zeigen, wie du denkst, wie du zusammenarbeitest und wie du Systeme aufbaust, die nicht zusammenbrechen, wenn es ernst wird.
In diesem Leitfaden haben wir grundlegende Fragen bis hin zu fortgeschrittenen Architekturthemen behandelt, von toolspezifischem Wissen bis hin zu Verhaltenskenntnissen. Wenn du es bis hierher geschafft hast, bist du schon einen Schritt voraus, weil die meisten Bewerber sich nicht so gut vorbereiten.
Aber hör hier nicht auf:
- Bau was.
- Mach was kaputt.
- Schreib darüber.
- Teile es mit anderen.
- Überleg dir, was schiefgelaufen ist – und wie du es beim nächsten Mal besser machen kannst.
Bei DevOps geht's mehr ums Machen als nur um die Theorie. Denk also daran, wenn du im Vorstellungsgespräch bist. Erkläre immer deinen Gedankengang und konzentriere dich mehr auf deine eigenen Erfahrungen.
Wenn du nach praktischen Tutorials suchst, schau dir unbedingt unser Azure DevOps Tutorialan.
Ich wünsche dir viel Erfolg für deine Vorstellungsgespräche und hoffe, dass dir dieser Leitfaden weiterhilft.
Häufig gestellte Fragen zu DevOps-Vorstellungsgesprächen
Was sind die häufigsten Herausforderungen bei einem DevOps-Vorstellungsgespräch?
Kandidaten werden oft mit praktischen, realitätsnahen Fragen konfrontiert, vor allem zu Themen wie CI/CD-Fehlerbehebung, Kubernetes-Netzwerke oder Reaktion auf Vorfälle und Wiederherstellung. Theorie allein reicht nicht aus.
Wie kann ich mich gut auf Verhaltensfragen in einem DevOps-Vorstellungsgespräch vorbereiten?
Denk mal über vergangene Vorfälle, Konflikte oder wichtige Produkteinführungen nach, die deine Organisation beeinflusst haben. Benutz das STAR-Format (Situation, Aufgabe, Aktion, Ergebnis) und sei mal ganz ehrlich, denn die Leute, die dich interviewen, finden Selbstbewusstsein wichtiger als Perfektion.
Wie wichtig ist es, praktische Erfahrung mit Tools wie Docker und Kubernetes zu haben?
Crucial. Die meisten DevOps-Jobs brauchen echte Praxis-Kenntnisse, nicht nur das Wissen aus Zertifikaten. Du solltest in der Lage sein, Container und Cluster sicher zu erstellen, zu löschen und zu debuggen.
Welche fortgeschrittenen DevOps-Themen können meinen Lebenslauf hervorheben?
GitOps, Policy-as-Code, Skalierung von CI/CD auf Kubernetes, Observability und Sicherheitsautomatisierung.
Sollte ich Cloud-spezifische DevOps-Tools wie Azure DevOps oder AWS CodePipeline lernen?
Ja. Cloud-native Tools können deine Chancen in einem Vorstellungsgespräch echt beeinflussen. Wenn du dich mit der DevOps-Suite von mindestens einer Plattform auskennst, bist du flexibler und wettbewerbsfähiger.
Ich bin ein Cloud-Ingenieur mit fundierten Kenntnissen in den Bereichen Elektrotechnik, maschinelles Lernen und Programmierung. Meine Karriere begann im Bereich Computer Vision mit dem Schwerpunkt Bildklassifizierung, bevor ich zu MLOps und DataOps wechselte. Ich bin spezialisiert auf den Aufbau von MLOps-Plattformen, die Unterstützung von Data Scientists und die Bereitstellung von Kubernetes-basierten Lösungen zur Optimierung von Machine Learning-Workflows.
