Cette page vous propose un plan de préparation concret pour la GitLab Certified CI/CD Associate. GitLab présente cette certification comme un examen en ligne et hands-on, centré sur les bases de la CI/CD dans GitLab. L'objectif ici n'est pas de recopier la documentation officielle, mais de transformer la formation et les labs en plan d'entraînement réaliste.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Les compétences centrales évaluées autour de GitLab CI/CD
- Comment transformer la formation en plan de préparation certification
- Quoi pratiquer en priorité pour être à l'aise le jour J
- Les erreurs de préparation les plus fréquentes et comment les éviter
Format officiel à connaître
Section intitulée « Format officiel à connaître »GitLab présente la GitLab Certified CI/CD Associate comme un examen en ligne et hands-on, destiné à valider une compréhension fondamentale de la CI/CD dans GitLab. Le GitLab CI Fundamentals Learning Path constitue le parcours officiel le plus proche pour préparer cette certification.
Avant de fixer votre date, vérifiez toujours :
- le nom exact de la certification
- le format en vigueur
- les prérequis annoncés
- le learning path associé
Dans quel contexte ?
Section intitulée « Dans quel contexte ? »Vous êtes dans ce cas si vous savez déjà faire tourner un pipeline simple et voulez consolider les bases attendues pour travailler proprement avec GitLab CI/CD : comprendre les runners, structurer un pipeline, le maintenir, et résoudre les incidents courants.
Situations réelles où ce guide est utile :
- vous devez standardiser les pipelines de plusieurs équipes GitLab
- vous passez un entretien DevOps ou Platform avec preuve de compétences CI/CD
- vous perdez du temps sur les mêmes incidents (jobs pending, pipeline skip, cache inefficace)
- vous voulez cadrer une montée en niveau équipe avec une référence commune
Pour qui cette certification est pertinente ?
Section intitulée « Pour qui cette certification est pertinente ? »Cette certification est pertinente si vous :
- utilisez déjà GitLab CI/CD au quotidien
- devez standardiser ou maintenir des pipelines existants
- voulez démontrer un socle solide sur GitLab CI/CD
- cherchez une preuve de compétence plus concrète qu'une simple lecture de documentation
Ce que cette certification ne remplace pas
Section intitulée « Ce que cette certification ne remplace pas »Une certification atteste d'un socle, pas d'une expertise. Savoir où s'arrête ce socle évite deux erreurs opposées : la survendre sur un CV, ou la négliger parce qu'elle ne couvre pas tout. Voici précisément ce qu'elle laisse de côté.
La GitLab Certified CI/CD Associate ne remplace pas :
- une expérience réelle de production
- la maîtrise de Kubernetes ou du cloud
- les sujets avancés de supply chain, trusted delivery ou gouvernance
- les choix d'architecture runner à grande échelle
Compétences à consolider pour être prêt
Section intitulée « Compétences à consolider pour être prêt »La certification cible une pratique solide des mécanismes fondamentaux CI/CD de GitLab : conception de pipeline, exécution, maintenance, qualité et débogage.
Ce tableau ne remplace pas les objectifs officiels de GitLab University : il traduit ces attentes en plan de travail pratique à partir de la formation.
| Bloc de compétence | Ce qui est attendu en pratique | Guides recommandés |
|---|---|---|
| Structure pipeline | Lire, écrire et corriger un .gitlab-ci.yml | Concepts de base, Premier pipeline |
| Exécution CI | Comprendre runners, stages, jobs, variables | Runners, Variables |
| Performance et feedback | Utiliser artifacts, cache, needs, parallélisme | Artifacts et cache, DAG et parallélisme |
| Maintenance et réutilisation | Factoriser avec extends, templates, include | Extends et ancres, Templates |
| Fiabilité | Diagnostiquer les erreurs, rendre un pipeline robuste | Debug logs, Fiabilité des pipelines |
Plan de préparation en 4 phases
Section intitulée « Plan de préparation en 4 phases »Le programme ci-dessous est un plan de préparation conseillé sur 4 semaines. Adaptez-le selon votre niveau de départ et votre pratique réelle de GitLab.
-
Stabiliser les fondamentaux
Reprenez les modules essentiels du Volet 1 : structure YAML,
rules, runners, variables, débogage. -
Industrialiser sans complexifier inutilement
Travaillez extends, templates, DAG et workflows pour produire des pipelines lisibles, rapides et maintenables.
-
Pratiquer sur des cas réels
Exécutez les labs de bout en bout et refaites ceux qui échouent sans regarder la solution.
-
Simuler des incidents
Entraînez-vous à corriger des scénarios : pipeline skip, job pending, artifacts absents, erreurs de cache.
Programme recommandé
Section intitulée « Programme recommandé »Ce découpage en quatre semaines suit une logique précise : on stabilise d'abord ce qui casse le plus souvent (la syntaxe et les rules), puis on apprend à diagnostiquer, puis seulement on industrialise. Chaque onglet se termine par des labs de validation numérotés, qui sont le vrai critère de passage à la semaine suivante. Si un lab échoue, refaites-le avant d'avancer : accumuler du retard sur les fondamentaux se paie doublement en semaine 3.
Objectif : maîtriser le socle
Section intitulée « Objectif : maîtriser le socle »La semaine la plus rentable de tout le programme. Les erreurs qui font perdre du temps en examen ne viennent presque jamais d'une fonctionnalité avancée, mais d'une indentation YAML ou d'une rules mal comprise. Consacrez la moitié du temps à écrire des fichiers depuis une page blanche, sans copier un exemple existant.
- Revoir les bases
.gitlab-ci.yml - Refaire
rules, runners, artifacts/cache - Valider avec les labs 01, 03, 04, 06, 07
Objectif : diagnostiquer vite
Section intitulée « Objectif : diagnostiquer vite »Cette semaine ne s'apprend pas en lisant : provoquez les pannes vous-même. Un job qui reste pending et un pipeline skipped sont deux symptômes silencieux, sans message d'erreur, et ce sont ceux qui bloquent le plus de candidats. Chronométrez-vous : l'objectif est d'identifier la cause en moins de deux minutes, pas de la corriger élégamment.
- Travailler debug logs, pending, skip
- Refaire les incidents avec timer court
- Valider avec les labs 02, 08, 11
Objectif : industrialiser
Section intitulée « Objectif : industrialiser »À ce stade vous savez écrire un pipeline qui marche ; l'enjeu devient un pipeline qu'une autre personne peut reprendre. extends et include suppriment la duplication, needs supprime l'attente inutile entre étages. Le piège de cette semaine est l'excès inverse : une hiérarchie de templates trop profonde devient impossible à déboguer, restez sur deux niveaux au maximum.
- Couvrir extends, templates, DAG, matrice, workflows
- Éviter la duplication et les dépendances implicites
- Valider avec les labs 12 à 17
Objectif : consolider et finaliser
Section intitulée « Objectif : consolider et finaliser »Dernière semaine, aucun sujet nouveau. Refaites les labs les plus complets sans aide et sans notes, dans les conditions de l'examen. Le livrable de cette semaine est votre propre check-list : la liste des gestes que vous ne voulez pas avoir à réfléchir le jour J, écrite avec vos mots.
- Refaire les labs 18 et 19 en conditions réelles
- Réviser les erreurs fréquentes
- Construire votre check-list d'examen
Si vous avez suivi cette formation
Section intitulée « Si vous avez suivi cette formation »Vous êtes généralement prêt à entrer en phase de révision si vous avez :
- terminé le Volet 1
- pratiqué les labs fondamentaux sans aide
- refait les incidents
pending,skip, cache et logs - couvert les bases de l'industrialisation : templates,
extends, DAG
Erreurs fréquentes de préparation
Section intitulée « Erreurs fréquentes de préparation »Ces quatre erreurs ont un point commun : elles donnent l'impression d'avancer. On coche des chapitres, on lit de la documentation, et le niveau perçu monte plus vite que le niveau réel. La colonne Impact décrit ce qui se produit le jour de l'examen ou en incident de production ; c'est elle qui doit vous alerter, pas la colonne Erreur, dont on se croit toujours exempt.
| Erreur | Impact | Correction |
|---|---|---|
| Apprendre uniquement la syntaxe | Fragilité en incident réel | Faire des scénarios de panne et post-mortem |
| Ignorer les runners | Jobs bloqués ou imprévisibles | Réviser tags, executors, capacité et quotas |
| Sauter la partie industrialisation | Pipelines difficiles à maintenir | Travailler templates, includes et DAG |
| Ne pas pratiquer avec limite de temps | Stress et lenteur le jour J | Simuler des sessions chronométrées |
Check-list avant l'examen
Section intitulée « Check-list avant l'examen »Avant de vous inscrire, assurez-vous de savoir faire sans hésiter :
- lire et corriger un
.gitlab-ci.yml - expliquer le rôle d'un runner et d'un executor
- choisir entre variables, cache, artifacts et reports
- diagnostiquer un job bloqué ou un pipeline ignoré
- factoriser un pipeline avec
extends,includeet templates - expliquer quand utiliser
needs,parallelet les workflows - retrouver rapidement l'origine d'un échec dans les logs
À retenir
Section intitulée « À retenir »- La réussite vient d'une pratique répétée sur des cas concrets, pas d'une mémorisation brute.
- Le niveau attendu est Associate : socle opérationnel solide, pas expertise architecte.
- Les sujets à plus fort retour sont :
rules, runners, débogage et réutilisation de pipeline. - Les labs sont votre meilleur indicateur de préparation réelle.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- CLI GitLab (glab) : Lancer, suivre et relancer un pipeline depuis le terminal, le réflexe qui fait gagner du temps pendant les exercices hands-on.
- Plumber : Scanner un projet GitLab pour vérifier que les bonnes pratiques attendues à l'examen sont réellement appliquées.