Guide complet CKAD — CNCF

Certified Kubernetes Application Developer · Programme, plan de révision, ressources, examen blanc gratuit.

TL;DR — Le guide en 1 minute

Le CKAD (Certified Kubernetes Application Developer) valide les competences pour concevoir, deployer et exploiter des applications cloud-native sur Kubernetes. Cette certification CNCF de niveau associate s'adresse aux developpeurs, DevOps et SRE. Format : examen pratique 100% hands-on de 2h avec acces terminal reel sur cluster K8s. Aucun prerequis formel, mais experience Docker et YAML indispensable. Debouches : Kubernetes Developer, Cloud Engineer, Platform Engineer, SRE. Tarif 2026 : 445 USD avec une seconde tentative incluse. Validite 2 ans.

Pourquoi passer la certification CKAD ?

En 2026, Kubernetes est devenu le standard de facto pour l'orchestration de conteneurs : plus de 96% des entreprises du Fortune 500 l'utilisent en production selon la CNCF Annual Survey. La certification CKAD est l'une des plus demandees sur LinkedIn (+78% d'offres mentionnant CKAD entre 2024 et 2026). Contrairement aux certifications QCM, le CKAD est 100% pratique : vous prouvez votre capacite a deployer reellement des applications, ce qui rassure fortement les recruteurs. Le ROI est excellent : un developpeur certifie CKAD voit en moyenne son salaire augmenter de 15 a 25% selon l'etude Stack Overflow Developer Survey 2026. La valorisation CV est immediate car la certification est editee par la Linux Foundation et la CNCF, references mondiales reconnues. Avec l'explosion des architectures microservices, du serverless via Knative et de l'IA cloud-native, maitriser Kubernetes cote application est devenu non negociable. Le CKAD est aussi une porte d'entree vers le CKA (administration) et le CKS (securite), formant un triptyque tres recherche. Les ESN francaises (Capgemini, Sopra, Atos) et les scale-ups (Doctolib, Back Market, Qonto) priorisent les profils CKAD pour leurs equipes plateforme.

Caractéristiques de l'examen

Format	Examen pratique hands-on, 15-20 taches sur clusters reels
Duree	120 minutes
Score requis	66%
Prix officiel	445 USD (environ 410 EUR), une retake gratuite incluse
Langues	Anglais (interface), examen technique universel
Validite	2 ans
Prerequis	Aucun officiel ; experience Docker, YAML et ligne de commande Linux fortement recommandee

Programme détaillé par domaine

Domain 1 : Application Design and Build 20%

Objectifs: Ce domaine couvre la conception et la construction d'applications conteneurisees pretes pour Kubernetes. Le candidat doit savoir definir, construire et modifier des images de conteneurs avec Docker ou Podman, comprendre les bonnes pratiques de dimensionnement et de securite des images (multi-stage builds, images minimales type distroless). Il doit egalement maitriser les workloads Kubernetes specifiques au build d'applications : Jobs et CronJobs pour les traitements batch, init containers pour la preparation d'environnement, multi-container pods avec les patterns sidecar, ambassador et adapter. La gestion des volumes persistants (PV, PVC, StorageClass) pour les donnees applicatives est egalement evaluee.
Concepts clés: Dockerfile optimise (couches, cache, multi-stage), patterns multi-container (sidecar pour logs, ambassador pour proxy, adapter pour normalisation), Jobs avec completions et parallelism, CronJobs avec syntaxe cron et concurrencyPolicy, init containers et sequencement, persistent volumes avec modes d'acces (ReadWriteOnce, ReadWriteMany, ReadOnlyMany), StorageClass dynamique, reclaimPolicy (Retain, Delete, Recycle), volumeMounts et subPath. Comprendre les emptyDir pour les caches ephemeres et hostPath pour les acces noeud.
Services / outils: Outils : docker build, buildah, kaniko pour les builds in-cluster, podman. Ressources Kubernetes : Pod, Job, CronJob, PersistentVolume, PersistentVolumeClaim, StorageClass. CLI : kubectl create job, kubectl explain, kubectl apply.
Temps estimé: 12-15h

Domain 2 : Application Deployment 20%

Objectifs: Ce domaine se concentre sur le deploiement, la mise a l'echelle et la mise a jour d'applications. Le candidat doit maitriser les Deployments avec leurs strategies (RollingUpdate, Recreate), gerer les rollouts, rollbacks et historique de revisions. La connaissance des outils de templating comme Helm et Kustomize est essentielle pour gerer plusieurs environnements (dev, staging, prod). L'autoscaling avec HorizontalPodAutoscaler (HPA) base sur CPU, memoire ou metriques custom est evalue. Les concepts de blue/green et canary deployments via services ou outils GitOps (Argo CD, Flux) font partie du perimetre.
Concepts clés: Deployment avec replicas, selector, strategy (maxSurge, maxUnavailable), kubectl rollout (status, history, undo, restart), Helm charts (values.yaml, templates, releases, repositories), Kustomize (bases, overlays, patches strategic merge), HPA avec metrics-server, ReplicaSet sous-jacent, DaemonSet pour agents par noeud, StatefulSet pour applications stateful avec identite stable.
Services / outils: Helm 3, Kustomize integre a kubectl, Argo CD, Flux CD, kubectl rollout, kubectl scale, kubectl autoscale, metrics-server. Comprendre les manifests YAML versus templating dynamique.
Temps estimé: 10-12h

