Container & Kubernetes

CKA, CKAD oder CKS: welche Prüfung zu deiner Rolle passt

CKA für Betrieb, CKAD für Entwicklung, CKS für Sicherheit, und die CKS setzt eine bestandene CKA voraus. Alle drei sind Praxisprüfungen an echten Clustern, in denen Tempo an der Kommandozeile mehr zählt als Theoriewissen.

6 Kapitel mit allen Befehlen
DevOps-Engineer erklärt einem Kollegen Container-Dashboards am Stehtisch
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Drei Examen, drei Rollen und eine unklare Reihenfolge

Wer nach einer Kubernetes-Zertifizierung sucht, landet fast immer bei denselben drei Kürzeln. Der Certified Kubernetes Administrator prüft den Betrieb eines Clusters, der Certified Kubernetes Application Developer die Sicht der Anwendungsentwicklung auf Workloads, und der Certified Kubernetes Security Specialist setzt auf dem CKA auf und behandelt Härtung, Supply-Chain-Sicherheit und Runtime-Erkennung. Kurslisten sortieren diese Angebote nach Produktnamen, beantworten aber nicht die eigentliche Frage: welches Examen zu deiner Rolle passt und was du überhaupt zuerst machen solltest.

Die Entscheidung ist nicht nur akademisch. Alle drei Prüfungen sind reine Praxisprüfungen in einer Browser-Umgebung mit echtem Cluster und kubectl, nicht mit Multiple Choice. Du löst Aufgaben unter Zeitdruck an mehreren Clustern, wechselst per SSH auf den Host der jeweiligen Aufgabe, arbeitest mit YAML-Manifesten und darfst dabei die offizielle Kubernetes-Dokumentation nutzen. Wer nur Folien gelesen hat, scheitert nicht am Wissen, sondern an der Geschwindigkeit im Terminal.

Typische Fehler sehen wir in der Vorbereitung immer wieder. Entwicklerinnen und Entwickler buchen den CKA, obwohl sie nie etcd sichern oder einen Cluster mit kubeadm aufsetzen werden. Administratoren steigen direkt beim CKS ein und stellen fest, dass die bestandene CKA Voraussetzung für die CKS ist. Und viele unterschätzen, wie viel Linux-Grundlage unter Kubernetes liegt, von Container-Runtime und cgroups über Netzwerk-Namespaces bis zu Zertifikaten und systemd-Units auf den Nodes.

Miniatur-Szene: Hafen mit gestapelten Containern, ein Kran hebt einen davon an, daneben ein Steuerrad
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Entscheidungsweg zur Kubernetes-Zertifizierung

  1. 01 Rolle klären: Betrieb, Entwicklung oder Security
  2. 02 Linux- und Container-Grundlagen absichern
  3. 03 CKA für Cluster-Betrieb oder CKAD für Workloads
  4. 04 Vorbereitungskurs mit Übungsclustern
  5. 05 CKS als Aufbau auf die bestandene CKA
  6. 06 Rezertifizierung rechtzeitig einplanen
Was du mitnimmst

So wählst du das passende Examen und bereitest dich vor

Die Auswahl fällt leichter, wenn du von deiner Rolle und deinem Cluster-Alltag ausgehst statt vom Zertifikatsnamen. Danach ergibt sich die Reihenfolge fast von selbst.

CKA, wenn du Cluster betreibst

Der CKA deckt im aktuellen Lehrplan Clusteraufbau und Lebenszyklus mit kubeadm, hochverfügbare Control Planes, Helm und Kustomize, CRDs und Operatoren, RBAC, Storage, Services mit Gateway API und Ingress sowie vor allem Troubleshooting ab, das mit 30 Prozent den größten Anteil hat. Das ist die richtige Wahl für Systemadministration, Plattform-Teams und alle, die für die Verfügbarkeit des Clusters geradestehen.

CKAD, wenn du Anwendungen auf Kubernetes bringst

Der CKAD bleibt oberhalb der Cluster-Ebene und prüft Deployments, Jobs und CronJobs, ConfigMaps und Secrets, Probes, Ressourcen-Limits, Services, Ingress sowie Debugging einzelner Pods. Cluster-Installation und etcd kommen darin nicht vor. Für Entwicklungsteams ist das der schnellere und passendere Einstieg.

CKS erst nach bestandener CKA

Vor dem CKS musst du die CKA bestanden haben. Geprüft werden unter anderem Cluster-Härtung, NetworkPolicies, Pod Security Standards, Admission Control und Policy as Code, Image-Scanning und Supply-Chain-Themen sowie Runtime-Erkennung mit Werkzeugen wie Falco und Audit-Logging. Plane den CKS also als zweiten Schritt ein, nicht als Einstieg.

