Veröffentlicht am

CKA, CKAD und CKS Erfahrungsbericht: Mein Weg zum Bestehen

Teilen:
Authors

TL;DR

  • Mein Weg: Erst CKA, dann CKAD (3 Monate spaeter), dann CKS (6 Monate spaeter). Alle drei beim ersten Versuch bestanden.
  • Die CKA war die haerteste Pruefung -- nicht wegen der Schwierigkeit, sondern weil alles neu war: das Format, der Zeitdruck, die Pruefungsumgebung.
  • CKAD nach CKA war deutlich einfacher, weil ca. 40% der Themen sich ueberschneiden. Die Vorbereitung hat nur 3 statt 8 Wochen gedauert.
  • CKS war inhaltlich die anspruchsvollste Pruefung. Ohne solide CKA-Grundlage haette ich keine Chance gehabt.
  • Der groesste Fehler, den ich gemacht habe: zu viel Theorie, zu wenig Hands-on-Uebung unter Zeitdruck.

Mein Hintergrund: Wo ich vor der CKA stand

Bevor ich meine erste Kubernetes-Zertifizierung in Angriff genommen habe, arbeitete ich etwa 2 Jahre mit Kubernetes. Nicht taeglich, aber regelmaessig. Ich hatte Deployments geschrieben, Services konfiguriert, Helm Charts angepasst und gelegentlich Pods debuggt. Mein Team betrieb mehrere Cluster auf AWS EKS.

Ich dachte, ich kenne Kubernetes ganz gut. Dann habe ich die erste killer.sh-Probesitzung gemacht und 38% erreicht. Das war ein Weckruf.

Was mir fehlte, war nicht das Konzeptwissen -- es war die Geschwindigkeit. Ich wusste, was ein NetworkPolicy tut, aber ich konnte keines in 3 Minuten aus dem Kopf schreiben. Ich verstand etcd-Backups konzeptuell, hatte aber noch nie eines manuell durchgefuehrt. Ich kannte RBAC, hatte aber nie eine ClusterRole von Grund auf erstellt.

Die Zertifizierung hat mir gezeigt: Verstehen und Koennen sind zwei verschiedene Dinge.


CKA: Die erste Pruefung

Vorbereitung (8 Wochen)

Mein Vorbereitungsplan sah so aus:

Woche 1-2: Bestandsaufnahme

  • Killer.sh-Probesitzung als Baseline
  • Schwachstellen identifiziert: NetworkPolicies, etcd-Backup, kubeadm-Upgrades, Troubleshooting von Node-Problemen
  • Lernressourcen ausgewaehlt

Woche 3-5: Strukturiertes Lernen

  • KodeKloud CKA-Kurs durchgearbeitet (ca. 2h pro Tag)
  • Jedes Kapitel mit Hands-on-Labs vertieft
  • Parallel die offizielle Kubernetes-Dokumentation als Referenz genutzt

Woche 6-7: Intensive Praxis

  • Eigenen kind-Cluster aufgesetzt fuer taeliches Ueben
  • killer.sh zweite Session: 71% (deutliche Verbesserung)
  • Fokus auf schwache Bereiche: NetworkPolicies und Troubleshooting

Woche 8: Pruefungsvorbereitung

  • Vim-Konfiguration und kubectl-Aliase eingeuebt
  • Pruefungsumgebung getestet (Browser, Webcam, Raum)
  • Letzte Wiederholung der Dokumentations-Bookmarks

Einen detaillierten Lernplan fuer die CKA findet ihr in unserem CKA 8-Wochen-Lernplan.

Fehler, die ich in der Vorbereitung gemacht habe

Zu viel Video, zu wenig Terminal. In den ersten Wochen habe ich stundenlang Kursvideos geschaut, ohne selbst zu tippen. Das fuehlt sich produktiv an, ist es aber nicht. Die CKA ist eine Hands-on-Pruefung. Erst als ich angefangen habe, jedes Konzept sofort in einem Cluster nachzubauen, hat sich echtes Wissen aufgebaut.