Domain 3 : Application Observability and Maintenance 15%

Objectifs: Ce domaine evalue la capacite a observer, debugger et maintenir des applications en production. Le candidat doit configurer les probes de sante (liveness, readiness, startup) qui conditionnent la disponibilite et le routage du trafic. Il doit maitriser les commandes de debug : kubectl logs (avec --previous, --tail, --follow), kubectl describe, kubectl exec, kubectl events. La comprehension des versions d'API Kubernetes deprecated et de leur migration est egalement attendue. L'utilisation de kubectl debug pour les ephemeral containers fait desormais partie du programme officiel 2026.
Concepts clés: Probes : livenessProbe (redemarre le conteneur), readinessProbe (retire du service), startupProbe (pour applications lentes), avec httpGet, tcpSocket, exec. Logs (stdout/stderr captures), events Kubernetes, ephemeral containers via kubectl debug, kubectl top pods/nodes. Versions API : v1, apps/v1, batch/v1, gestion des deprecations.
Services / outils: kubectl logs, kubectl describe, kubectl exec, kubectl debug, kubectl top, kubectl events, metrics-server, conditions de Pod, statut et phases (Pending, Running, Succeeded, Failed, Unknown).
Temps estimé: 8-10h

Domain 4 : Application Environment, Configuration and Security 25%

Objectifs: Domaine le plus important en ponderation. Il couvre la configuration externalisee, la securite et l'isolation. Le candidat doit utiliser ConfigMaps et Secrets pour injecter configuration et donnees sensibles (variables d'environnement, volumes montes). La maitrise du RBAC (Roles, RoleBindings, ClusterRoles, ServiceAccounts) est centrale. Les SecurityContext (runAsUser, fsGroup, capabilities, readOnlyRootFilesystem) et les ressources de quota (ResourceQuota, LimitRange) doivent etre maitrises. Les Custom Resource Definitions (CRD) et Operators sont egalement abordes au niveau utilisation.
Concepts clés: ConfigMap (envFrom, valueFrom, volumeMount), Secret (Opaque, dockerconfigjson, tls), encodage base64, ServiceAccount avec token automount, RBAC (verbs : get, list, watch, create, update, patch, delete), SecurityContext au niveau pod et conteneur, capabilities Linux (NET_ADMIN, SYS_TIME), ResourceQuota (limits.cpu, requests.memory), LimitRange par defaut, CRD et apiextensions.k8s.io.
Services / outils: ConfigMap, Secret, ServiceAccount, Role, RoleBinding, ClusterRole, ClusterRoleBinding, ResourceQuota, LimitRange, NetworkPolicy. Outils : kubectl auth can-i, kubectl create secret, sealed-secrets, external-secrets-operator.
Temps estimé: 15-18h

Domain 5 : Services and Networking 20%

Objectifs: Ce domaine couvre l'exposition des applications et la securisation reseau. Le candidat doit creer des Services (ClusterIP, NodePort, LoadBalancer, ExternalName) et comprendre le DNS interne Kubernetes (CoreDNS). La configuration d'Ingress avec regles host/path et TLS termination est evaluee, ainsi que la nouvelle Gateway API qui remplace progressivement Ingress en 2026. Les NetworkPolicies pour l'isolation reseau (ingress et egress) avec selecteurs de pods et namespaces sont centrales pour la securite zero-trust.
Concepts clés: Service types et selectors, endpoints, kube-proxy (iptables/IPVS), DNS pod (<service>.<namespace>.svc.cluster.local), Ingress avec ingressClassName, Gateway API (GatewayClass, Gateway, HTTPRoute), NetworkPolicy avec podSelector, namespaceSelector, ipBlock, ports. CNI plugins (Calico, Cilium) en contexte.
Services / outils: Service, Endpoints, EndpointSlice, Ingress, IngressClass, Gateway, HTTPRoute, NetworkPolicy, CoreDNS. Outils : kubectl expose, kubectl port-forward, nslookup depuis un pod debug.
Temps estimé: 10-12h

Plan de révision hebdomadaire

