Interviewfragen für Senior DevOps Engineers zu Produktionssystemen

Milad Bonakdar
Autor
Bereiten Sie sich mit praxisnahen Fragen zu Kubernetes, Terraform State, GitOps, Sicherheit, Observability, Incident Response und Produktions-Trade-offs vor.
Worauf Senior-DevOps-Interviews abzielen
In Senior-DevOps-Interviews geht es selten nur darum, Tools aufzuzählen. Sie müssen zeigen, dass Sie Produktionssysteme betreiben können: Kubernetes-Ausfälle eingrenzen, Terraform-State schützen, GitOps-Rollouts steuern, Cloud-Resilienz planen, Sicherheitskontrollen erklären und Incidents sauber nachbereiten.
Nutzen Sie diesen Leitfaden, um Antworten zu üben, die Urteilskraft zeigen: Was prüfen Sie zuerst, welches Risiko reduzieren Sie, wie validieren Sie die Lösung und wie erklären Sie den Trade-off gegenüber Engineering, Security oder Product?
Fortgeschrittenes Kubernetes
1. Erläutern Sie die Kubernetes-Architektur und die Rolle der Schlüsselkomponenten.
Antwort: Kubernetes nutzt eine Architektur aus Control Plane und Worker Nodes. Eine starke Senior-Antwort erklärt sowohl die Komponenten als auch, wie der gewünschte Zustand durch das System läuft:
Komponenten der Steuerungsebene:
- API-Server: Frontend für die Kubernetes-Steuerungsebene, verarbeitet alle REST-Anfragen
- etcd: Verteiltes Schlüsselwert-Speicher für den Clusterstatus
- Scheduler: Weist Pods basierend auf Ressourcenanforderungen Knoten zu
- Controller Manager: Führt Controller-Prozesse aus (Replikation, Endpunkte usw.)
- Cloud Controller Manager: Integration mit Cloud-Provider-APIs
Knotenkomponenten:
- kubelet: Agent, der sicherstellt, dass Container in Pods ausgeführt werden
- kube-proxy: Verwaltet Netzwerkregeln für die Pod-Kommunikation
- Container Runtime: Führt Container aus (Docker, containerd, CRI-O)
Funktionsweise:
- Benutzer übermittelt Deployment über kubectl
- API-Server validiert und speichert in etcd
- Scheduler weist Pods Knoten zu
- kubelet auf dem Knoten erstellt Container
- kube-proxy konfiguriert die Vernetzung
Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer
2. Wie beheben Sie einen Pod, der in CrashLoopBackOff feststeckt?
Antwort: Systematischer Debugging-Ansatz:
Häufige Ursachen:
- Anwendung stürzt beim Start ab
- Fehlende Umgebungsvariablen
- Falsche Liveness-Probe-Konfiguration
- Unzureichende Ressourcen (OOMKilled)
- Image-Pull-Fehler
- Fehlende Abhängigkeiten
Beispielhafte Fehlerbehebung:
Seltenheit: Sehr häufig Schwierigkeitsgrad: Mittel
3. Erläutern Sie die Kubernetes-Vernetzung: Services, Ingress und Netzwerkrichtlinien.
Antwort: Kubernetes-Netzwerkschichten:
Services: Arten der Service-Exponierung:
Ingress: HTTP/HTTPS-Routing:
Netzwerkrichtlinien: Steuern der Pod-zu-Pod-Kommunikation:
Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer
4. Wie implementieren Sie Autoscaling in Kubernetes?
Antwort: Mehrere Autoscaling-Strategien:
Horizontal Pod Autoscaler (HPA):
Vertical Pod Autoscaler (VPA):
Cluster Autoscaler: Passt die Clustergröße automatisch basierend auf ausstehenden Pods an:
Seltenheit: Häufig Schwierigkeitsgrad: Mittel
Fortgeschrittenes Terraform
5. Erläutern Sie das Terraform-State-Management und die Best Practices.
Antwort: Terraform-State verfolgt die Infrastruktur und ist entscheidend für den Betrieb.
Remote-State-Konfiguration:
State-Locking:
Bewährte Verfahren:
1. Niemals State-Dateien in Git committen
2. Workspaces für Umgebungen verwenden
3. Vorhandene Ressourcen importieren
4. State-Manipulation (vorsichtig verwenden)
5. State vor größeren Änderungen sichern
Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer
6. Wie strukturieren Sie Terraform-Code für große Projekte?
Antwort: Modulare Struktur für Wartbarkeit:
Verzeichnisstruktur:
Modulbeispiel:
Verwendung von Modulen:
Seltenheit: Häufig Schwierigkeitsgrad: Schwer
Cloud-Architektur
7. Entwerfen Sie eine hochverfügbare Multi-Region-Architektur auf AWS.
Antwort: Multi-Region-Architektur für hohe Verfügbarkeit:
Schlüsselkomponenten:
1. DNS und Traffic-Management:
2. Datenbankreplikation:
3. Datenreplikation:
Designprinzipien:
- Aktiv-Aktiv- oder Aktiv-Passiv-Setup
- Automatisches Failover mit Integritätsprüfungen
- Datenreplikation mit minimaler Verzögerung
- Konsistentes Deployment über Regionen hinweg
- Überwachung und Alarmierung für beide Regionen
Seltenheit: Häufig Schwierigkeitsgrad: Schwer
GitOps & CI/CD
8. Erläutern Sie GitOps und wie man es mit ArgoCD implementiert.
Antwort: GitOps verwendet Git als Single Source of Truth für deklarative Infrastruktur und Anwendungen.
Prinzipien:
- Deklarative Konfiguration in Git
- Automatisierte Synchronisation
- Versionskontrolle für alle Änderungen
- Kontinuierliche Abstimmung
ArgoCD-Implementierung:
Verzeichnisstruktur:
Kustomization:
Vorteile:
- Git als Audit-Trail
- Einfache Rollbacks (git revert)
- Deklarativer Soll-Zustand
- Automatisierte Drift-Erkennung
- Multi-Cluster-Management
Seltenheit: Häufig Schwierigkeitsgrad: Mittel
Sicherheit & Compliance
9. Wie implementieren Sie Sicherheitsbest Practices in Kubernetes?
Antwort: Mehrschichtiger Sicherheitsansatz:
1. Pod-Sicherheitsstandards:
2. RBAC (Role-Based Access Control):
3. Netzwerkrichtlinien:
4. Geheimnismanagement:
5. Sicherheitskontext:
6. Image-Scanning:
Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer
Observability & SRE
10. Entwerfen Sie einen umfassenden Observability-Stack.
Antwort: Drei Säulen der Observability: Metriken, Protokolle, Traces
Architektur:
1. Metriken (Prometheus + Grafana):
2. Protokollierung (Loki):
3. Tracing (Jaeger):
4. Alarmierungsregeln:
5. SLO-Überwachung:
Seltenheit: Häufig Schwierigkeitsgrad: Schwer
Disaster Recovery
11. Wie implementieren Sie Disaster Recovery für einen Kubernetes-Cluster?
Antwort: Umfassende DR-Strategie:
1. Backup-Strategie:
2. etcd-Backup:
3. Wiederherstellungsprozedur:
4. Multi-Region-Failover:
5. RTO/RPO-Ziele:
- RTO (Recovery Time Objective): < 1 Stunde
- RPO (Recovery Point Objective): < 15 Minuten
- Regelmäßige DR-Übungen (monatlich)
- Dokumentierte Runbooks
- Automatisches Failover, wo möglich
Seltenheit: Häufig Schwierigkeitsgrad: Schwer
Service Mesh
12. Erläutern Sie die Service-Mesh-Architektur und wann sie verwendet werden sollte.
Antwort: Ein Service Mesh bietet eine Infrastrukturschicht für die Service-zu-Service-Kommunikation.
Kernkomponenten:
Istio-Implementierung:
Wann verwenden:
- Komplexe Microservice-Kommunikation mit vielen Abhängigkeiten
- mTLS, Autorisierung und einheitliche Traffic-Regeln zwischen Services
- Canary-Releases, Traffic-Splitting und bessere Fehlerisolation
- Gemeinsame Observability für Service-zu-Service-Aufrufe
Worauf achten: Ein Service Mesh erhöht Komplexität, Latenz und Betriebsaufwand. In Senior-Interviews sollten Sie erklären, warum der Nutzen diese Kosten im konkreten System rechtfertigt.
Fazit
Bereiten Sie sich nicht nur auf Tool-Definitionen vor. Zeigen Sie an jedem Beispiel, wie Sie ein Produktionsproblem eingrenzen, Risiken priorisieren, eine Lösung validieren und den nächsten dauerhaften Fix ableiten.