Erst Linux, dann Kubernetes

Wenn Namespaces, Routing, Dateisysteme und Zertifikate auf Linux-Ebene noch wackeln, lohnt sich ein Zwischenschritt. Ein Linux-Aufbaukurs zur Administration oder ein Container-Workshop mit Docker und Podman spart in der Prüfungsvorbereitung mehr Zeit, als er kostet, weil du Fehlerbilder dann an der richtigen Schicht suchst.

Vorbereitung an echten Clustern statt an Folien

Bei cmt bereiten dich das Certified Kubernetes Administrator Training (CKA), der Kurs CKAD: Certified Kubernetes Application Developer und CKS: Certified Kubernetes Security Specialist gezielt auf die jeweilige Prüfung vor. Aus dem Linux-Foundation-Programm gibt es zusätzlich LFS458 Kubernetes Administration, LFD459: Kubernetes for App Developers und LFS460: Kubernetes Security Fundamentals.

Prüfungstag realistisch üben

Trainiere kubectl mit Kurzformen, Autovervollständigung, dem Erzeugen von Manifesten über --dry-run=client -o yaml und dem schnellen Wechsel zwischen Hosts und Namespaces. Wer jede Aufgabe im Editor von Hand tippt, verliert im Zeitfenster genau die Minuten, die am Ende zum Bestehen fehlen.

Tutorial

Vorbereitung, die im Prüfungsterminal trägt

Hier baust du dir zuerst einen Cluster, den du zerlegen darfst, trimmst dann kubectl auf Prüfungstempo und drillst danach die Aufgabentypen der drei Examen. Zum Schluss steht der Probelauf unter Zeitdruck, weil an der Uhr mehr Kandidaten scheitern als am Fachwissen.

01

Ein Cluster, den du kaputtmachen darfst

Ein verwalteter Cluster beim Cloud-Anbieter nützt dir für die CKA wenig, weil du dort nie an die Control Plane kommst. Du brauchst zwei Umgebungen.

Nimm kind für alles, was innerhalb von Pods passiert, und ein kubeadm-Cluster aus zwei bis drei virtuellen Maschinen für alles, was an der Control Plane, am kubelet oder an etcd hängt. Nur im zweiten Aufbau existieren /etc/kubernetes/manifests und /var/lib/kubelet/config.yaml, und genau darum drehen sich die teuersten Prüfungsaufgaben.

kind-cluster.yaml: drei Knoten in einem Rutsch
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

Start mit kind create cluster --name uebung --config kind-cluster.yaml. Der Cluster ist in unter einer Minute da und genauso schnell wieder weg, ideal für CKAD-Drills. Für CKA-Themen reicht es nicht: die Knoten sind Container, ein kaputtes kubelet debuggst du dort nicht realistisch.

Erst sichern, dann absichtlich zerstören
# etcd-Snapshot ziehen, bevor du etwas kaputt machst
sudo etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /opt/etcd-uebung.db

# Danach ruhig Unsinn bauen und die Reparatur üben
sudo mv /etc/kubernetes/manifests/kube-scheduler.yaml /tmp/
kubectl -n kube-system get pod          # der Scheduler verschwindet nach Sekunden
sudo journalctl -u kubelet -f           # hier stehen die Fehler, nicht in kubectl

Static Pods im Verzeichnis /etc/kubernetes/manifests startet das kubelet direkt, ohne API-Server. Ein Tippfehler dort erzeugt deshalb kein Event in kubectl get events, sondern nur eine Zeile im Journal. Wer diesen Reflex nicht trainiert hat, sucht in der Prüfung an der falschen Stelle.

02

kubectl auf Prüfungstempo bringen

Alle drei Examen sind Zeitprüfungen. Wer YAML von Hand tippt, schafft die Aufgaben fachlich und verliert trotzdem.

Kürzel, die dir in jeder Aufgabe Zeit sparen
# Zu Hause nachbauen, was die Prüfungsumgebung schon mitbringt
source <(kubectl completion bash)
alias k=kubectl
complete -o default -F __start_kubectl k

# Eigene Kürzel gelten nur in der aktuellen Shell, nach jedem ssh neu setzen
export do='--dry-run=client -o yaml'
export now='--grace-period=0 --force'

# Gerüste erzeugen statt schreiben
k run web --image=nginx:1.27 $do > pod.yaml
k create deploy api --image=nginx:1.27 --replicas=3 $do > deploy.yaml
k expose deploy api --port=80 --target-port=8080 $do > svc.yaml
k -n kube-system delete pod kaputt $now