Plan de revision sur 8 semaines a raison de 8-10h/semaine, total ~70h. Semaine 1 : Fondamentaux Kubernetes via la documentation officielle kubernetes.io (architecture, objets de base), installation de minikube ou kind en local, premiers kubectl run et kubectl apply. Lecture du Curriculum officiel CKAD v1.32 sur GitHub CNCF. Semaine 2 : Domain 1 (Application Design). Construction d'images Docker optimisees, deploiement de Jobs et CronJobs, exercices sur multi-container patterns. Lab : creer un sidecar de log shipping. Semaine 3 : Domain 2 (Deployment). Strategies de rollout, manipulation Helm 3 (creation d'un chart from scratch), Kustomize overlays. Lab : pipeline de deploiement multi-environnements. Semaine 4 : Domain 3 (Observability). Probes liveness/readiness/startup, debug avec kubectl debug et ephemeral containers, analyse de logs. Lab : diagnostiquer un pod en CrashLoopBackOff. Semaine 5 : Domain 4 (Security & Config) - partie 1. ConfigMaps, Secrets, ServiceAccounts, RBAC complet avec exercices kubectl auth can-i. Semaine 6 : Domain 4 partie 2 et Domain 5. SecurityContext, ResourceQuota, Services, Ingress, NetworkPolicies avec scenarios zero-trust. Lab : isoler un namespace en deny-all puis autoriser specifiquement. Semaine 7 : Examens blancs sur Killer.sh (inclus avec l'inscription) et KodeKloud CKAD Mock. Chronometrage strict 2h. Identifier les domaines faibles. Semaine 8 : Revision ciblee des faiblesses, maitrise des alias kubectl (export do='--dry-run=client -o yaml'), pratique vim/vi rapide, raccourcis bash. Passage de l'examen en fin de semaine 8.

Besoin d'un planning sur mesure ? 30 jours · 60 jours · 90 jours

Ressources recommandées

Documentation officielle Kubernetes

Reference unique autorisee pendant l'examen. A connaitre parfaitement pour naviguer rapidement (concepts, tasks, reference).

CKAD Curriculum officiel CNCF

Programme detaille version 1.32 avec ponderation par domaine. Document fondateur a relire avant l'examen.

KodeKloud CKAD Course

Cours video complet avec labs integres dans le navigateur, scenarios chronometres et examens blancs realistes.

Killer.sh CKAD Simulator

Simulateur officiel offert avec l'inscription a l'examen. Deux sessions de 36h chacune, niveau plus difficile que l'examen reel.

Communaute Kubernetes Slack

Canal #ckad-exam-prep pour echanger avec d'autres candidats et formateurs CNCF certifies.

5 erreurs classiques à éviter

Erreur 1 : Negliger la vitesse de frappe et les alias kubectl. Solution : configurer alias k=kubectl, export do='--dry-run=client -o yaml', export now='--grace-period=0 --force' des le debut de l'examen.
Erreur 2 : Ecrire les YAML from scratch. Solution : toujours generer un squelette avec kubectl create ... --dry-run=client -o yaml > fichier.yaml puis editer, gain de temps massif.
Erreur 3 : Oublier de changer de namespace via kubectl config set-context --current --namespace=XXX au debut de chaque question. Beaucoup d'echecs viennent de ressources creees dans le mauvais namespace.
Erreur 4 : Mal gerer le temps : 120 minutes pour 15-20 taches, soit ~7 minutes par tache. Solution : skipper immediatement les questions difficiles avec flag, revenir a la fin. Ne jamais bloquer plus de 10 minutes sur une question.
Erreur 5 : Ne pas verifier ses solutions. Toujours kubectl get et kubectl describe la ressource creee, et tester avec kubectl exec ou kubectl logs que l'application repond reellement.

5 questions types corrigées

Q1. Vous devez creer un Pod nomme 'web' qui execute l'image nginx:1.25 et qui doit etre marque comme non pret tant qu'un fichier /tmp/ready n'existe pas. Quelle configuration utiliser ?

Réponse : B

La readinessProbe controle si un Pod doit recevoir du trafic via les Services. Tant que la probe echoue, le Pod est retire des endpoints sans etre redemarre. La livenessProbe (A) redemarrerait le conteneur en boucle, ce qui n'est pas le but. La startupProbe (C) sert uniquement pendant le demarrage initial et httpGet ne verifie pas un fichier. Un initContainer (D) bloquerait le demarrage du Pod entier. La syntaxe correcte utilise exec.command: ['cat', '/tmp/ready'] avec periodSeconds adapte.

Q2. Vous devez accorder a un ServiceAccount 'ci-bot' dans le namespace 'build' le droit de lister et creer des Pods uniquement dans ce namespace. Quelle combinaison appliquer ?

Réponse : B

Pour un acces limite a un namespace, la solution canonique est Role + RoleBinding tous deux dans ce namespace. Le Role definit les verbs (list, create) sur la resource pods. Le RoleBinding lie le ServiceAccount au Role. L'option C est valide techniquement (un ClusterRole reutilisable lie via RoleBinding) mais cree une ressource cluster-wide non necessaire. L'option A donnerait un acces a tous les namespaces. L'option D est invalide car un ClusterRoleBinding ne peut pas referencer un Role namespace.

Q3. Quelle commande genere rapidement le YAML d'un Deployment nginx avec 3 replicas sans le creer ?

Réponse : B

La commande kubectl create deployment avec --dry-run=client -o yaml est la methode officielle pour generer un manifest sans appliquer au cluster. C'est un reflexe indispensable pour gagner du temps a l'examen. L'option A cree un Pod (kubectl run) et ne supporte plus --replicas depuis K8s 1.18. L'option C utilise une syntaxe invalide : apply ne prend pas de sous-commande deployment. L'option D n'existe pas. Combiner cette commande avec un redirect > deploy.yaml puis editer le fichier est la pratique standard CKAD.

Voir plus de questions gratuites →

Carrière & salaire après CKAD

Le CKAD ouvre des postes tres recherches en 2026 : Kubernetes Developer (50-70k EUR junior, 75-95k EUR senior en France), Platform Engineer (65-95k EUR), Cloud Native Developer (60-85k EUR), SRE junior (55-80k EUR). A Paris et en region parisienne, les salaires sont 15-20% superieurs, et au Luxembourg ou en Suisse les packages atteignent 110-140k EUR. Les ESN (Capgemini, Devoteam, Octo Technology) et les editeurs SaaS recrutent massivement. Evolutions naturelles : Senior Platform Engineer, Tech Lead Cloud, Architecte Kubernetes (100-140k EUR). Certifications complementaires fortement recommandees : CKA (Certified Kubernetes Administrator) pour la dimension ops, CKS (Certified Kubernetes Security Specialist) pour la securite, puis specialisations cloud (AWS Solutions Architect, Azure AKS, Google GKE). Le combo CKAD + CKA + une cert cloud majeure est le profil ideal recherche par les scale-ups et grands comptes en transformation cloud-native.

Détail des salaires CKAD en 2026 →

FAQ — CKAD

Combien de temps faut-il pour preparer CKAD ?

Comptez 60 a 80 heures de preparation sur 6 a 10 semaines pour un developpeur ayant deja une experience Docker. Sans experience conteneurs, prevoyez 100-120 heures sur 3 mois. La pratique intensive en lab est plus importante que la theorie.

Cette certification est-elle reconnue en France ?

Oui, totalement. Editee par la Linux Foundation et la CNCF, elle figure systematiquement dans les offres d'emploi des grandes ESN francaises (Capgemini, Sopra Steria, Atos), des banques (BNP, Societe Generale) et des scale-ups (Doctolib, Back Market, Qonto, BlaBlaCar).

Quel est le taux de reussite a CKAD ?

Le taux de reussite officiel n'est pas publie par la CNCF, mais les estimations communautaires situent la reussite a la premiere tentative entre 60 et 70%. Avec la retake gratuite incluse, le taux global de certification depasse 85%.

Quel est le salaire apres CKAD ?

En France 2026 : 50-70k EUR pour un profil junior (1-3 ans), 75-95k EUR pour un senior (5+ ans). A Paris, comptez +15%. Au Luxembourg ou en Suisse, 110-140k EUR. Le CKAD ajoute typiquement 8-15% au salaire de base d'un developpeur.

Faut-il une experience prealable ?

Aucun prerequis officiel, mais une experience pratique Docker, YAML et ligne de commande Linux est indispensable. Connaitre les concepts de microservices et API REST aide enormement. Sans cela, le format hands-on chronometree est tres difficile.

CKAD ou cert concurrente : laquelle choisir ?

CKAD se distingue par son format 100% pratique, contrairement aux certifications QCM. Si vous etes developpeur, choisissez CKAD. Pour l'administration cluster, prenez CKA. Les certifications cloud (AWS, Azure, GCP Kubernetes) sont complementaires mais vendor-specific.

Combien coute l'examen CKAD ?

445 USD en 2026, soit environ 410 EUR, incluant une seconde tentative gratuite si echec. Des codes promo CNCF (KubeCon, Black Friday, Cyber Monday) offrent regulierement 30-40% de reduction. La Linux Foundation propose aussi des bundles CKAD+cours a tarif reduit.

Combien de fois peut-on repasser CKAD ?

L'inscription inclut une tentative initiale plus une retake gratuite, soit deux essais. Au-dela, il faut racheter une nouvelle inscription complete. Il n'y a pas de limite au nombre total de tentatives ni de delai d'attente minimum entre les essais.

Prêt à passer à la pratique ?

Lancez votre examen blanc gratuit ou faites le test d'orientation pour valider votre choix.

Démarrer l'examen blanc CKAD → Test d'orientation