Certification KCNA : le programme, l'examen et un quiz pour réviser

Presque la moitié de l'examen, et de loin le domaine qui décide de votre résultat. Il couvre l'architecture du cluster - control plane, nœuds, le fait que tout passe par l'API server et que lui seul parle à etcd - puis les objets que vous manipulez tous les jours : pods, Deployments, ReplicaSets, DaemonSets, Jobs.

Scheduling y est une compétence à part entière, et c'est là que beaucoup de candidats se font avoir : il ne suffit pas de savoir qu'un scheduler existe. Il faut savoir ce que sont requests et limits, en quoi la réservation choisit la machine et le plafond la protège, et pourquoi une taint repousse un pod qui n'a pas la toleration correspondante.

Containerization remonte d'un cran en amont : ce qu'est réellement une image OCI, ce que fait un runtime conforme à CRI, et pourquoi le retrait de l'adaptateur Docker en 1.24 n'a rien changé à vos images. La question « Docker est-il mort » tombe sous une forme ou une autre, et la réponse est non.

Si vous ne deviez réviser qu'un domaine, c'est celui-là. Quarante-quatre pour cent d'un examen à 75 % de seuil, ça veut dire qu'un naufrage ici ne se rattrape nulle part ailleurs.

Quatre compétences qui n'ont pas grand-chose à voir entre elles, réunies sous un nom un peu large : le réseau, la sécurité, le dépannage et le stockage.

Le réseau est le morceau le plus dense. Il faut savoir distinguer les types de Service (et surtout comprendre que ni ClusterIP ni NodePort ne sont des solutions d'exposition publique), ce que fait le DNS interne, et où s'arrête un Ingress. Un point d'actualité qui vaut le détour : Ingress-NGINX, le contrôleur que la plupart des tutoriels francophones font encore installer, est retiré depuis mars 2026 et ne reçoit plus de correctifs de sécurité. Gateway API est la réponse pour tout nouveau projet.

Le stockage se joue sur la chaîne PersistentVolume, PersistentVolumeClaim, StorageClass, et sur ce qui se passe quand un pod meurt : un volume emptyDir part avec lui, un PVC non.

Le dépannage est le domaine où l'expérience paie le plus. Savoir qu'un Pending veut presque toujours dire que le scheduler n'a trouvé aucun nœud, qu'un ImagePullBackOff n'est pas un problème de ressources, et qu'un code de sortie 137 signe un OOMKill, c'est trois questions gagnées sans réfléchir.

Le premier des deux domaines que le guide Kubernetes ne couvre pas, parce qu'il ne parle pas de Kubernetes mais de ce qu'on met autour pour livrer.

Application Delivery tourne autour d'une idée centrale, le GitOps : l'état désiré du cluster vit dans un dépôt Git, et un agent qui tourne dans le cluster le réconcilie en continu, au lieu d'un pipeline qui pousse des changements avec des identifiants d'administration. La conséquence pratique est ce qui tombe à l'examen : la piste d'audit est l'historique des commits, et revenir en arrière, c'est révoquer un commit. Argo CD et Flux sont les deux implémentations à connaître de nom.

Autour, le vocabulaire de la livraison progressive : déploiement bleu-vert, canari, rolling update - celui-là est natif dans un Deployment et vous le connaissez déjà. Helm apparaît comme gestionnaire de paquets, avec ses charts et ses valeurs ; les operators comme façon d'empaqueter une application qui a besoin de logique métier pour être exploitée.

Debugging recoupe en partie le dépannage du domaine précédent, mais côté application : lire des logs, comprendre ce qu'une sonde de vivacité mal réglée fait à un démarrage lent, et savoir qu'une sonde de disponibilité qui échoue retire le pod du Service sans le tuer.

Le plus petit domaine, et le plus facile à sous-estimer. C'est aussi le seul qui pose des questions auxquelles on ne peut pas répondre en réfléchissant : soit on connaît l'écosystème, soit non.

Observability a rejoint ce domaine lors de la révision de novembre 2025, après avoir été un domaine à part entière. Les trois signaux - logs, métriques, traces - et le rôle d'OpenTelemetry comme spécification qui les unifie suffisent à la plupart des questions. Prometheus pour les métriques, sa notion de série temporelle et son modèle de collecte par interrogation plutôt que par envoi.

Cloud Native Ecosystem and Principles demande de savoir ce qu'est la CNCF, ce que sont ses niveaux de maturité, et de situer une poignée de projets. Kubernetes lui-même est passé en 1.0 le 21 juillet 2015, jour où la création de la CNCF a été annoncée ; il en est le premier projet diplômé.

Cloud Native Community and Collaboration est la compétence la plus inattendue d'un examen technique : gouvernance des projets, rôle des SIG, code de conduite, façon dont on contribue. Ça paraît anecdotique, et ça ne l'est pas - c'est douze pour cent de l'examen partagés avec les deux autres, et ce sont des points qui se prennent en une soirée de lecture.