Leg dir zusätzlich set et ts=2 sw=2 in die ~/.vimrc. YAML mit Tabulatoren parst nicht, und der Fehler kostet dich mitten in der Aufgabe mehrere Minuten Suche.

Nachschlagen statt raten
k explain deployment.spec.template.spec.containers.livenessProbe --recursive
k get pod -A -o wide --sort-by=.metadata.creationTimestamp
k get pod -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}'
k get events -A --sort-by=.lastTimestamp | tail -20
k describe pod web | sed -n '/Events/,$p'

kubectl explain kennt jedes Feld inklusive Typ und ist schneller als jede Suche in der Dokumentation. JSONPath brauchst du in allen drei Prüfungen mindestens einmal, meist um eine Liste in eine Datei zu schreiben.

03

CKA: die Handgriffe am Cluster

Die CKA prüft Betrieb. Diese fünf Abläufe solltest du ohne Nachdenken beherrschen.

Drills, die du wiederholen musst, bis sie sitzen

  • etcd-Snapshot ziehen und in ein leeres Datenverzeichnis zurückspielenetcdutl snapshot restore schreibt in ein neues Verzeichnis, etcdctl kann das in aktuellen etcd-Versionen nicht mehr. Danach musst du den Pfad im Static-Pod-Manifest von etcd anpassen, sonst startet der Cluster mit den alten Daten weiter und du hältst die Wiederherstellung für gescheitert. Der aktuelle CKA-Lehrplan nennt etcd nicht mehr ausdrücklich, im Betrieb bleibt der Handgriff trotzdem Pflicht.
  • Knoten für Wartung leeren und wieder aufnehmenkubectl drain bricht ohne --ignore-daemonsets ab, und Pods mit lokalem Speicher brauchen zusätzlich --delete-emptydir-data. Das uncordon danach vergessen viele, der Knoten bleibt dann leer und die Aufgabe gilt als nicht gelöst.
  • Cluster mit kubeadm auf die nächste Minor-Version hebenkubeadm springt nur eine Minor-Version pro Durchgang, und das kubelet-Paket aktualisierst du je Knoten getrennt. Die Reihenfolge Control Plane vor Worker ist keine Empfehlung, sondern Voraussetzung.
  • Eine Rolle samt Bindung bauen und die Wirkung prüfenOhne Prüfschritt weißt du nicht, ob die apiGroup stimmt. Genau daran scheitert handgeschriebenes RBAC-YAML fast immer.
  • Ein kaputtes kubelet wieder ans Laufen bringenFalscher Pfad in /var/lib/kubelet/config.yaml, abgelaufenes Zertifikat oder ein Dienst, der gar nicht läuft: die Ursache steht im Journal, nicht im Cluster. Wer nur kubectl get nodes kennt, sieht dort ausschließlich NotReady.
RBAC in vier Zeilen, inklusive Prüfung
k -n prod create sa deploy-bot
k -n prod create role reader --verb=get,list,watch --resource=pods,deployments
k -n prod create rolebinding reader-bind --role=reader \
     --serviceaccount=prod:deploy-bot

# Der Prüfschritt, der die Aufgabe absichert
k auth can-i list deployments -n prod --as=system:serviceaccount:prod:deploy-bot
k auth can-i delete pods -n prod --as=system:serviceaccount:prod:deploy-bot

Der erste Aufruf muss yes liefern, der zweite no. Ein unerwartetes no kommt meist von der falschen apiGroup: Deployments liegen in apps, Pods in der Core-Gruppe. kubectl create role setzt die Gruppe automatisch richtig, handgeschriebenes YAML nicht.

04

CKAD: viele kleine Aufgaben, wenig Zeit

Die CKAD fragt nichts an der Control Plane ab. Der Druck sitzt in der Menge kleiner Aufgaben, die alle einen kurzen Weg haben.

Aufgabe und kürzester Weg

AufgabeSchnellster Befehl
Wert aus einem Secret in den Containerk create secret generic db --from-literal=pass=geheim, dann envFrom
Job einmalig aus einem CronJob startenk create job jetzt --from=cronjob/backup
Rollout zurückdrehenk rollout undo deploy/api --to-revision=2
Logs mehrerer Pods gleichzeitigk logs -l app=api --all-containers --tail=50
Ressourcen nachträglich begrenzenk set resources deploy/api --limits=cpu=500m,memory=256Mi
Datei aus einem Pod holenk cp prod/web-0:/var/log/app.log ./app.log
Container ohne Shell untersuchenk debug -it web --image=busybox --target=app
Probes, die in fast jeder Aufgabe vorkommen
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
    readinessProbe:
      exec:
        command: ["cat", "/tmp/bereit"]
      failureThreshold: 3
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

