⚠️ Fail Analysis

Pourquoi les gens ratent Docker Certified Associate (DCA)

La Docker Certified Associate couvre le runtime Docker, Docker Swarm (l'orchestrateur natif), la sécurité conteneur et Docker Enterprise (Universal Control Plane / Docker Trusted Registry). La majorité des candidats arrivent avec une bonne connaissance des commandes Docker courantes — et ratent sur Swarm, les namespaces de sécurité et DTR/UCP qu'ils n'ont jamais utilisés. Données issues de r/docker, forums Mirantis et retours de community members.

Révisé 2026-05 Mirantis ne publie pas de taux officiel. Estimations communautaires : ~60-70% en première tentative. La DCA est réputée plus technique que les certifications cloud fondation mais moins hands-on que la CKA.

TL;DRTu peux build et run des conteneurs Docker les yeux fermés ? Bien. L'examen teste surtout Docker Swarm (orchestration), la sécurité conteneur (namespaces, cgroups, seccomp) et Docker Enterprise — exactement ce que les candidats n'utilisent pas au quotidien.

Top 5 erreurs (du plus fréquent au moins fréquent)

Ignorer Docker Swarm parce que 'tout le monde utilise Kubernetes'.

Cause #1 d'échec selon les retours communautaires — Swarm représente ~25% du blueprint.

Docker Swarm est l'orchestrateur natif Docker et reste massivement présent dans l'examen. Les candidats qui ont tout misé sur Kubernetes en pratique ne connaissent pas les services Swarm, les stacks, le routing mesh, les overlay networks ou les labels de node. Résultat : ~25% des questions perdues d'entrée.

Le fixMonte un lab Swarm de 3 nœuds (1 manager, 2 workers) dans des VMs ou via Play with Docker. Pratique : `docker swarm init`, `docker service create`, `docker service scale`, `docker stack deploy`, rolling updates, drain d'un node. Ce n'est pas Kubernetes — les commandes et le modèle mental sont différents, il faut s'y entraîner explicitement.

Ne pas comprendre les primitives de sécurité Docker (namespaces, cgroups, seccomp, AppArmor/SELinux).

Bloc sécurité = ~15% de l'examen — régulièrement mal maîtrisé.

L'exam teste : à quoi sert chaque namespace (PID, NET, MNT, UTS, IPC, USER), comment cgroups limite les ressources CPU/mémoire, qu'est-ce que seccomp et quand l'utiliser, comment les capabilities Linux permettent de ne pas lancer en root. Sans comprendre ces mécanismes, les questions de 'isolation conteneur' deviennent des devinettes.

Le fixApprends les 6 namespaces Linux et leur rôle dans l'isolation Docker. Retiens que cgroups limite les ressources (CPU, mémoire, I/O) et que seccomp filtre les syscalls. Pour les questions 'moins de privilèges possibles' : `--cap-drop ALL --cap-add <MINIMAL>` + `--security-opt seccomp=<profile>`. Lab : lance un conteneur avec `--cap-drop ALL` et observe ce qui casse.

Sous-estimer la partie réseau Docker (drivers, overlay, macvlan, bridge).

20-25% des questions réseau sont ratées en moyenne.

Bridge (réseau local d'un host), Host (partage le réseau du host), Overlay (réseau multi-host pour Swarm), Macvlan (IP directement sur le LAN) — l'examen demande 'quel driver pour communiquer entre containers sur des hosts différents' (overlay), 'quel driver si tu veux que ton conteneur ait une IP sur ton LAN physique' (macvlan). Sans les distinctions, tu confonds bridge et overlay.

Le fixMémorise les 4 drivers courants et leur cas d'usage. Règle : Overlay = multi-host Swarm, Bridge = local monohost, Macvlan = IP physique LAN, Host = maximum performance réseau. Crée un réseau overlay manuellement (`docker network create --driver overlay mon-réseau`) et déploie 2 services Swarm dessus.

Ne pas pratiquer Docker Content Trust (image signing) et Docker Trusted Registry.

Bloc Image Management + DTR = ~20% de l'examen — pas pratiqué par la majorité.

Docker Content Trust (DCT) permet de signer et vérifier les images avant déploiement. Docker Trusted Registry (DTR) est le registry d'entreprise avec RBAC, image scanning et mirroring. Ces outils sont utilisés dans les contextes enterprise mais pas dans les labs perso. L'examen teste les commandes DCT et les concepts de gestion de registry dans UCP/DTR.

Le fixActive DCT avec `export DOCKER_CONTENT_TRUST=1`, teste la signature d'une image locale (`docker trust sign`), comprends les notions de Notary server et de root key. Pour DTR/UCP : utilise la version d'essai de Mirantis Docker Enterprise ou revois le blueprint section by section — c'est du QCM, pas du hands-on, donc un survol documentaire suffit.

Confondre les Dockerfile best practices avec les directives de sécurité examen.

Questions 'quelle est la meilleure pratique' mal traitées sur les images multi-stage.

L'examen teste les multi-stage builds (réduire la taille de l'image finale), l'usage de USER pour ne pas lancer en root, les .dockerignore pour ne pas copier des secrets dans l'image, l'ordre des layers pour optimiser le cache. Les candidats font du Docker depuis des années mais n'ont jamais formalisé ces pratiques.

Le fixÉcris 3 Dockerfile avec multi-stage build (une appli Node, une appli Go, une appli Python). Dans chaque, ajoute : USER non-root, HEALTHCHECK, .dockerignore, copie uniquement le nécessaire. Ces patterns reviennent dans plusieurs questions — les avoir pratiqués te donne la bonne réponse instinctivement.

Évite ces 5 erreurs en t'entraînant correctement

La pratique sur des questions au format examen reste la méthode #1 pour calibrer son niveau. Docker Certified Associate (DCA) a sa propre banque sur CertQuests — gratuite et sans inscription.

⚡ S'entraîner sur DCA 🗺️ Cert Quest path

Sources

Analyse issue de threads publics (Reddit, communautés Discord/forum vendor). Les fréquences sont des estimations qualitatives — pas des stats officielles. Vérifier avec ses propres recherches avant de prendre une décision majeure de prep.