Examen CNPA : réussir avec une préparation ciblée
Préparez l’examen CNPA sans perdre de temps : domaines évalués, notions clés et plan de révision réaliste pour viser la certification dès le premier essai.
Examen CNPA : les notions à maîtriser pour réussir sans réviser à l'aveugle
Réviser « outil par outil » dans l'écosystème (jusqu'au dernier paramètre) peut sembler prudent. Dans la pratique, pour l'examen CNPA, ça finit surtout par vous faire perdre du temps. L'épreuve teste moins votre capacité à configurer un produit précis que votre compréhension de l'ingénierie de plateforme : qui construit, qui utilise, comment c'est livré et comment on mesure si ça apporte vraiment de la valeur.
Un candidat a obtenu 88 points au premier essai, alors que le seuil de réussite était à 75, après environ quinze heures de préparation sur deux semaines. Son retour est utile : il dit que certaines heures passées sur Backstage ou Tekton n'ont pas beaucoup servi. À l'inverse, comprendre GitOps, relire attentivement le livre blanc de la CNCF et mémoriser les métriques DORA lui ont donné un bien meilleur rendement.
Voici donc une méthode simple et pragmatique : comprendre le format et les domaines évalués, repérer ce qui revient, distinguer les concepts des détails d'implémentation, puis organiser vos révisions en fonction de ce que l'examen attend vraiment. L'objectif n'est pas d'apprendre tout Kubernetes par cœur, mais de mieux répondre aux questions du CNPA.
Ce que l'examen CNPA évalue vraiment
Le CNPA, ou Certified Cloud Native Platform Engineering Associate, vise l'ingénierie de plateforme au-dessus de Kubernetes. Ce n'est pas un contrôle « vous connaissez l'écosystème Kubernetes ? ». L'examen cherche surtout à vérifier que vous comprenez les pratiques, les rôles et les décisions qui permettent de proposer des capacités réutilisables aux équipes de développement.
Pour orienter vos révisions, la différence avec le KCNA aide bien. Le KCNA couvre plus largement les fondamentaux du cloud native et de Kubernetes. Le CNPA, lui, insiste davantage sur la façon dont une organisation conçoit et fait fonctionner une plateforme : expérience développeur, équipes de plateforme, livraison, provisionnement et mesure des résultats.
Le format et la pondération donnent déjà une stratégie
L'épreuve se déroule en ligne, sous surveillance à distance. Environ 85 questions à choix multiples, pour 120 minutes. Dans le retour d'expérience cité, le seuil de réussite est de 75 points sur 100 et le candidat a obtenu 88 dès sa première tentative.
Et surtout : les domaines donnent un meilleur fil conducteur que la liste des outils. Par exemple :
| Domaine | Poids dans l'examen |
|---|---|
| Fondamentaux de l'ingénierie de plateforme | 36 % |
| Observabilité, sécurité et conformité des plateformes | 20 % |
| Livraison continue et ingénierie de plateforme | 16 % |
| API de plateforme et provisionnement de l'infrastructure | 12 % |
| Plateformes de développement internes et expérience développeur | 8 % |
| Mesure de la plateforme | 8 % |
Les fondamentaux pèsent plus d'un tiers de l'épreuve. Ce n'est pas « réciter du YAML », c'est comprendre ce qu'est une plateforme et comment les équipes interagissent. Les domaines liés à la mesure, aux API et à l'expérience développeur sont plus petits, mais ils regroupent souvent des notions bien délimitées : vous pouvez donc les travailler efficacement.
La question implicite : qui est le client de cette capacité ?
Quand vous traitez un scénario, gardez un fil simple : la capacité répond-elle d'abord à un problème de l'équipe de plateforme ou à un besoin du développeur ? En général, l'équipe de plateforme fournit et maintient les interfaces communes ; le développeur s'en sert pour obtenir une ressource ou suivre un chemin vers la production.
Cette distinction évite un piège courant : confondre l'outil et le service rendu. Une plateforme ne se résume pas à un portail, à un cluster, ni même à une collection d'outils. C'est un ensemble de capacités pensé pour réduire la charge mentale des équipes de développement et rendre certaines opérations disponibles de façon cohérente.
Les notions qui rapportent le plus de points
Si vous voulez maximiser vos points, commencez par le livre blanc de la CNCF sur les plateformes. Il aborde notamment la plateforme comme produit, la logique d'alignement sur les flux de valeur, et le développeur comme utilisateur. Une lecture rapide ne suffit pas forcément : ce sont les liens entre concepts qui vous aident à choisir la bonne réponse dans des questions de mise en situation.
Le candidat derrière ce retour l'a lu deux fois, avec des notes. Il estime que le contenu recouvrait environ 30 % des questions. Je le traiterais comme une estimation liée à une session donnée, pas comme une « pondération garantie ». Mais l'idée reste la même : comprendre le document vaut mieux que disperser ses révisions dans des tutoriels d'outils.
Plateforme comme produit et parcours de référence
Une plateforme interne doit être pensée comme un produit utilisé par des équipes de développement. Concrètement, ça veut dire : comprendre leurs besoins, proposer des interfaces cohérentes, puis améliorer le service à partir de retours observés. Le mot « produit » ne veut pas dire qu'il faut ajouter une couche commerciale : il rappelle surtout que la plateforme doit résoudre un problème réel pour ses utilisateurs.
Les golden paths (parcours de référence) sont des voies recommandées, avec une opinion derrière. Elles peuvent standardiser des choix et éviter des répétitions. Mais elles ne devraient pas forcément verrouiller toutes les options. Dans vos révisions, une bonne question est souvent : est-ce que ce parcours aide vraiment, ou est-ce qu'il empêche d'autres approches ?
Autre point utile : le portail développeur et la plateforme ne sont pas la même chose. Une Internal Developer Platform désigne l'ensemble des capacités en libre-service qui permettent de provisionner ou d'exploiter des services. Une Internal Developer Portal, par exemple Backstage, est l'interface qui montre ces capacités. Le portail peut être une porte d'entrée ; il ne remplace pas l'ensemble de la plateforme.
DORA : apprendre les quatre métriques, pas une liste approximative
Les métriques DORA servent à suivre des résultats liés à la livraison logicielle et à la récupération du service. Retenez les quatre :
- Fréquence de déploiement : à quelle fréquence les changements arrivent en production.
- Délai de livraison des changements : le temps entre un changement validé (souvent un commit) et sa mise en production.
- Taux d'échec des changements : la part des déploiements qui provoquent une dégradation ou un incident qui nécessite une intervention.
- Temps moyen de restauration : le temps nécessaire pour rétablir le service après un incident ou un échec.
Dans le retour d'expérience, le piège cité est le Mean Time to Detect (temps moyen de détection). Le terme ressemble, mais ce n'est pas une des quatre métriques DORA. En QCM, ne vous laissez pas juste convaincre par la proximité des mots : vérifiez ce qui est réellement mesuré.
Comment réviser les outils sans surapprendre
Les outils comptent, mais l'examen évalue surtout votre compréhension de leur rôle. Une bonne approche consiste à savoir à quelle couche appartient chaque objet et quel problème il résout. Passer des heures à mémoriser une configuration détaillée n'est rentable que si des questions demandent vraiment de produire cette configuration.
Crossplane : connaître les responsabilités de chaque objet
Le candidat a passé plus de temps que nécessaire sur Crossplane. Il explique que les questions portaient davantage sur les concepts que sur « écrire du YAML » depuis zéro. Pour éviter de confondre les objets, retenez la répartition des responsabilités :
- XRD : définit l'API mise à disposition par l'équipe de plateforme.
- Composition : décrit l'implémentation maintenue par l'équipe de plateforme.
- Claim : représente la demande formulée par le développeur via cette API.
Cette logique par responsabilités tient mieux que la mémorisation de la syntaxe. Si une question vous demande qui définit le contrat et qui exprime le besoin, vous voyez tout de suite que l'équipe de plateforme et le développeur n'ont pas le même rôle dans le modèle.
Pour ancrer, une courte manipulation dans un cluster de test peut aider. Voir ce qu'un Claim déclenche, et quelles ressources apparaissent ensuite, clarifie le lien entre l'interface demandée et l'implémentation. Pas besoin d'en faire un environnement de production : l'idée est juste de visualiser le mécanisme.
GitOps : distinguer une synchronisation tirée d'un déploiement poussé
En GitOps, un agent ou un contrôleur regarde l'état déclaré puis le rapproche de l'état réel du cluster. Le modèle est généralement pull : le système récupère les changements depuis la source déclarative. À l'inverse, un pipeline CI qui pousse directement des modifications vers le cluster correspond plutôt à un modèle push. Dans l'examen, on vous demande parfois de reconnaître quel modèle respecte les principes GitOps : c'est souvent là que la réponse se joue.
Retenez aussi les principes OpenGitOps : état déclaratif, versionné et immuable ; récupération automatique ; puis réconciliation continue. Ces principes ne dépendent pas d'un outil unique : ils s'appliquent à des solutions comme Argo CD ou Flux.
Pour Argo CD, vous pouvez vous concentrer sur le résultat de quelques options plutôt que sur tous les écrans de configuration. Self-heal remet l'état déclaré en cohérence avec Git quand des changements manuels créent une dérive. Prune supprime les ressources absentes de l'état souhaité. La « détection de dérive » correspond simplement à l'écart entre ce qui est attendu et ce qui est observé.
Observabilité, sécurité et conformité : comprendre ce qui marche, pas seulement les noms
En observabilité, faites la différence entre traces, métriques et journaux (OpenTelemetry). Et gardez en tête que l'OpenTelemetry Collector reçoit, traite et transmet des données de télémétrie. Vous n'avez pas besoin d'apprendre chaque pipeline par cœur : l'enjeu est de savoir où se situe le Collector et ce qu'il fait.
Pour la partie sécurité, le retour d'expérience recommande de comprendre la différence conceptuelle entre Kyverno et OPA Gatekeeper, sans s'enfermer dans tous les détails de configuration. Même idée côté chaîne d'approvisionnement logicielle : savoir expliquer la signature d'images, les SBOM (listes des composants logiciels) et les contrôles de politique intégrés au pipeline CI.
À noter : le candidat n'a pas rencontré de questions sur la configuration RBAC ou SSO d'Argo CD. Ça ne veut pas dire que ça ne pourrait jamais tomber. Juste : sur sa session, apprendre les concepts clés et la logique GitOps a été plus rentable que mémoriser des réglages avancés.
Un plan de préparation réaliste en quinze heures
Le candidat a préparé environ quinze heures, étalées sur deux semaines de soirées, pour obtenir 88 points. Évidemment, ça ne garantit pas le même résultat à tout le monde : votre expérience de Kubernetes, de la livraison logicielle et des plateformes change le temps nécessaire. Mais ce qui compte ici, c'est l'ordre de priorité.
Répartir le temps selon le rendement attendu
Commencez par DORA : environ vingt minutes. Apprenez les quatre métriques et leur définition, puis distinguez bien le temps de détection du temps de restauration. Même si le domaine ne pèse que 8 %, les notions sont claires et testables.
Lisez le livre blanc de la CNCF deux fois, avec des notes. Première passe : repérez les idées (plateforme comme produit, équipes, utilisateurs, parcours de référence). Deuxième passe : reformulez chaque point et reliez-le à une situation concrète. C'est prioritaire parce que ce sont les fondamentaux (36 %).
Réservez environ trois heures à une expérimentation ciblée. Dans un cluster de test, observez une synchronisation avec Argo CD et voyez ce qu'un Claim Crossplane déclenche. Une démo courte éclaire mieux les boucles de réconciliation et les responsabilités qu'une longue lecture sans pratique.
Révisez le vocabulaire technique au bon niveau. Pour OpenTelemetry : identifiez les signaux et le rôle du Collector. Pour Kyverno et Gatekeeper : retenez à quoi servent les politiques. Pour la chaîne d'approvisionnement : sachez décrire signature, SBOM et contrôle côté CI. Pour GitOps : entraînez-vous à reconnaître les modèles pull et push.
Faites des questions d'entraînement avant le jour J. Le but n'est pas de prédire chaque item, mais de repérer vos zones faibles. Après chaque erreur, notez le concept mal compris et ce qui vous a piégé. Refaire une question sans comprendre l'erreur donne une impression de progrès ; ce n'est pas une vraie consolidation.
Ce qui a été moins rentable dans ce cas
Dans ce retour, le candidat estime avoir passé trop de temps à la configuration de Backstage et aux détails de Tekton. Il dit que les questions portaient peu sur les plugins Backstage en pratique, et que le domaine « livraison continue » testait surtout les principes GitOps plutôt que la maîtrise fine de Tekton.
La leçon n'est pas d'abandonner ces outils. Si votre travail implique de déployer Backstage ou de maintenir des pipelines Tekton, cette connaissance a une valeur professionnelle. En revanche, si vous préparez uniquement le CNPA, posez-vous avant chaque bloc : le domaine est-il fortement pondéré, et l'épreuve attend-elle un concept ou une configuration ?
C'est exactement cette différence qui évite de consacrer dix heures à un outil secondaire tout en laissant flou un principe central. Platform Engineering on Kubernetes, de Mauricio Salatino, peut compléter avec une approche plus pratique. Mais rien ne remplace vraiment la lecture du référentiel d'examen et les ressources de la CNCF.
À retenir : pour chaque notion, identifiez le besoin auquel elle répond, l'acteur responsable et le niveau de détail réellement attendu. C'est plus efficace que mémoriser des commandes hors contexte.
Conclusion : réviser le raisonnement, pas les écrans
Le CNPA valorise une compréhension cohérente de l'ingénierie de plateforme. Les sujets les plus utiles sont : les fondamentaux de la CNCF, les parcours de référence, la différence entre plateforme et portail, les principes GitOps, les responsabilités Crossplane, et les métriques DORA. La configuration avancée d'un outil ne devrait pas automatiquement devenir votre priorité.
Avant d'ajouter une ressource à votre programme, regardez : le poids du domaine, le niveau de détail attendu, et si vous savez expliquer clairement le rôle de chaque acteur. Ensuite, testez avec des questions concrètes. Cette méthode ne promet pas un score parfait, mais elle évite de brûler du temps et vous prépare mieux aux scénarios. Commencez par le livre blanc et par les notions que, pour l'instant, vous n'arrivez pas à expliquer sans hésiter.