Blog

Geslaagd voor CKAD — op de derde poging

Augustus 2026 · Kubernetes, CKAD, CNCF

Ik ben geslaagd voor het praktijkexamen Certified Kubernetes Application Developer (CKAD) — op mijn derde poging. Deze post is niet alleen een terugblik, maar ook een praktische gids met het soort voorbeelden waar ik zelf houvast aan had gehad.

Wat er misging bij de eerste twee pogingen

De eerste twee keer dook ik meteen in de moeilijkste onderwerpen en sloeg ik de fundamenten over. Bij de tweede poging haalde ik 62%, terwijl 66% nodig was. Zwakke plekken: NetworkPolicies, kubectl edit-workflows, API-deprecations en vertrouwdheid met de Kubernetes-documentatie.

Wat ik deze keer anders deed

Ik zorgde dat ik Linux-processen, Linux-namespaces en de onderliggende concepten van Kubernetes écht begreep, vóórdat ik aan applicatie-scenario’s begon. Ook dacht ik meer na over hoe developers dagelijks werken — CKAD is niet voor niets hét developer-examen.

Praktijkvoorbeelden die het verschil maakten

1. Probes: weet het verschil tussen liveness, readiness en startup

Een klassieke valkuil: een liveness probe die te vroeg faalt tijdens een trage opstart, waardoor Kubernetes de container blijft herstarten. Oplossing: een startupProbe.

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: nginx:1.27
    ports:
    - containerPort: 80
    startupProbe:
      httpGet:
        path: /healthz
        port: 80
      failureThreshold: 30
      periodSeconds: 2
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      periodSeconds: 10
    readinessProbe:
      tcpSocket:
        port: 80
      periodSeconds: 5

2. Multi-container Pods: sidecar-patroon met emptyDir

Veelvoorkomend examenscenario: een applicatie-container die logs wegschrijft, en een sidecar die ze verwerkt. Ze delen een emptyDir-volume.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "while true; do echo $(date) >> /var/log/app.log; sleep 5; done"]
    volumeMounts:
    - name: log-volume
      mountPath: /var/log
  - name: log-sidecar
    image: busybox
    command: ["sh", "-c", "tail -f /var/log/app.log"]
    volumeMounts:
    - name: log-volume
      mountPath: /var/log
  volumes:
  - name: log-volume
    emptyDir: {}

3. ConfigMaps en Secrets: env vars vs. volume mounts

Belangrijk om te weten: bij een volume mount worden wijzigingen aan een ConfigMap uiteindelijk doorgevoerd in de draaiende Pod; bij env vars niet, zonder herstart.

apiVersion: v1
kind: Pod
metadata:
  name: config-demo
spec:
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "env; sleep 3600"]
    envFrom:
    - configMapRef:
        name: app-config
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secret
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: app-secret

4. NetworkPolicy: default-deny en gerichte ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Hoe ik me voorbereidde

Killer.sh voor realistische examensimulatie onder tijdsdruk, KodeKloud voor theorie met bijbehorende practice labs, en Killercoda als leuke aanvulling, soms samen met de Linux Foundation e-learnings. Alle drie de pogingen meegerekend, kostte de voorbereiding zo’n drie maanden.

Tip voor wie het examen nog moet doen

Oefen met kubectl explain en de officiële Kubernetes-documentatie tijdens je labs — dat mag tijdens het examen, en hoe vertrouwder je ermee bent, hoe sneller je iets terugvindt onder tijdsdruk.

De les

Bouw van onderop: begrijp eerst de fundamenten, en begrijp voor wie het examen eigenlijk geschreven is. Op naar de volgende certificering: CKA.

← Terug naar blog