Die Liveness-Probe startet den Container neu, die Readiness-Probe nimmt ihn nur aus dem Service. Wer beide verwechselt, baut eine Anwendung, die sich beim Start selbst in einer Neustartschleife erschlägt. Für langsam startende Anwendungen ist die Startup-Probe die richtige Antwort, nicht ein hoher Wert bei initialDelaySeconds.

05

CKS: härten, ohne den Cluster zu erlegen

Die CKS ist die einzige der drei Prüfungen, in der eine korrekte Maßnahme die Anwendung sofort lahmlegen kann. Genau das wird auch geprüft.

Default-Deny als Ausgangspunkt jeder NetworkPolicy-Aufgabe
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: dns-erlauben
  namespace: prod
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Policies sind additiv, es gibt kein Deny. Du erlaubst also nach dem Default-Deny gezielt wieder einzelne Wege.

Pod Security Admission und Image-Prüfung
# Erst warnen, dann erzwingen: so siehst du vorher, was rausfliegt
k label --overwrite ns prod pod-security.kubernetes.io/warn=restricted
k label --overwrite ns prod pod-security.kubernetes.io/audit=restricted
k rollout restart deploy -n prod        # jetzt erscheinen die Warnungen
k label --overwrite ns prod pod-security.kubernetes.io/enforce=restricted

# Images vor dem Ausrollen prüfen
trivy image --severity HIGH,CRITICAL --ignore-unfixed nginx:1.27

# Cluster gegen eine Härtungsbasis messen
kube-bench run --targets master,node

Das Profil restricted verlangt unter anderem runAsNonRoot, allowPrivilegeEscalation: false, das Ablegen aller Capabilities und seccompProfile.type: RuntimeDefault. Setz diese Felder im Pod-Spec, bevor du enforce aktivierst, sonst startet kein Pod mehr nach.

CKS-Themen, die im Training gern hinten runterfallen

  • Audit-Policy in /etc/kubernetes/audit-policy.yaml anlegen und die Flags --audit-policy-file und --audit-log-path im Static Pod des API-Servers ergänzen
  • automountServiceAccountToken: false am ServiceAccount und am Pod, damit kein Token im Container liegt, der ihn nicht braucht
  • AppArmor-Profile setzt du inzwischen über securityContext.appArmorProfile, ältere Beispiele im Netz nutzen noch die Annotation
  • Container-Laufzeit prüfen mit crictl ps, crictl inspect und crictl logs, weil der API-Server bei manchen Aufgaben schlicht nichts mehr weiß
  • Falco-Regeln lesen und eine Regel anpassen, statt sie neu zu erfinden
06

Der Probelauf unter Prüfungsbedingungen

Übung ohne Uhr misst nichts. Der letzte Schritt vor der Anmeldung ist ein vollständiger Durchgang unter denselben Einschränkungen wie am Prüfungstag.

So baust du den Durchgang auf

  • Timer auf die volle Prüfungslänge, keine Pause, kein zweites FensterDie Belastung entsteht nicht durch die einzelne Aufgabe, sondern durch die Dauer. Wer nur in 20-Minuten-Häppchen übt, merkt am Prüfungstag zum ersten Mal, wie die Konzentration nachlässt.
  • Nur die offizielle Kubernetes-Dokumentation als QuelleIm Prüfungsbrowser gibt es keinen Blogartikel und keinen Assistenten. Wer beim Üben etwas anderes benutzt, trainiert einen Griff, den er in der Prüfung nicht hat.
  • Überspringen aktiv üben und Aufgaben markierenDie Aufgaben sind unterschiedlich gewichtet. Wer sich an einer schweren festbeißt, verliert die billigen Punkte am Ende der Liste. Notier dir die Nummer und geh weiter.
  • Jede Lösung mit einem Befehl belegenEin kubectl get oder auth can-i nach jeder Aufgabe kostet Sekunden und fängt genau die Fehler ab, die dich sonst die ganze Aufgabe kosten: falscher Namespace, falscher Host, Tippfehler im Label.
  • Nach jedem Durchgang notieren, welcher Befehl gefehlt hatDiese Notizen sind nach zwei Wochen deine persönliche Kurzreferenz, und sie ist kürzer als jede fertige Übersicht aus dem Netz, weil nur deine Lücken darin stehen.
Standortbestimmung

Bist du schon prüfungsreif?

