CKA-Vorbereitung und typische Fragen

Lernziele

Nach dieser Lektion weißt du, was die CKA-Prüfung tatsächlich testet und wie du dich auf ihr Format — praktische Aufgaben am echten Cluster unter Zeitdruck — gezielt vorbereitest. Du beherrschst die imperative kubectl-Arbeitsweise mit --dry-run=client -o yaml und kubectl explain, kennst die Aufgabentypen, die fast immer drankommen, und hast einen Plan, wie du Kubernetes-Interviews vom 60-Sekunden-Pitch bis zum Live-Troubleshooting bestreitest.

Das Format verstehen: ein Terminal, ein Timer, echte Cluster

Die CKA (Certified Kubernetes Administrator) ist kein Multiple-Choice-Test. Du sitzt vor einem Remote-Terminal mit mehreren echten Clustern und löst in zwei Stunden praktische Aufgaben: Deployments reparieren, RBAC aufsetzen, Nodes warten, Storage anbinden, Netzwerkprobleme finden. Bewertet wird das Ergebnis im Cluster — der Weg dorthin ist egal. Die Kubernetes-Dokumentation ist während der Prüfung erlaubt und über den Browser erreichbar.

Daraus folgt die wichtigste Erkenntnis: Die CKA testet nicht, ob du Konzepte erklären kannst, sondern ob deine Hände schnell genug sind. Wer für jedes Manifest fünf Minuten YAML tippt, scheitert an der Uhr, nicht am Wissen. Trainingsziel ist Geläufigkeit: dieselben Handgriffe wiederholen, bis sie automatisch ablaufen. Genau das macht die CKA-Vorbereitung auch für Interviews wertvoll — Live-Debugging vor Publikum gelingt nur mit eingeschliffenen Abläufen.

Zwei Format-Details retten Punkte: Jede Aufgabe nennt den zu verwendenden Kontext (kubectl config use-context …) — wer das überliest, arbeitet im falschen Cluster. Und die Aufgaben sind unabhängig: Festbeißen an einer schweren kostet die drei leichten danach. Markieren, weitergehen, am Ende zurückkommen.

Imperativ statt YAML-Tippen: der Geschwindigkeits-Stack

Kern der Prüfungstechnik sind imperative kubectl-Befehle als YAML-Generatoren. Statt ein Deployment-Manifest aus dem Kopf zu schreiben, lässt du kubectl es erzeugen:

kubectl create deployment web --image=nginx --replicas=3 \
  --dry-run=client -o yaml > deploy.yaml

--dry-run=client -o yaml ist der wichtigste Flag-Verbund der Prüfung: nichts wird angelegt, aber du bekommst ein korrektes Manifest-Skelett, das du nur noch um die geforderten Details ergänzt (Ressourcen, Volumes, Affinity). Das funktioniert für fast alles: kubectl run für Pods, kubectl create service/configmap/secret/role/rolebinding/cronjob, kubectl expose für Services zu bestehenden Workloads.

Wenn du ein Feld nicht auswendig weißt, ist kubectl explain schneller als die Browser-Doku: kubectl explain pod.spec.affinity.nodeAffinity --recursive zeigt dir die exakte Feldstruktur samt Typen direkt im Terminal — kein Tab-Wechsel, kein Suchen.

Dazu das Tempo-Setup, das du dir vor der Prüfung antrainierst (alias k=kubectl ist in der Prüfungsumgebung üblicherweise eingerichtet): die Kurzformen po, svc, deploy, ns, no, cm, pvc; den Namespace per kubectl config set-context --current --namespace=<ns> fixieren; und für Änderungen an Bestehendem kubectl edit, set image, scale, label statt YAML-Roundtrip.

Die Aufgabenklassiker — und was sie wirklich prüfen

Über die Prüfungsversionen hinweg stabil sind diese Aufgabenfamilien, die du alle in diesem Pfad gelernt hast:

RBAC aufsetzen (Lektion 18): ServiceAccount, Role, RoleBinding anlegen — komplett imperativ machbar (kubectl create role … --verb=… --resource=…), mit kubectl auth can-i --as=… verifizierbar. Geprüft wird, ob du die Objektkette und das Subject-Format sicher hast.

