Miss deine Bereitschaft zur Kubernetes-Administration mit 20 unabhängigen Challenges, die eine zweite Gruppe von Betriebsszenarien aus den öffentlichen CKA-Domänen bilden. Aus Symptomen, Anforderungsdateien, Events, Logs und Objektzuständen leitest du Änderungen ab und erfüllst automatische Endzustandsprüfungen ohne befehlsweise Anleitung.
Diese Form betont Speicherlebenszyklus, Node- und Komponentenfehler, Autoscaling und Unterbrechungsschutz, Cluster-Erweiterungen und neuere Netzwerkressourcen. Sie ist eine eigenständige vollständige Übungsprüfung, keine Fortsetzung von Prüfung 01, und setzt die geprüften Kubernetes-Grundlagen voraus.
Was du lernen wirst
- Logspeicher dynamisch bereitstellen und ein Released Volume mit Retain-Policy ohne Datenverlust sicher neu binden
- Einen statischen Pod, lokalen Image-Pull, metrics-server-Erkennung, Init-Container, Scheduling-Drift und Headless-Service-DNS reparieren
- CPU-basiertes Horizontal Pod Autoscaling einrichten und freiwillige Unterbrechungen mit einem PodDisruptionBudget absichern
- Restricted PodSecurity durch Non-root-Ausführung, seccomp, entfernte Capabilities und explizite Ressourcen erfüllen
- Lesenden Cluster-Diagnosezugriff per RBAC delegieren, ohne Änderungen, Secrets oder Wildcard-Administration zu erlauben
- Ein bereitgestelltes kubeadm-Zertifikat prüfen und erneuern, Drain-Nachweise erfassen und Node und Workloads nach Upgrade-Vorbereitung wiederherstellen
- Ein vorbereitetes CSI-ähnliches Paket mit Kustomize anpassen und eine vom Controller abgeglichene Custom Resource prüfen
- Gateway-API-Routing bauen, EndpointSlice-gestützten Zugriff reparieren, Egress per NetworkPolicy begrenzen und CoreDNS bedingt weiterleiten
Für wen dieser Kurs geeignet ist
Diese Übungsprüfung richtet sich an Kubernetes-Administratoren und CKA-Kandidaten nach strukturierter Schulung, die mit anderen Fehlerbildern und Ressourcen einen weiteren unabhängigen Bereitschaftstest möchten. Du solltest unbekannten Cluster-Zustand untersuchen und selbst einen gültigen Befehls- oder YAML-Weg wählen können.
Voraussetzungen: Linux-CLI, Kubernetes-YAML, kubectl, Pods, Deployments, StatefulSets, Services, Speicher, Scheduling, RBAC und Fehleranalyse sollten sitzen. Erfahrung mit HPA, PDB, Pod Security, kubeadm-Zertifikaten, Kustomize, CRDs und Controllern, Gateway API, EndpointSlices, NetworkPolicy und CoreDNS wird dringend empfohlen.
Lernumgebung: Der Kurs enthält 20 getrennte Challenges in einer Ubuntu-22.04-CKA-Terminalumgebung mit dem Kubernetes-Einzelknotenprofil labex-v135. Elf sind mittel und neun fortgeschritten. Jede startet in einer eigenen vorbereiteten VM, nennt Situation, Umfang, Kriterien und wenige Hinweise und prüft den geforderten Cluster- oder Dateizustand mit zwei oder drei automatischen Checks.
Häufig gestellte Fragen
Ist dies eine offizielle CKA-Prüfung oder ein offizieller Fragensatz?
Nein. Dies ist eine unabhängige LabEx-Ressource ohne Verbindung, Billigung oder Sponsoring durch The Linux Foundation oder CNCF. Die Abdeckung folgt öffentlichen CKA-Domänen, aber Aufgaben und Verteilung entsprechen weder echten Fragen noch der exakten Prüfungsmischung.
Wie unterscheidet sie sich von CKA-Übungsprüfung 01?
Sie ist eine andere vollständige Form, keine Fortsetzung, Nachschulung oder bewusst schwierigere Version. Schwerpunkte sind dynamischer Speicher und Retain-Wiederherstellung, statische Pods, Metriken, HPA und PDB, Pod Security, Gateway API, Egress, EndpointSlices, Zertifikate und vorbereitete Erweiterungen.
Wie funktionieren Zeit und Bewertung?
Für den vollständigen Versuch werden 120 Minuten empfohlen. Jede der 20 Challenges zählt fünf simulierte Punkte, zusammen 100; 66 Punkte sind die simulierte LabEx-Übungsschwelle. Diese Werte dienen nur der Selbsteinschätzung und sagen kein offizielles CKA-Ergebnis voraus.
Welche Infrastrukturaufgaben sind simuliert oder vorbereitet?
Das Zertifikat wird nur in einer bereitgestellten kubeadm-PKI-Kopie erneuert, nicht im Live-Cluster. Die Upgrade-Aufgabe umfasst Cordon, Drain, Nachweise, Uncordon und Wiederherstellung ohne Binärinstallation. CSI verwendet einen vorbereiteten Mock-Treiber; Operator und Gateway ebenfalls schlanke vorbereitete Komponenten. Geprüft werden begrenzte Objekte und Abläufe, kein vollständiger Produktionslebenszyklus.
