La KCNA valide votre compréhension fondamentale de Kubernetes et de l'écosystème cloud native. C'est la certification d'entrée de la CNCF, conçue comme un tremplin vers les certifications plus avancées (KCSA, CKAD, CKA, CKS). Contrairement aux autres certifications Kubernetes, la KCNA est un examen théorique (QCM), pas de terminal, pas de cluster à manipuler. Elle teste vos connaissances, pas votre vitesse d'exécution.
Cette page est le hub de préparation KCNA. Elle vous guide à travers les domaines de l'examen, les ressources du site, et une stratégie structurée pour réussir.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Ce que valide la KCNA et pourquoi c'est le point de départ des certifications CNCF
- Le format de l'examen et les conditions de passage
- Les 4 domaines du blueprint avec leur pondération officielle
- Les concepts que vous devez maîtriser pour chaque domaine
- Comment raisonner sur les QCM pour maximiser votre score
- Un plan de préparation sur 4 semaines avec les ressources du site
Ce que la KCNA valide
Section intitulée « Ce que la KCNA valide »La KCNA (Kubernetes and Cloud Native Associate) certifie que vous comprenez les fondations de Kubernetes et de l'écosystème cloud native :
- L'architecture Kubernetes : clusters, nodes, control plane, pods, namespaces
- Les ressources fondamentales : Deployments, Services, ConfigMaps, Secrets
- L'orchestration de conteneurs : pourquoi orchestrer, scheduling, scaling, service discovery
- Le paysage cloud native : les grandes familles d'outils et quelques projets emblématiques de la CNCF
- Les principes de livraison : CI/CD, GitOps, infrastructure immuable
- Les bases de sécurité : bonnes pratiques Kubernetes, isolation, contrôle d'accès
Pourquoi passer la KCNA ?
Section intitulée « Pourquoi passer la KCNA ? »La KCNA remplit un rôle précis dans le parcours de certification CNCF. Cherchez la ligne qui correspond à votre situation, car la valeur de cette certification varie fortement selon le point de départ. Pour un profil technique déjà à l'aise avec Kubernetes, l'apport est surtout la structuration des connaissances : on découvre en révisant les zones qu'on utilisait sans les comprendre. Pour un profil non technique, c'est au contraire une preuve de compréhension obtenable sans passer par un examen en terminal.
| Situation | Ce que la KCNA vous apporte |
|---|---|
| Vous découvrez Kubernetes | Une validation structurée de vos connaissances de base |
| Vous venez de Docker | Un pont vers le cloud native au-delà des conteneurs seuls |
| Vous préparez CKA/CKAD | Un socle solide qui accélère la suite |
| Vous êtes manager ou architecte | Une preuve de compréhension sans besoin de maîtrise pratique |
| Vous changez de poste | Un signal clair sur votre CV pour des rôles cloud native |
Format de l'examen
Section intitulée « Format de l'examen »Deux lignes de ce tableau structurent toute la préparation. Le score minimum de 75 % est plus élevé que celui des examens pratiques CKA et CKAD, fixé à 66 % : la marge d'erreur est donc plus faible qu'on ne le croit. L'absence d'accès à la documentation Kubernetes est l'autre différence majeure avec les examens pratiques, où la doc reste ouverte pendant l'épreuve. Ici, tout doit être en mémoire, ce qui change la méthode de révision : comprendre ne suffit pas, il faut savoir nommer.
| Aspect | Valeur |
|---|---|
| Durée | 90 minutes |
| Type | QCM en ligne, supervisé (proctored) |
| Score minimum | 75% |
| Reprise | 1 retake inclus |
| Prix | 250 USD |
| Prérequis | Aucun |
| Documentation | Pas d'accès à la documentation Kubernetes pendant l'examen |
Les 4 domaines du blueprint
Section intitulée « Les 4 domaines du blueprint »Le blueprint officiel CNCF définit les domaines et leur pondération. Ces pourcentages ne sont pas indicatifs : ils déterminent directement combien de questions portent sur chaque thème. Concrètement, les deux premiers domaines pèsent 72 % de l'examen à eux seuls, et il est mathématiquement impossible d'atteindre les 75 % requis en les négligeant, même avec un sans-faute sur les deux autres. Répartissez votre temps de révision dans ces proportions plutôt qu'en fonction de vos préférences.
| Domaine | Poids | Ce que ça couvre |
|---|---|---|
| Kubernetes Fundamentals | 44% | Architecture, composants, ressources de base, API, kubectl |
| Container Orchestration | 28% | Scheduling, scaling, service discovery, networking, storage |
| Cloud Native Application Delivery | 16% | CI/CD, GitOps, Helm, déploiement d'applications |
| Cloud Native Architecture | 12% | Microservices, infrastructure immuable, autoscaling, serverless |
Domaine 1 : Kubernetes Fundamentals (44%)
Section intitulée « Domaine 1 : Kubernetes Fundamentals (44%) »C'est le coeur de l'examen. Vous devez comprendre comment Kubernetes fonctionne, pas seulement comment l'utiliser.
Architecture du cluster
Section intitulée « Architecture du cluster »Les questions d'examen sur ce point portent moins sur la liste des composants que sur qui fait quoi. La confusion la plus sanctionnée oppose le Scheduler, qui décide sur quel nœud placer un Pod, au Controller Manager, qui surveille l'écart entre état désiré et état réel. Retenez également que seul l'API Server parle à etcd : aucun autre composant n'y accède directement, et c'est un point de question fréquent.
- Le control plane : API Server, etcd, Scheduler, Controller Manager
- Les worker nodes : kubelet, kube-proxy, container runtime
- Le rôle de chaque composant et comment ils communiquent
Ressources fondamentales
Section intitulée « Ressources fondamentales »Pour chacune de ces ressources, sachez répondre à deux questions : quel problème elle résout, et quelle ressource elle remplace ou complète. Un Deployment ne remplace pas un Pod, il en pilote la création via un ReplicaSet intermédiaire. Un Namespace n'isole pas le réseau par défaut, seulement les noms d'objets, ce qui surprend souvent. Et la différence entre ConfigMap et Secret ne tient pas à la sécurité du stockage mais à l'intention et au traitement par le cluster.
- Pods : l'unité de base, pourquoi pas un conteneur seul
- Deployments : scaling, rolling updates, rollbacks
- Services : ClusterIP, NodePort, LoadBalancer, DNS interne
- ConfigMaps et Secrets : injection de configuration
- Namespaces : isolation logique
L'API Kubernetes
Section intitulée « L'API Kubernetes »Le point conceptuel à maîtriser est le modèle déclaratif : vous décrivez ce que vous voulez obtenir, et des boucles de contrôle travaillent en continu pour y parvenir. C'est ce qui distingue Kubernetes d'un outil de déploiement classique, et beaucoup de questions en découlent, notamment sur l'auto-réparation. Côté API, sachez reconnaître à quel groupe appartient une ressource : les Pods et Services vivent dans le groupe de base v1, les Deployments dans apps/v1, les Jobs dans batch/v1.
- Le modèle déclaratif (état désiré vs état réel)
- Les groupes d'API (
apps/v1,batch/v1, etc.) kubectl: les commandes essentielles (get,describe,apply,delete)
Ce que vous devez savoir expliquer
Section intitulée « Ce que vous devez savoir expliquer »Ces quatre questions sont un test d'auto-évaluation, pas une liste à mémoriser. Formulez la réponse à voix haute, sans notes : si vous hésitez sur un maillon de la chaîne, vous venez d'identifier une lacune. La première question est la plus révélatrice, car y répondre complètement oblige à faire intervenir l'API Server, etcd, le Controller Manager, le Scheduler et le kubelet, c'est-à-dire tout le domaine 1 en une seule explication.
- Que se passe-t-il quand vous exécutez
kubectl apply -f deployment.yaml? - Pourquoi un Pod reste en
Pending? - Quelle est la différence entre un ReplicaSet et un Deployment ?
- Comment un Service trouve les Pods qu'il doit exposer (labels et selectors) ?
Guides du site pour ce domaine :
Domaine 2 : Container Orchestration (28%)
Section intitulée « Domaine 2 : Container Orchestration (28%) »Ce domaine teste votre compréhension de pourquoi et comment orchestrer des conteneurs à grande échelle.
Pourquoi orchestrer
Section intitulée « Pourquoi orchestrer »Les questions de ce type demandent d'identifier ce qu'un orchestrateur apporte en plus de l'exécution de conteneurs. Formulez-le en termes de problème résolu : Docker lance un conteneur sur une machine, Kubernetes maintient un nombre voulu de répliques sur un ensemble de machines, les remplace quand elles échouent et les rend joignables sous un nom stable. La comparaison avec Docker Swarm ou Nomad ne demande pas de détails techniques, seulement de savoir que ce sont des orchestrateurs concurrents.
- Les limites de Docker seul (scaling, résilience, service discovery)
- Ce qu'apporte un orchestrateur (scheduling, health checks, auto-healing)
- Kubernetes vs alternatives (Docker Swarm, Nomad)
Scheduling et placement
Section intitulée « Scheduling et placement »Le mécanisme à comprendre est en deux temps : le Scheduler filtre d'abord les nœuds incapables d'accueillir le Pod, puis classe les survivants pour choisir le meilleur. Les requests interviennent dans la phase de filtrage, pas les limits : un Pod qui demande 2 Go ne sera jamais placé sur un nœud qui n'a plus qu'un Go de disponible. La distinction entre taint (posé sur le nœud, qui repousse) et toleration (posée sur le Pod, qui accepte) est une question classique.
- Comment le Scheduler place les Pods sur les nodes
- Affinités, taints et tolerations (principes, pas la syntaxe détaillée)
- Requests et limits : leur rôle dans le scheduling
Scaling et résilience
Section intitulée « Scaling et résilience »L'examen distingue deux niveaux d'automatisme qu'il ne faut pas confondre. Le ReplicaSet maintient un nombre fixe de répliques, décidé par vous ; l'HPA fait varier ce nombre en fonction d'une métrique observée, typiquement l'usage CPU. Le self-healing, lui, ne relève d'aucun des deux : c'est le kubelet qui redémarre un conteneur en échec sur place, et le contrôleur qui recrée un Pod entier si le nœud disparaît.
- Horizontal Pod Autoscaler (HPA) : principes de fonctionnement
- ReplicaSets : maintien du nombre de réplicas souhaité
- Self-healing : redémarrage automatique des Pods en échec
Networking et service discovery
Section intitulée « Networking et service discovery »La règle fondatrice du modèle réseau Kubernetes tient en une phrase : chaque Pod dispose de sa propre adresse IP et peut joindre n'importe quel autre Pod sans traduction d'adresse. C'est de là que découlent toutes les autres notions. Comme ces adresses changent à chaque recréation, le Service fournit un nom et une adresse stables, et le DNS interne rend ce nom résolvable. Les NetworkPolicies viennent ensuite restreindre ce qui, par défaut, est entièrement ouvert.
- Le modèle réseau Kubernetes (chaque Pod a une IP)
- Services et DNS interne (
service.namespace.svc.cluster.local) - NetworkPolicies : principes d'isolation réseau
Le découpage à retenir est une séparation des responsabilités entre trois objets. Le PersistentVolume représente le stockage réel et relève de l'administrateur ; le PersistentVolumeClaim est la demande formulée par l'application et relève du développeur ; la StorageClass automatise la création du premier à partir de la seconde. Sachez aussi qu'un volume emptyDir disparaît avec le Pod, alors qu'un volume persistant lui survit.
- Volumes éphémères vs persistants
- PersistentVolumes (PV) et PersistentVolumeClaims (PVC)
- StorageClasses : provisionnement dynamique
Guides du site pour ce domaine :
Domaine 3 : Cloud Native Application Delivery (16%)
Section intitulée « Domaine 3 : Cloud Native Application Delivery (16%) »Ce domaine couvre la chaîne de livraison des applications cloud native.
CI/CD et déploiement
Section intitulée « CI/CD et déploiement »L'attendu porte sur le vocabulaire et sur ce que chaque stratégie de déploiement fait réellement. Le rolling update remplace les instances progressivement, sans jamais tout arrêter ; le blue-green maintient deux environnements complets et bascule le trafic d'un coup ; le canary n'expose la nouvelle version qu'à une fraction des utilisateurs avant de généraliser. Sachez associer chaque stratégie à son compromis entre coût en ressources et risque d'exposition.
- Les principes de CI/CD (intégration continue, déploiement continu)
- Pipelines de build, test, déploiement
- Stratégies de déploiement (rolling update, blue-green, canary)
La distinction pull contre push est le point le plus interrogé de ce thème. Dans un modèle push, votre pipeline CI détient des identifiants sur le cluster et lui envoie les changements ; dans un modèle pull, un agent installé dans le cluster va lui-même chercher l'état voulu dans Git. Le modèle pull est associé au GitOps parce qu'il évite d'exposer des accès au cluster depuis l'extérieur et qu'il corrige automatiquement les dérives de configuration.
- Le principe : Git comme source de vérité
- Le modèle pull vs push
- Les outils : ArgoCD, Flux (concepts, pas la configuration détaillée)
Trois mots suffisent, à condition de ne pas les mélanger : un chart est le paquet, les values sont les paramètres que vous fournissez, une release est une installation nommée de ce chart dans un cluster. Le problème que Helm résout est la duplication : sans lui, déployer la même application dans trois environnements impose de maintenir trois jeux de manifests presque identiques.
- Le rôle de Helm dans l'écosystème Kubernetes
- Charts, values, releases (vocabulaire)
- Pourquoi les templates facilitent la gestion des manifests
Conteneurs et images
Section intitulée « Conteneurs et images »Le point qui revient le plus souvent est le rôle de l'OCI (Open Container Initiative). Ne la confondez pas avec la CNCF : l'OCI produit des spécifications techniques normalisant le format des images et le comportement des runtimes, ce qui garantit qu'une image construite avec un outil s'exécute avec un autre. La CNCF, elle, héberge et gouverne des projets. Retenez aussi que l'image est immuable : on ne la modifie pas, on en publie une nouvelle version.
- Le cycle de vie d'une image conteneur (build, push, pull, run)
- Registries et distribution d'images
- Le standard OCI (Open Container Initiative)
Guides du site pour ce domaine :
Domaine 4 : Cloud Native Architecture (12%)
Section intitulée « Domaine 4 : Cloud Native Architecture (12%) »Ce domaine teste votre compréhension des principes architecturaux du cloud native.
Microservices
Section intitulée « Microservices »L'examen attend une position nuancée, pas un plaidoyer. Les microservices apportent un déploiement indépendant et une mise à l'échelle ciblée, au prix d'une complexité réseau et opérationnelle considérable. Sur les patterns, sachez situer chacun : le sidecar est un conteneur additionnel dans le même Pod, le service mesh généralise ce principe à l'échelle du cluster, l'API gateway se place en entrée pour le trafic venant de l'extérieur.
- Monolithe vs microservices : avantages et inconvénients
- Communication entre services (synchrone vs asynchrone)
- Patterns courants : sidecar, service mesh, API gateway
Infrastructure immuable
Section intitulée « Infrastructure immuable »Le bénéfice à savoir énoncer est la disparition de la dérive de configuration : quand aucun serveur n'est modifié après sa création, deux machines issues de la même définition restent identiques dans le temps. C'est ce qui rend les déploiements reproductibles et les retours arrière fiables. Faites le lien avec les conteneurs, qui sont l'application la plus visible de ce principe, et avec l'Infrastructure as Code, qui en est la condition pratique.
- Le principe : ne jamais modifier, toujours remplacer
- Infrastructure as Code (IaC) et son rôle
- Conteneurs comme unité de déploiement immuable
Autoscaling et serverless
Section intitulée « Autoscaling et serverless »Trois mécanismes d'autoscaling coexistent dans Kubernetes et l'examen vérifie que vous les distinguez. L'HPA ajoute ou retire des Pods, le VPA modifie les ressources allouées à un Pod existant, le Cluster Autoscaler ajoute ou retire des nœuds. Le serverless se situe à un autre niveau : c'est un modèle où l'infrastructure disparaît de vos préoccupations et où la mise à l'échelle peut descendre jusqu'à zéro instance, ce que Knative apporte à Kubernetes.
- Scaling horizontal vs vertical
- Kubernetes HPA et Cluster Autoscaler (principes)
- Serverless et Knative (concepts)
L'écosystème CNCF
Section intitulée « L'écosystème CNCF »Les trois niveaux de maturité reviennent très souvent dans les questions : sandbox pour les projets en début de vie, incubating pour ceux qui ont démontré un usage en production, graduated pour ceux qui ont franchi un audit complet et disposent d'une gouvernance stable. Kubernetes et Prometheus sont graduated, et connaître deux ou trois exemples par niveau suffit. Retenez aussi que la CNCF fait partie de la Linux Foundation, elle n'est pas une entreprise.
- La Cloud Native Computing Foundation : son rôle et sa gouvernance
- Les niveaux de maturité des projets : graduated, incubating, sandbox
- Les grandes familles d'outils (monitoring, networking, runtime, packaging) et quelques projets représentatifs
Observabilité
Section intitulée « Observabilité »Malgré son poids réduit dans le blueprint, ce thème revient régulièrement parce qu'il est facile à interroger. Sachez à quelle question répond chaque pilier : les métriques disent qu'il y a un problème et à quelle ampleur, les logs disent ce qui s'est passé sur un composant précis, les traces disent où le temps a été consommé dans un enchaînement d'appels entre services. Associez ensuite chaque catégorie à un projet représentatif de la CNCF.
- Les trois piliers : métriques, logs, traces
- Comprendre le rôle de chaque pilier et les catégories d'outils CNCF associées
Guides du site pour ce domaine :
Socle minimum avant de commencer
Section intitulée « Socle minimum avant de commencer »Avant d'attaquer la préparation KCNA, vérifiez que vous avez :
-
Compris ce qu'est un conteneur
Vous devez savoir ce qu'est une image, un conteneur, un Dockerfile. Vous avez déjà lancé un conteneur Docker au moins une fois.
-
Compris pourquoi on orchestre des conteneurs
Vous savez que Docker seul ne gère pas le scaling, la résilience ou le service discovery. Vous comprenez pourquoi Kubernetes existe.
-
Lu sur l'architecture Kubernetes
Vous connaissez les mots control plane, API Server, kubelet, Pod, Node, même si vous ne les maîtrisez pas encore parfaitement.
-
Un minimum de culture DevOps
Vous savez ce que sont CI/CD et Git. Vous comprenez l'idée d'automatisation du déploiement.
Plan de préparation (4 semaines)
Section intitulée « Plan de préparation (4 semaines) »Ce découpage suit les pondérations du blueprint : une semaine entière pour le domaine 1, une pour le domaine 2, une pour les deux domaines les plus légers réunis, une pour la consolidation. Chaque semaine se termine par un critère de validation formulé comme une explication à produire de mémoire, et non comme une liste de pages à avoir lues. C'est volontaire : sur un examen sans documentation, savoir reconnaître une notion ne suffit pas, il faut savoir la restituer.
Semaine 1 : Kubernetes Fundamentals (44%)
Section intitulée « Semaine 1 : Kubernetes Fundamentals (44%) »Objectif : Maîtriser l'architecture et les ressources de base.
C'est presque la moitié de l'examen. Passez du temps ici.
Ce que vous devez étudier :
- L'architecture du cluster (control plane + worker nodes)
- Chaque composant : API Server, etcd, Scheduler, Controller Manager, kubelet, kube-proxy
- Les ressources de base : Pod, Deployment, Service, ConfigMap, Secret, Namespace
- Le modèle déclaratif et les labels/selectors
- Les commandes kubectl fondamentales
Critère de validation : Vous pouvez expliquer oralement ce qui se passe quand on crée un Deployment, du kubectl apply jusqu'au Pod en fonctionnement.
Guides du site :
Semaine 2 : Container Orchestration (28%)
Section intitulée « Semaine 2 : Container Orchestration (28%) »Objectif : Comprendre les mécanismes d'orchestration.
Ce que vous devez étudier :
- Le Scheduler : comment il place les Pods
- Affinités, taints, tolerations (concepts)
- Scaling horizontal (HPA) et vertical (VPA)
- Le modèle réseau Kubernetes
- Services, DNS interne, NetworkPolicies
- Storage : PV, PVC, StorageClasses
Critère de validation : Vous pouvez expliquer comment Kubernetes assure la haute disponibilité d'une application (self-healing, scaling, service discovery).
Guides du site :
Semaine 3 : Application Delivery (16%) + Architecture (12%)
Section intitulée « Semaine 3 : Application Delivery (16%) + Architecture (12%) »Objectif : Comprendre la livraison et les principes cloud native.
Ces deux domaines représentent 28% à eux deux. Ils sont complémentaires et se révisent bien ensemble.
Ce que vous devez étudier :
- CI/CD : principes, pipelines, stratégies de déploiement
- GitOps : Git comme source de vérité, modèle pull, ArgoCD/Flux
- Helm : charts, values, releases
- Microservices vs monolithe
- Infrastructure immuable
- L'écosystème CNCF : les grandes familles d'outils et les projets emblématiques
- Les trois piliers de l'observabilité
Critère de validation : Vous pouvez expliquer le cycle de vie complet d'un changement applicatif (commit → build → test → deploy) dans un contexte GitOps.
Guides du site :
Semaine 4 : Révisions et entraînement
Section intitulée « Semaine 4 : Révisions et entraînement »Objectif : Consolider et identifier les lacunes.
Ce que vous devez faire :
- Relire vos notes sur les 4 domaines
- Refaire les quiz du site pour chaque domaine
- Identifier vos points faibles et y consacrer du temps
- Réviser le vocabulaire CNCF (projets graduated, incubating)
- Faire des QCM d'entraînement
Critère de validation : Vous obtenez régulièrement plus de 80% aux quiz d'entraînement.
Checklist finale :
- Architecture du cluster : je sais nommer et décrire chaque composant
- Ressources de base : Pod, Deployment, Service, ConfigMap, Secret, Namespace
- Orchestration : scheduling, scaling, self-healing, service discovery
- Réseau : modèle plat, Services, DNS, NetworkPolicies
- Storage : PV, PVC, StorageClasses
- CI/CD et GitOps : principes et outils
- Helm : rôle, vocabulaire, pourquoi c'est utile
- Écosystème CNCF : au moins 5 projets et leur rôle
- Observabilité : métriques, logs, traces, Prometheus
- Sécurité de base : RBAC, isolation, bonnes pratiques
Ce que la KCNA ne demande pas
Section intitulée « Ce que la KCNA ne demande pas »Pour ne pas vous disperser, voici ce qui est hors scope :
- Manipuler un cluster en ligne de commande → c'est un QCM, pas un examen pratique
- Installer Kubernetes avec kubeadm → CKA
- Écrire des manifests YAML de mémoire → CKA/CKAD
- Configurer des politiques de sécurité avancées → CKS
- Maîtriser Helm en profondeur → CKAD
- Déboguer des Pods en temps limité → CKA/CKAD
La KCNA teste votre compréhension conceptuelle, pas votre rapidité d'exécution.
Comment raisonner sur les QCM KCNA
Section intitulée « Comment raisonner sur les QCM KCNA »La KCNA n'est pas un examen de rapidité, c'est un examen de précision conceptuelle. Chaque question teste votre capacité à distinguer des notions proches, à identifier le rôle exact d'un composant ou à reconnaître un principe cloud native.
Distinguer les catégories
Section intitulée « Distinguer les catégories »Pour chaque notion, entraînez-vous à identifier s'il s'agit :
- d'un concept (microservices, infrastructure immuable, GitOps)
- d'un outil (Prometheus, Helm, ArgoCD)
- d'un rôle / composant (kubelet, API Server, Scheduler)
- d'un bénéfice (portabilité, résilience, observabilité)
Les questions KCNA jouent souvent sur ces distinctions. Par exemple : "Quel composant est principalement responsable du scheduling ?" teste si vous confondez le Scheduler avec le Controller Manager.
Confusions classiques à éliminer
Section intitulée « Confusions classiques à éliminer »Ces six paires sont celles que les rédacteurs de questions exploitent le plus, parce qu'une compréhension approximative suffit à travailler au quotidien mais pas à répondre juste. Traitez la dernière ligne avec prudence : le base64 d'un Secret est un encodage, pas un chiffrement, et n'importe qui ayant accès à l'objet peut le lire. C'est précisément le genre de nuance que l'examen cherche à vérifier.
| Facile à confondre | Comment distinguer |
|---|---|
| Pod / conteneur | Le Pod est l'enveloppe Kubernetes, le conteneur est le processus à l'intérieur |
| Deployment / ReplicaSet | Le Deployment gère les mises à jour, le ReplicaSet maintient le nombre de réplicas |
| Service / Ingress | Le Service expose à l'intérieur du cluster, l'Ingress gère l'entrée HTTP externe |
| CNI / CSI / CRI | Container Network / Storage / Runtime Interface, trois interfaces, trois préoccupations |
| OCI / CNCF | OCI = standards de conteneurs, CNCF = écosystème cloud native |
| ConfigMap / Secret | Même mécanisme, mais les Secrets sont encodés en base64 et destinés aux données sensibles |
Se méfier des formulations
Section intitulée « Se méfier des formulations »Les QCM CNCF utilisent des formulations précises. Soyez attentif à :
- "Which is NOT…", les négations inversent le raisonnement
- "Best describes…", plusieurs réponses peuvent sembler correctes, mais une seule est la plus précise
- "Primarily responsible for…", cherchez le rôle principal, pas un rôle secondaire
- "Which of the following…", lisez toutes les options avant de répondre
Stratégie le jour de l'examen
Section intitulée « Stratégie le jour de l'examen »Avec 90 minutes pour un questionnaire à choix multiples, le temps n'est pas la contrainte principale : la plupart des candidats terminent en avance. Le vrai risque est la lecture trop rapide d'une formulation négative ou d'une nuance de vocabulaire. Prévoyez explicitement un temps de relecture des questions marquées plutôt que de rendre l'examen dès la dernière réponse cochée.
| Conseil | Pourquoi |
|---|---|
| Lisez chaque question deux fois | Les formulations négatives ("lequel n'est PAS...") et les nuances ("best describes") sont fréquentes |
| Éliminez d'abord | 1-2 réponses sont souvent clairement fausses, ramenez le choix à 2 options |
| Ne bloquez pas | Marquez la question et revenez, utilisez les 90 minutes à bon escient |
| Précision du vocabulaire | Pod ≠ conteneur, Service ≠ Ingress, CNI ≠ CSI, les QCM testent ces distinctions |
| Pas d'accès à la doc | Contrairement aux CKA/CKAD/CKS, les quiz d'entraînement sont essentiels |
Positionnement dans les certifications CNCF
Section intitulée « Positionnement dans les certifications CNCF »La KCNA est la porte d'entrée du parcours de certification. La ligne à regarder en premier est Format : c'est la seule de ces quatre certifications qui ne se passe pas dans un terminal, ce qui explique à la fois son prix inférieur et son exigence de score plus élevée. Un score de 75 % sur un questionnaire à choix multiples reste plus accessible que 66 % sur des tâches à réaliser en deux heures sous chronomètre. Ces montants et ces seuils évoluent : vérifiez-les sur le site de la Linux Foundation avant d'acheter.
| Aspect | KCNA | CKAD | CKA | CKS |
|---|---|---|---|---|
| Niveau | Fondamental | Intermédiaire | Intermédiaire-avancé | Avancé |
| Format | QCM | Pratique (terminal) | Pratique (terminal) | Pratique (terminal) |
| Focus | Concepts | Applications | Cluster | Sécurité |
| Prérequis | Aucun | Pratique Kubernetes | Pratique Kubernetes | CKA réussie |
| Durée | 90 min | 2h | 2h | 2h |
| Prix | 250 $ | 445 $ | 445 $ | 445 $ |
| Score min | 75% | 66% | 66% | 67% |
Pièges courants de la préparation
Section intitulée « Pièges courants de la préparation »Ces cinq pièges ont un point commun : ils viennent d'une mauvaise représentation de l'examen, pas d'un manque de travail. Les deux premiers sont typiques des profils qui pratiquent déjà Kubernetes et supposent que l'expérience suffira ; le dernier touche tout le monde, puisque l'épreuve se déroule en anglais et que le vocabulaire technique y est employé avec précision. Traduire mentalement « scheduling » ou « workload » pendant l'examen coûte du temps et introduit des erreurs.
| Piège | Conséquence | Solution |
|---|---|---|
| Négliger les fondamentaux Kubernetes | 44% de l'examen perdu | Passez 50% de votre temps sur le domaine 1 |
| Se concentrer uniquement sur la pratique | L'examen est théorique (QCM) | Révisez aussi les concepts, pas seulement les commandes |
| Ignorer l'écosystème CNCF | Questions sur Prometheus, Envoy, OPA... | Faites un tour du landscape CNCF |
| Ne pas faire de QCM d'entraînement | Surpris par le format et le timing | Entraînez-vous en conditions réelles |
| Sous-estimer le vocabulaire anglais | L'examen est proposé en anglais | Révisez les termes anglais des concepts clés |
Ressources recommandées
Section intitulée « Ressources recommandées »Formation officielle
Section intitulée « Formation officielle »Le cours LFS250 est celui que la CNCF référence dans son propre dépôt de curriculum, ce qui en fait l'alignement le plus sûr avec le contenu réellement évalué. Il n'est pas obligatoire, et son intérêt dépend de votre point de départ : utile si vous découvrez le cloud native, redondant si vous pratiquez déjà Kubernetes et cherchez surtout à combler des lacunes ciblées.
- LFS250, Kubernetes and Cloud Native Essentials : Formation officielle de la Linux Foundation, conçue pour la KCNA
Documentation et références
Section intitulée « Documentation et références »Ces trois ressources répondent à des besoins distincts. Le curriculum officiel est la seule source qui fait autorité sur ce qui est évalué : commencez toujours par lui, et revenez-y avant de réserver l'examen car il est mis à jour sans annonce. La documentation Kubernetes sert à approfondir un concept mal compris, sans chercher l'exhaustivité. Le CNCF Landscape se parcourt par catégories, pas projet par projet, et une heure suffit largement.
- Kubernetes Documentation, La référence pour les concepts fondamentaux
- CNCF Landscape, Cartographie de l'écosystème cloud native
- KCNA Curriculum (CNCF), Le blueprint officiel de l'examen
Pratique complémentaire
Section intitulée « Pratique complémentaire »Même si l'examen est un QCM, manipuler un cluster aide à mémoriser les concepts :
- Créer un cluster local avec kind ou minikube
- Déployer une application simple (Deployment + Service)
- Observer le comportement (scaling, self-healing, rolling update)
Ce que le site couvre déjà
Section intitulée « Ce que le site couvre déjà »Le site couvre une large partie du programme KCNA. Voici un aperçu par domaine :
| Domaine (poids) | Couverture sur le site | Statut |
|---|---|---|
| Kubernetes Fundamentals (44%) | Architecture, Pods, Deployments, Services, Namespaces, ConfigMaps, RBAC | Bonne |
| Container Orchestration (28%) | Scheduling, HPA, Storage, Network Policies, DNS | Bonne |
| Cloud Native Delivery (16%) | GitOps, ArgoCD, Helm, Docker, Dockerfile | Correcte |
| Cloud Native Architecture (12%) | Principes cloud native, CNCF, service mesh, serverless, observabilité | En progression |
Les principaux manques pour la KCNA concernent surtout l'entraînement au format QCM et certains concepts cloud native transverses. Utilisez les quiz du site pour vous tester régulièrement et complétez avec les ressources externes ci-dessus.
À retenir
Section intitulée « À retenir »- La KCNA est un QCM de 90 minutes, pas d'accès à un cluster ni à la documentation
- Kubernetes Fundamentals représente 44%, investissez la moitié de votre préparation ici
- 75% de score minimum, c'est plus exigeant que CKA/CKAD (66%)
- 250 USD avec 1 reprise incluse, la certification CNCF la moins chère
- C'est un tremplin, pas une fin en soi, le parcours continue vers KCSA, CKAD, CKA ou CKS selon votre profil
- L'écosystème CNCF fait partie de l'examen, connaissez les grandes familles d'outils et les projets emblématiques
- Apprenez à raisonner sur les QCM, distinguer concept, outil, rôle et bénéfice fait la différence
- La pratique aide même pour un QCM, manipuler un cluster local ancre les concepts