YAML auswendig lernen statt generieren. Ich habe anfangs versucht, komplette YAML-Manifeste auswendig zu lernen. Das ist Zeitverschwendung. Der richtige Weg: kubectl create deployment --dry-run=client -o yaml generiert euch die Grundstruktur. Ihr muesst nur die Anpassungen kennen.

Die Dokumentation unterschaetzt. In der Pruefung duerft ihr kubernetes.io/docs nutzen. Ich habe erst in Woche 6 angefangen, gezielt in der Dokumentation zu suchen. Haette ich das frueher gemacht, haette ich viel schneller die richtigen YAML-Snippets gefunden.

Pruefungstag: CKA

Check-in (30 Minuten vor der Pruefung):

Der Check-in-Prozess war aufwendiger als erwartet. Ich musste:

  • Meinen Ausweis von beiden Seiten fotografieren
  • Meinen gesamten Arbeitsplatz per Webcam zeigen (360-Grad-Schwenk)
  • Alle Monitore bis auf einen abstecken
  • Wasserflasche und alles andere vom Tisch raeumen
  • Den Raum verschliessen

Tipp: Plant mindestens 30 Minuten fuer den Check-in ein. Bei mir hat es 20 Minuten gedauert, bis der Proctor alles abgenommen hatte.

Die Pruefung selbst:

Die ersten 5 Minuten habe ich genutzt, um meine Umgebung einzurichten:

alias k=kubectl
export do="--dry-run=client -o yaml"
source <(kubectl completion bash)
complete -o default -F __start_kubectl k

Dann die erste Aufgabe gelesen -- und sofort gemerkt, dass killer.sh schwerer war als die echte Pruefung. Das hat enorm beruhigt.

Was mich ueberrascht hat:

  • Die Pruefungsumgebung war langsamer als erwartet. Befehle brauchten manchmal 2-3 Sekunden.
  • Das Copy-Paste zwischen Aufgabentext und Terminal war umstaendlich (rechter Mausklick statt Strg+C/V).
  • Manche Aufgaben waren extrem kurz (2 Minuten), andere sehr umfangreich (15 Minuten).
  • Der integrierte Notizblock war praktisch, um ueberspungene Aufgaben zu markieren.

Meine Strategie:

  1. Zuerst alle Aufgaben ueberfliegen und nach Schwierigkeit sortieren
  2. Leichte Aufgaben zuerst (Punkte sichern)
  3. Mittlere Aufgaben als naechstes
  4. Schwere Aufgaben am Ende mit der verbleibenden Zeit
  5. Nie laenger als 10 Minuten an einer Aufgabe haengenbleiben

Ergebnis: 82% -- bestanden. Das Ergebnis kam nach ca. 24 Stunden per E-Mail.

Weitere Tipps fuer den Pruefungstag gibt es in unserem Artikel CKA Pruefung bestehen: 10 Tipps.


CKAD: Die zweite Pruefung (3 Monate nach CKA)

Warum CKAD nach CKA einfacher war

Nach der CKA hatte ich zwei grosse Vorteile: Ich kannte das Pruefungsformat und ich hatte ca. 40% der CKAD-Themen bereits durch die CKA abgedeckt.

Die Ueberschneidungen sind erheblich:

  • Pods, Deployments, Services
  • ConfigMaps, Secrets
  • Liveness/Readiness Probes
  • Labels, Selectors, Annotations
  • Grundlegendes Troubleshooting

Was bei der CKAD neu war:

  • Multi-Container-Patterns (Sidecar, Init Container)
  • CronJobs und Jobs im Detail
  • Helm-Grundlagen (install, upgrade, rollback)
  • Canary Deployments
  • Staerkerer Fokus auf Application Design

Vorbereitung (3 Wochen)

Da ich viele Themen bereits kannte, habe ich mich auf die Unterschiede konzentriert:

Woche 1: CKAD-spezifische Themen durcharbeiten (Multi-Container, Helm, CronJobs)

Woche 2: killer.sh CKAD-Session (67% beim ersten Versuch -- die Ueberschneidung mit CKA hat geholfen)

Woche 3: Schwachstellen nacharbeiten und zweite killer.sh-Session (79%)

Pruefungstag: CKAD

Der Check-in war identisch zur CKA, diesmal wusste ich aber, was mich erwartet. Die Pruefung selbst fuehlte sich entspannter an -- nicht weil sie einfach war, sondern weil ich das Format kannte.

Ueberraschung: Die CKAD hatte mehr Aufgaben als die CKA, aber die einzelnen Aufgaben waren kuerzer. Zeitmanagement war trotzdem der entscheidende Faktor.

Ergebnis: 87% -- die beste meiner drei Pruefungen. Die CKA-Vorbereitung hat hier massiv geholfen.

Einen detaillierten Vergleich der Pruefungen findet ihr in unserem CKA vs. CKAD vs. CKS Vergleich.


CKS: Die dritte Pruefung (6 Monate nach CKAD)

Warum CKS die haerteste Pruefung war

Die CKS (Certified Kubernetes Security Specialist) war mit Abstand die anspruchsvollste der drei Pruefungen. Und das aus mehreren Gruenden:

Das Themenspektrum ist riesig. Security in Kubernetes umfasst nicht nur Kubernetes selbst, sondern auch:

  • Container-Image-Security (Trivy, Image Signing)
  • Runtime-Security (Falco, Seccomp, AppArmor)
  • Network Security (NetworkPolicies, Ingress-Controller)
  • Cluster Hardening (RBAC, ServiceAccounts, API Server Flags)
  • Supply Chain Security (Admission Controller, OPA/Gatekeeper)
  • Monitoring und Auditing

Die Tools sind vielfaeltig. In CKA und CKAD arbeitet ihr hauptsaechlich mit kubectl. In der CKS muesst ihr zusaetzlich Falco-Regeln schreiben, Trivy-Scans interpretieren, AppArmor-Profile anwenden und OPA-Rego-Policies verstehen. Das sind voellig unterschiedliche Tools mit unterschiedlicher Syntax.

Weniger Zeit pro Aufgabe. Die CKS hat 2 Stunden bei gleicher Aufgabenzahl, aber die Aufgaben sind komplexer. Ihr muesst oft mehrere Schritte kombinieren (z.B. erst einen Scan durchfuehren, dann die Policy anpassen, dann verifizieren).

Vorbereitung (6 Wochen)

Woche 1-2: Grundlagen der Kubernetes-Security

  • CKS-Kurs auf KodeKloud durchgearbeitet
  • Parallel: Kubernetes Security Best Practices aus der offiziellen Doku
  • Fokus auf RBAC, NetworkPolicies, SecurityContexts (aus CKA schon teilweise bekannt)

Woche 3-4: Security-Tools

  • Falco installiert und Regeln geschrieben
  • Trivy fuer Image-Scanning verwendet
  • AppArmor- und Seccomp-Profile erstellt und getestet
  • OPA/Gatekeeper-Policies deployed

Woche 5: Integration und Praxis

  • killer.sh CKS-Session: 52% (der niedrigste aller meiner Probe-Ergebnisse)
  • Schwachstellen massiv nachgearbeitet (vor allem Falco und Supply Chain)

Woche 6: Letzte Vorbereitung

  • Zweite killer.sh-Session: 68%
  • Wiederholung aller Tool-spezifischen Befehle
  • Bookmark-Sammlung fuer die Doku aufgebaut

Pruefungstag: CKS

Diesmal war ich deutlich nervoeser als bei CKA und CKAD. Die killer.sh-Ergebnisse waren niedrig, und ich wusste, dass die CKS als die schwerste CNCF-Pruefung gilt.