Bevor du Geld und Urlaubstage in eine Prüfung steckst, finde in wenigen Minuten heraus, wo du wirklich stehst. Der Test ist kostenlos, braucht keine Anmeldung und erklärt jede Antwort.

Aus unseren Kursen

Was Teilnehmende über unsere IT-Kurse sagen

Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.
Rückmeldung aus dem Kurs „SUSE Linux Enterprise 15 High Availability Deployment – HAE311v15“
Gut zu wissen

Häufige Fragen zu Kubernetes-Zertifizierungen

Ist deine Frage nicht dabei? Ruf an oder schreib uns, du sprichst direkt mit jemandem aus der Kursberatung.

Frag uns direkt
Was ist der Unterschied zwischen CKA und CKAD?
Der CKA prüft den Betrieb des Clusters, also Installation und Upgrades mit kubeadm, Helm und Kustomize, RBAC, Storage, Netzwerk mit Gateway API und Troubleshooting der Control Plane. Der CKAD prüft die Sicht der Anwendungsentwicklung, also Deployments, Konfiguration über ConfigMaps und Secrets, Probes, Ressourcen, Services und das Debugging einzelner Workloads. Wenn du Cluster verantwortest, ist der CKA richtig, wenn du Anwendungen auf einem bestehenden Cluster betreibst, der CKAD.
Brauche ich für den CKS zwingend den CKA?
Ja. Die Linux Foundation verlangt, dass du die CKA bestanden hast, bevor du den Certified Kubernetes Security Specialist ablegst. Ob die CKA am Prüfungstag noch gültig sein muss, prüfst du vor der Anmeldung in den aktuellen Bedingungen. Inhaltlich ist das sinnvoll, weil der CKS auf Cluster-Kenntnissen aufbaut und Themen wie Admission Control, NetworkPolicies oder Audit-Logging ohne Betriebswissen kaum zu bearbeiten sind.
Wie läuft die Prüfung ab?
Alle drei Examen sind reine Praxisprüfungen, die online und beaufsichtigt in einer Browser-Terminalumgebung stattfinden. Jede Prüfung dauert zwei Stunden, du wechselst per SSH zwischen den Clustern der einzelnen Aufgaben und darfst währenddessen die offizielle Kubernetes-Dokumentation aufrufen. Bestanden hast du mit 66 Prozent bei CKA und CKAD und mit 67 Prozent bei der CKS. Im Prüfungspreis sind ein Wiederholungsversuch und zwei Sitzungen im Prüfungssimulator enthalten.
Wie lange ist eine Kubernetes-Zertifizierung gültig?
Seit April 2024 erworbene Zertifikate laufen nach zwei Jahren ab, ältere galten noch drei Jahre. Danach erneuerst du sie durch eine erneute Prüfung. Prüfe die aktuellen Bedingungen und Fristen vor der Buchung direkt bei der Linux Foundation, da sich Gültigkeitsdauer und Prüfungsformat gelegentlich ändern.
Lohnt sich eine Kubernetes-Zertifizierung überhaupt?
Sie ersetzt keine Betriebserfahrung, belegt aber überprüfbar, dass du unter Zeitdruck an einem echten Cluster arbeiten kannst, und das unterscheidet sie von reinen Wissenstests. Für Ausschreibungen, Partnerstatus und interne Rollenwechsel ist der Nachweis oft gefordert. Wenn du dagegen nur einzelne Anwendungen deployst und kein Cluster verantwortest, reicht häufig ein Kubernetes Grundkurs ohne Zertifizierung.

Zuletzt geprüft am 05. Oktober 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick

Passt thematisch dazu

Läuft euer Cluster auf AWS, lohnt neben dem Kubernetes-Nachweis ein Blick darauf, wie die AWS-Prüfungen von Practitioner bis Professional nach Rolle, Dauer und Preis auseinandergehen.

Betreibt ihr die Plattform bei einem der großen Anbieter, ergänzt oft ein Cloud-Nachweis die Kubernetes-Prüfung, und welche Schiene dazu passt, zeigt der Überblick über die DevOps-Zertifizierungen der Cloud-Anbieter .

Aus einem anderen Bereich von cmt: Geförderte Weiterbildung: bis zu 100 % Förderung

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Unsicher, welches Examen zu deinem Team passt?

Sag uns, womit ihr arbeitet und wer zertifiziert werden soll, dann ordnen wir CKA, CKAD und CKS für eure Situation ein und schlagen den passenden Vorbereitungskurs vor. Alle Kubernetes-Trainings bei cmt finden Live-Online oder als Inhouse-Termin statt, auf Wunsch mit Prüfungsgutschein.