NetworkPolicy schreiben (Lektion 13): Hier hilft kein Generator — Policies musst du als YAML können. Lerne das Default-Deny-Muster und eine Allow-Policy mit pod- und namespaceSelector auswendig; der Rest sind Varianten. Geprüft wird Selektor-Logik: wer ist selektiert, welche Richtung, UND vs. ODER in der from-Liste.

PV/PVC und Storage (Lektion 15): PVC an StorageClass binden, Pod mit Volume-Mount, Access Modes korrekt wählen. Geprüft wird, ob du die Bindungskette PVC → PV → Mount fehlerfrei baust und Pending-Zustände deuten kannst.

Troubleshooting (Lektionen 14 und 19): Ein kaputter Pod, ein Node NotReady, ein Service ohne Antwort — finde und behebe es. Das ist der größte Prüfungsblock und der, der am meisten Interview-Transfer hat: describe → Events → logs —previous → gezielter Fix. Auch Node-Wartung gehört hierher: kubectl cordon, kubectl drain --ignore-daemonsets, danach uncordon.

Trainiere diese Familien szenarienweise: Cluster mit kind aufsetzen, Aufgabe stellen (oder von Übungsplattformen wie killer.sh nehmen — der Simulator ist im Prüfungspreis enthalten), Timer auf 6–8 Minuten, lösen, verifizieren.

Vom Zertifikat zum Interview: Wissen in Antworten verwandeln

Interviews prüfen dieselben Themen erklärend statt ausführend. Drei Frageformate solltest du vorbereitet haben.

Der 60–90-Sekunden-Pitch („Erkläre Kubernetes-Networking / Storage / RBAC”): Nimm die Problem-zuerst-Struktur jeder Lektion dieses Pfads — Problem in einem Satz, Mechanismus in zwei, drei Sätzen, eine Grenze oder ein Trade-off zum Schluss. Das Schema trägt durch jedes Thema, und die Zusammenfassungen der Lektionen 11–19 sind deine Pitch-Vorlagen.

Das Live-Troubleshooting („Hier ist ein Cluster, der Service antwortet nicht”): Hier zahlt sich CKA-Training direkt aus. Entscheidend ist lautes Denken: Hypothese nennen, Befehl ausführen, Ergebnis interpretieren, nächste Hypothese. Schweigendes Tippen ist die häufigste vermeidbare Schwäche in solchen Runden — der Interviewer bewertet deinen Diagnosepfad, nicht dein Endergebnis.

Die Design-Frage („Wie würdest du Multi-Team-Zugriff / Storage / Ingress aufbauen?”): Anforderungen kurz klären, dann die Primitives aus diesem Pfad kombinieren — Namespaces + RBAC + NetworkPolicies für Tenancy, StorageClasses + Reclaim Policies für Daten, Gateway API für rollengetrennten Traffic — und pro Entscheidung einen Trade-off nennen. Tiefe schlägt Breite: ein Thema sauber durchdacht überzeugt mehr als zehn Buzzwords.

Praxis

Ein Timeboxing-Drill, der Prüfung und Interview gleichzeitig trainiert — Timer stellen, 25 Minuten für alle vier Aufgaben:

kind create cluster

# Aufgabe 1 (5 min): Deployment "api", nginx, 3 Replicas, Service ClusterIP Port 80
kubectl create deployment api --image=nginx --replicas=3
kubectl expose deployment api --port=80
kubectl get endpointslices -l kubernetes.io/service-name=api  # verifizieren!

# Aufgabe 2 (6 min): ServiceAccount "ci" in Namespace "build" darf Deployments
# lesen und skalieren
kubectl create namespace build
kubectl create serviceaccount ci -n build
kubectl create role deploy-operator -n build \
  --verb=get,list,watch,patch --resource=deployments
kubectl create rolebinding ci-binding -n build \
  --role=deploy-operator --serviceaccount=build:ci
kubectl auth can-i patch deployments -n build \
  --as=system:serviceaccount:build:ci              # yes?

# Aufgabe 3 (6 min): Pod mit PVC (1Gi, RWO, Default-StorageClass) unter /data
kubectl create -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata: {name: data}
spec:
  accessModes: ["ReadWriteOnce"]
  resources: {requests: {storage: 1Gi}}
EOF
kubectl run app --image=nginx --dry-run=client -o yaml > pod.yaml
# pod.yaml editieren: volume + volumeMount ergänzen, dann:
kubectl apply -f pod.yaml && kubectl get pvc data   # Bound?