Was anders war als bei CKA/CKAD:

  • Mehr Aufgaben, die mehrere Schritte erfordern
  • Ich musste zwischen verschiedenen Clustern und Namespaces springen
  • Einige Aufgaben erforderten das Lesen und Interpretieren von Log-Output (Falco, Audit Logs)
  • Die Doku-Navigation war schwieriger, weil Security-Themen ueber viele Seiten verstreut sind

Mein kritischer Moment: Bei einer Aufgabe zu Falco-Regeln bin ich 12 Minuten haengengeblieben. Die Syntax war komplexer als in meiner Uebung. Ich habe die Aufgabe markiert, uebersprungen und am Ende mit frischem Kopf noch einmal angesetzt. Beim zweiten Versuch hat es geklappt.

Ergebnis: 74% -- bestanden, aber knapper als bei CKA und CKAD. Die Bestehensgrenze liegt bei 67%, also war das Polster duenn. Trotzdem: bestanden ist bestanden.


Was ich bei allen drei Pruefungen gelernt habe

Die Pruefungsumgebung ist ein eigener Gegner

Egal wie gut euer Kubernetes-Wissen ist: Wenn ihr die Pruefungsumgebung nicht kennt, verliert ihr wertvolle Minuten. Die Remote-Desktop-Umgebung ist langsamer als euer lokales Terminal. Copy-Paste funktioniert anders. Der integrierte Browser fuer die Doku ist traege.

Mein Tipp: Uebt mindestens einmal mit killer.sh unter realen Bedingungen. Nicht auf eurem bequemen Setup mit drei Monitoren und tmux, sondern in einem Browser-Tab, genau wie in der Pruefung.

Zeitmanagement schlaegt Wissen

Ich kenne Leute mit mehr Kubernetes-Erfahrung als ich, die durchgefallen sind. Nicht weil sie die Antworten nicht wussten, sondern weil sie bei schweren Aufgaben zu lange haengengeblieben sind und am Ende keine Zeit mehr fuer die leichten Punkte hatten.

Meine Faustregel: Wenn eine Aufgabe nach 5 Minuten nicht klar ist, markieren und weitergehen. Lieber 90% der leichten Aufgaben richtig als 50% der schweren.

Die Dokumentation ist euer bester Freund

In allen drei Pruefungen habe ich die offizielle Dokumentation intensiv genutzt. Nicht zum Lernen -- dafuer ist sie in der Pruefung zu langsam -- sondern zum schnellen Nachschlagen von:

  • YAML-Strukturen (z.B. NetworkPolicy-Spec)
  • Befehlssyntax (z.B. kubeadm upgrade Schritte)
  • Konfigurationsoptionen (z.B. SecurityContext-Felder)
# Diese Bookmarks hatte ich in allen drei Pruefungen offen:
# kubernetes.io/docs/reference/kubectl/cheatsheet/
# kubernetes.io/docs/concepts/services-networking/network-policies/
# kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
# kubernetes.io/docs/reference/access-authn-authz/rbac/

kubectl-Generierung spart mehr Zeit als alles andere

Der wichtigste einzelne Tipp fuer alle drei Pruefungen:

# Niemals YAML von Hand schreiben. Immer generieren lassen:
kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
kubectl create deployment app --image=nginx --dry-run=client -o yaml > dep.yaml
kubectl create service clusterip svc --tcp=80:80 --dry-run=client -o yaml > svc.yaml
kubectl create configmap cfg --from-literal=key=val --dry-run=client -o yaml > cm.yaml
kubectl create secret generic sec --from-literal=pw=123 --dry-run=client -o yaml > sec.yaml

Damit habt ihr in Sekunden ein korrektes Grundgeruest, das ihr nur noch anpassen muesst. Von Hand wuerde das 3-5 Minuten dauern -- und ihr riskiert Tippfehler.


Was ich heute anders machen wuerde

Wenn ich die drei Zertifizierungen nochmal von vorne machen muesste, wuerde ich Folgendes aendern:

1. Frueher mit Hands-on anfangen

