DevOps Engineer Vorstellungsgespräch: Fragen & Antworten (mit Musterantworten)

Musterantwort

DevOps ist für mich vor allem eine Kultur, die Entwicklung und Betrieb enger zusammenbringt und gemeinsame Verantwortung schafft. Automatisierung und Tools sind wichtige Mittel, aber kein Selbstzweck. Ziel ist, Software schneller, zuverlässiger und mit weniger Reibung auszuliefern. Feedbackschleifen und kontinuierliche Verbesserung stehen dabei im Zentrum.

Musterantwort

Ich automatisiere jeden Schritt vom Commit über Tests bis zum Deployment, damit nichts manuell und fehleranfällig bleibt. Die Pipeline soll bei Fehlern früh und deutlich abbrechen, statt Probleme weiterzureichen. Deployments gestalte ich risikoarm, etwa über Blue-Green- oder Canary-Strategien mit der Möglichkeit zum schnellen Rollback. Wichtig ist mir, dass die Pipeline schnell genug bleibt, damit Entwickler sie gerne nutzen.

Musterantwort

Meine erste Priorität ist die Wiederherstellung des Betriebs, etwa durch ein Rollback, bevor ich die Ursache im Detail suche. Ich kommuniziere klar und ruhig mit den Beteiligten über Status und nächste Schritte. Nach der Behebung führe ich eine schuldfreie Nachbesprechung durch, um die eigentliche Ursache zu verstehen. Daraus leite ich Maßnahmen ab, damit der Vorfall sich nicht wiederholt.

Musterantwort

Ich integriere Sicherheitschecks direkt in die Pipeline, etwa Scans von Abhängigkeiten und Container-Images. Zugriffsrechte vergebe ich nach dem Least-Privilege-Prinzip und verwalte Secrets in einem dedizierten Tool statt im Code. Infrastruktur beschreibe ich als Code, damit Änderungen nachvollziehbar und überprüfbar sind. Sicherheit ist für mich ein fester Teil des Prozesses, nicht ein nachgelagerter Schritt.

Musterantwort

Ich erfasse Metriken, Logs und Traces und definiere aussagekräftige Alerts auf Basis von Symptomen, die Nutzer betreffen, statt auf jeder kleinen Schwankung. Mit Dashboards machen ich den Zustand der Systeme für das Team sichtbar. Über Service Level Objectives lege ich fest, welche Zuverlässigkeit wir anstreben. So erkennen wir Probleme, bevor Nutzer sie bemerken.

Infrastructure as Code beschreibt Infrastruktur in versionierten Konfigurationsdateien statt in manuellen Klicks, etwa mit Terraform. Das macht Umgebungen reproduzierbar, nachvollziehbar und überprüfbar und reduziert Fehler durch manuelle Einrichtung.

Docker verpackt Anwendungen in Container, die überall gleich laufen. Kubernetes ist eine Orchestrierungsplattform, die viele Container über mehrere Maschinen hinweg verwaltet, skaliert und im Fehlerfall automatisch neu startet.

Beim Blue-Green-Deployment laufen zwei identische Umgebungen, von denen nur eine aktiv ist. Eine neue Version wird in der inaktiven Umgebung ausgerollt und getestet, dann wird der Verkehr umgeschaltet, was ein schnelles Rollback ermöglicht.

Metriken sind aggregierte Zahlenwerte über die Zeit, etwa CPU-Auslastung. Logs sind detaillierte Ereignisaufzeichnungen, und Traces verfolgen den Weg einer einzelnen Anfrage durch verteilte Dienste, was bei der Fehlersuche hilft.

Secrets gehören niemals in den Quellcode, sondern in einen dedizierten Secret Store wie HashiCorp Vault oder den Secret-Manager der Cloud. Sie werden zur Laufzeit injiziert, regelmäßig rotiert und mit minimalen Zugriffsrechten versehen.

Ein fehlerhaftes Deployment legte nachts einen zentralen Dienst lahm. Ich habe sofort ein Rollback durchgeführt, um den Betrieb wiederherzustellen, und parallel die Stakeholder informiert. Danach habe ich die Ursache analysiert und einen fehlenden Test in der Pipeline identifiziert. In der Nachbesprechung haben wir diesen Test ergänzt und einen besseren Canary-Schritt eingeführt.

Das Aufsetzen neuer Umgebungen dauerte manuell mehrere Stunden und war fehleranfällig. Ich habe den gesamten Prozess mit Infrastructure as Code beschrieben und in die Pipeline integriert. Danach ließ sich eine neue Umgebung in wenigen Minuten reproduzierbar erstellen. Das sparte dem Team viel Zeit und reduzierte Fehler deutlich.

Die Entwickler wollten schneller deployen, während der Betrieb um die Stabilität fürchtete. Ich habe beide Seiten zusammengebracht und gemeinsam klare Qualitätskriterien und automatisierte Tests in der Pipeline definiert. So konnten wir schneller und zugleich sicherer ausliefern. Das Vertrauen zwischen den Teams wuchs spürbar.

Die monatliche Cloud-Rechnung stieg unerwartet stark an. Ich habe die Kosten nach Diensten aufgeschlüsselt und ungenutzte Ressourcen sowie überdimensionierte Instanzen identifiziert. Nach dem Abschalten und Anpassen sanken die Kosten deutlich. Anschließend habe ich ein Kosten-Monitoring eingerichtet, um künftig früh zu warnen.