# Aufgabe 4 (8 min): Node-Wartung simulieren
kubectl drain kind-control-plane --ignore-daemonsets --delete-emptydir-data
kubectl get pods -o wide    # wohin sind die Pods? (Single-Node: Pending — warum?)
kubectl uncordon kind-control-plane

Zwei Gewohnheiten mittrainieren: jede Aufgabe mit einem Verifikationsbefehl abschließen (in der CKA zählt nur der Cluster-Zustand) und nach Ablauf der Timebox konsequent zur nächsten Aufgabe springen.

Typische Stolperfallen

YAML von Hand statt generieren: Wer Manifeste tippt, verliert pro Aufgabe Minuten und produziert Einrückungsfehler. --dry-run=client -o yaml plus gezieltes Editieren ist immer schneller.

Kontext und Namespace ignoriert: Aufgabe im falschen Cluster oder falschen Namespace gelöst = null Punkte trotz korrekter Arbeit. Kontext-Wechsel-Befehl ist immer der erste Befehl jeder Aufgabe.

Nicht verifiziert: Ein Tippfehler im Label, und der Service hat keine Endpoints — wer nach dem Anlegen nicht prüft, gibt funktionslose Lösungen ab. Jede Aufgabe endet mit einem Check.

Im Interview Zertifikat statt Verständnis anbieten: „Ich bin CKA-zertifiziert” beantwortet keine Frage. Interviewer haken nach Mechanismen — wer den Stoff nur für die Prüfung gepaukt hat, fliegt beim zweiten Follow-up auf. Die Konzept-Lektionen dieses Pfads sind das Fundament, die CKA-Technik der Geschwindigkeits-Aufsatz.

Interview-Vorbereitung

Auf die Meta-Frage „Wie hast du dich auf Kubernetes vorbereitet?” ist die stärkste Antwort eine Kombination: Konzepte verstanden (Pfad-Themen mit Problem-Mechanismus-Trade-off erklären können), Hände trainiert (Lab-Cluster, CKA-Drills, Troubleshooting-Szenarien), und beides an realistischen Aufgaben zusammengeführt. Nenne konkret, was du in Labs gebaut und kaputtgemacht hast — das ist glaubwürdiger als jede Zertifikatsliste.

Typische Follow-ups aus dem Schlussbereich von Kubernetes-Interviews:

• „Dein Vorgehen bei einem Pod in CrashLoopBackOff?” — describe für Events und Last State, logs --previous für die Absturzursache, Probe-Konfiguration prüfen; Fix je nach Befund (Lektion 19).
• „Service erreichbar machen — welche Optionen?” — ClusterIP intern, NodePort roh, LoadBalancer pro Service, Ingress/Gateway API für HTTP-Routing mit TLS (Lektionen 11–12).
• „Wie isolierst du zwei Teams im selben Cluster?” — Namespaces als Grenze, RBAC für API-Zugriff, NetworkPolicies für Traffic, ResourceQuotas gegen Ressourcen-Verdrängung (Lektionen 13, 17, 18).
• „Wo liegen die Grenzen von Kubernetes?” — Ehrlich bleiben: hohe Betriebskomplexität, kein fertiges Multi-Tenancy-Modell, Stateful-Workloads brauchen Sorgfalt — und vieles (Ingress-Controller, CNI, Storage) sind Entscheidungen, die der Cluster dir nicht abnimmt.

Zusammenfassung

Die CKA prüft Handwerk unter Zeitdruck: imperative Befehle mit --dry-run=client -o yaml als Manifest-Generator, kubectl explain statt Doku-Suche, Kurzformen und Namespace-Disziplin, Verifikation nach jeder Aufgabe — trainiert in Timeboxen an den Klassikern RBAC, NetworkPolicy, PV/PVC und Troubleshooting. Interviews prüfen dieselben Themen erklärend: Problem-zuerst-Pitches, lautes Denken beim Live-Debugging, Trade-offs bei Design-Fragen.

Damit ist der Kubernetes-Pfad komplett: von Architektur und Workloads über Networking, Storage, Scheduling und Security bis zu Methodik und Prüfungsform. Was jetzt zählt, ist Wiederholung im Lab — jedes Thema dieses Pfads ist eine Übungsstunde mit kind, und jede dieser Stunden zahlt direkt auf Prüfung, Interview und den ersten Arbeitstag als Platform Engineer ein.