Statt 2 Wochen Theorie gefolgt von 4 Wochen Praxis wuerde ich ab Tag 1 parallel ueben. Video schauen und sofort im Terminal nachbauen.

2. Einen festen Uebungsrhythmus etablieren

45 Minuten pro Tag sind effektiver als 6 Stunden am Wochenende. Konsistenz schlaegt Intensitaet.

3. Die killer.sh-Sessions besser timen

Ich habe meine erste killer.sh-Session zu frueh gemacht (Woche 2) und war entsprechend frustriert. Besser: Erste Session nach 60% der Vorbereitung, zweite Session eine Woche vor der Pruefung.

4. CKS-Vorbereitung frueher beginnen

6 Wochen waren fuer die CKS knapp. Ich wuerde heute 8 Wochen einplanen, besonders fuer die Security-Tools, die nicht zum normalen Kubernetes-Alltag gehoeren.

5. Mehr Community nutzen

Die Kubernetes-Community (Slack, Reddit, Foren) ist unglaublich hilfsbereit. Ich habe erst nach meiner CKA angefangen, Fragen dort zu stellen. Das haette mir vorher schon viele Stunden Recherche erspart.


Die Auswirkungen auf meine Karriere

Seit ich alle drei Zertifizierungen habe, hat sich einiges veraendert:

  • Sichtbarkeit: Auf LinkedIn bekomme ich regelmaessig Anfragen von Recruitern, die explizit nach CKA/CKS suchen.
  • Selbstvertrauen: Ich gehe anders an Kubernetes-Probleme heran. Die Pruefungsvorbereitung hat Wissensluecken geschlossen, von denen ich nicht einmal wusste.
  • Teamrolle: Ich bin zum internen Kubernetes-Experten geworden. Kollegen fragen mich bei Architekturentscheidungen und Troubleshooting.
  • Gehalt: Nach der CKS-Zertifizierung konnte ich im Jahresgespraech eine Gehaltserhoehung verhandeln.

Ob sich die Zertifizierungen "lohnen", haengt von eurer Situation ab. Fuer mich war es eine der besten beruflichen Investitionen.


Meine Empfehlung: Die optimale Reihenfolge

Basierend auf meinem Kubernetes Zertifizierung Erfahrungsbericht empfehle ich folgende Reihenfolge:

  1. CKA zuerst: Die breiteste Wissensbasis, und Voraussetzung fuer CKS. Auch wenn ihr Entwickler seid -- das Admin-Wissen hilft beim Debugging.
  2. CKAD als zweites: Nutzt die Ueberschneidung mit CKA. Innerhalb von 3 Monaten nach CKA ist die Vorbereitung minimal.
  3. CKS als drittes: Erst wenn CKA-Wissen gefestigt ist. Plant genuegend Zeit fuer die Security-Tools ein.

Wer den kompletten Pfad gehen will, kann sich ueber den Kubestronaut-Status informieren.


Fazit

Die drei CNCF-Zertifizierungen waren anstrengend, zeitintensiv und manchmal frustrierend. Aber sie haben mein Kubernetes-Wissen auf ein voellig neues Level gehoben -- nicht nur durch den Pruefungsstoff, sondern durch die Art der Vorbereitung: systematisch, praxisorientiert und unter Zeitdruck.

Wenn ihr ueberlegt, ob ihr eine Kubernetes Zertifizierung ablegen sollt: Tut es. Fangt mit der CKA an, nutzt killer.sh von Anfang an, und uebt jeden Tag ein bisschen statt einmal pro Woche viel. Der Rest kommt von allein.


Verwandte Artikel


Ihr plant eure eigene Kubernetes-Zertifizierung und wuenscht euch professionelle Unterstuetzung? Wir bieten individuelle Pruefungsvorbereitung und Team-Trainings an -- von zertifizierten Kubernetes-Experten. Jetzt unverbindlich anfragen.

Kubernetes-Beratung gesucht?

Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen