QCM : Docker et conteneurisation (29 questions)

Questions et réponses du QCM

1. Quel est le principe de l’Infrastructure as Code (IaC) ?

Regrouper les serveurs physiques dans une machine virtuelle administrée manuellement
Centraliser les données dans un service distant pour éviter de gérer les équipements
Surveiller les services au moyen de tableaux de bord sans décrire leur configuration
Décrire l’infrastructure dans des fichiers ou des recettes pour la reproduire automatiquement

Décrire l’infrastructure dans des fichiers ou des recettes pour la reproduire automatiquement

Explication

L’IaC formalise le fonctionnement de l’infrastructure dans des fichiers ou des recettes afin d’en automatiser la reproduction. La surveillance par tableaux de bord peut compléter une infrastructure, mais ne définit pas l’IaC.

2. Pourquoi héberger les données en interne peut-il contribuer à la souveraineté d’une infrastructure ?

Cela garantit que les logiciels utilisés sont tous développés par l’équipe interne
Cela assure que les données sont répliquées automatiquement chez un prestataire externe
Cela dispense de documenter les configurations et les procédures de maintenance
Cela permet de maîtriser le matériel, les données, les services et l’accès physique

Cela permet de maîtriser le matériel, les données, les services et l’accès physique

Explication

L’hébergement interne aide à garder la maîtrise des équipements, des données, des services et de l’accès physique. Il ne garantit pas que les logiciels soient développés par l’équipe, ce qui est une question distincte.

3. Que regroupe un conteneur pour distribuer une application ?

L’application avec son code ou binaire, son environnement d’exécution, ses bibliothèques et ses fichiers annexes
Un ensemble de services distants accessibles par le réseau, sans fichiers ni outils associés
Un système d’exploitation complet avec son propre noyau, indépendant de celui de l’hôte
Une image immuable qui sert de référence, sans inclure l’environnement nécessaire à l’application

L’application avec son code ou binaire, son environnement d’exécution, ses bibliothèques et ses fichiers annexes

Explication

Un conteneur enveloppe l’application et les éléments nécessaires à son exécution, notamment ses bibliothèques et fichiers annexes. Un système d’exploitation doté de son propre noyau caractérise plutôt une machine virtuelle.

4. Quel rôle joue une image Docker par rapport aux conteneurs ?

Elle fournit un noyau distinct que chaque conteneur utilise pour isoler son système
Elle représente un conteneur en cours d’exécution dont les changements modifient le modèle
Elle décrit les connexions réseau entre les applications déjà lancées dans des conteneurs
Elle constitue une référence empaquetée et immuable permettant de créer des conteneurs

Elle constitue une référence empaquetée et immuable permettant de créer des conteneurs

Explication

Une image Docker est une capture empaquetée et immuable utilisée comme référence pour créer des conteneurs. Un conteneur en cours d’exécution est une instance de l’image, et non l’image elle-même.

5. Une équipe doit lancer trois instances identiques d’une application ; quelle relation entre images et conteneurs convient ?

Créer trois conteneurs à partir de la même image de référence
Créer une image distincte à partir de chacun des trois conteneurs
Faire d’un conteneur le modèle immuable dont dérivent les deux autres
Fusionner les trois instances dans une image qui ne peut pas être exécutée

Créer trois conteneurs à partir de la même image de référence

Explication

Un conteneur est une instance d’image, et plusieurs conteneurs peuvent provenir de la même image. L’image joue le rôle de modèle de référence, tandis que le conteneur est l’instance exécutée.

6. Pour ajouter un logiciel à une image Docker, quelle démarche de construction convient ?

Écrire les étapes dans un volume, qui remplace l’image de départ et le Dockerfile
Modifier une image immuable en cours d’exécution sans enregistrer les étapes de construction
Partir d’une image existante et décrire l’ajout du logiciel dans un Dockerfile, par exemple avec RUN
Créer d’abord un conteneur, puis utiliser son noyau comme base du Dockerfile

Partir d’une image existante et décrire l’ajout du logiciel dans un Dockerfile, par exemple avec RUN

Explication

La construction part d’une image existante et décrit dans un Dockerfile les logiciels ou fichiers à ajouter, avec des commandes telles que RUN. Modifier un conteneur en cours d’exécution ne remplace pas la description reproductible de la construction dans le Dockerfile.

7. Quelle différence de système distingue une machine virtuelle d’un conteneur ?

Les deux embarquent un noyau distinct, mais le conteneur partage le système de fichiers de l’hôte
La machine virtuelle partage le noyau de l’hôte, tandis que le conteneur embarque son propre noyau
La machine virtuelle embarque son propre système et son noyau, tandis que le conteneur partage le noyau de l’hôte
Les deux partagent le noyau de l’hôte, mais la machine virtuelle ajoute un environnement d’exécution

La machine virtuelle embarque son propre système et son noyau, tandis que le conteneur partage le noyau de l’hôte

Explication

Une machine virtuelle embarque un système d’exploitation avec son propre noyau, alors qu’un conteneur utilise le noyau de l’hôte. L’idée que le conteneur possède son propre noyau confond conteneurisation et virtualisation.

8. Une équipe compare l’espace généralement nécessaire à une VM et à un conteneur : quelle estimation est cohérente ?

Une VM occupe quelques centaines de mégaoctets ou moins, tandis qu’un conteneur pèse plusieurs gigaoctets
Les deux occupent généralement plusieurs dizaines de gigaoctets, car ils embarquent un système complet
Une VM occupe plusieurs gigaoctets à plusieurs dizaines, tandis qu’un conteneur pèse quelques centaines de mégaoctets ou moins
Les deux occupent généralement quelques centaines de mégaoctets, car ils partagent le même format d’image

Une VM occupe plusieurs gigaoctets à plusieurs dizaines, tandis qu’un conteneur pèse quelques centaines de mégaoctets ou moins

Explication

Une VM pèse généralement plusieurs gigaoctets à plusieurs dizaines de gigaoctets, contre quelques centaines de mégaoctets ou moins pour un conteneur. Inverser ces ordres de grandeur revient à attribuer au conteneur le poids habituel d’une VM.

9. Pour isoler plus fortement une charge de travail du système hôte, quel choix est le mieux justifié ?

Une machine virtuelle, car elle partage le noyau de l’hôte tout en supprimant l’isolation logicielle
Un conteneur, car il embarque son propre noyau et élimine toute dépendance au système hôte
Un conteneur, car le partage du noyau crée une séparation plus forte qu’un système d’exploitation distinct
Une machine virtuelle, car elle n’a pas de lien direct avec l’hôte comme en a un conteneur partageant son noyau

Une machine virtuelle, car elle n’a pas de lien direct avec l’hôte comme en a un conteneur partageant son noyau

Explication

La virtualisation complète offre une isolation plus forte : la VM n’a pas de lien direct avec le système hôte, contrairement au conteneur qui partage son noyau. Le partage du noyau explique précisément pourquoi la conteneurisation isole moins fortement.

10. Pour choisir une image sur Docker Hub, quelle pratique est recommandée afin de limiter les risques liés à la qualité variable des images disponibles ?

Privilégier les images les plus téléchargées, quel que soit leur éditeur
Choisir les images qui proposent le plus grand nombre de tags
Privilégier les images officielles publiées par l’éditeur du logiciel
Préférer les images les plus légères, même si leur éditeur est inconnu

Privilégier les images officielles publiées par l’éditeur du logiciel

Explication

Les images officielles publiées par l’éditeur sont recommandées, car la qualité des images disponibles sur Docker Hub varie. La popularité peut guider un choix, mais elle ne remplace pas cette recommandation sur l’éditeur.

11. Une image Docker repose sur une image de base vulnérable ; quelle démarche permet de traiter correctement ce risque ?

Remplacer le tag par un nom différent sans modifier le contenu de l’image
Ajouter une couche applicative afin de masquer les vulnérabilités de la base
Reconstruire et corriger l’image de base, puis la maintenir à jour
Déployer plusieurs conteneurs pour répartir l’exposition à la vulnérabilité

Reconstruire et corriger l’image de base, puis la maintenir à jour

Explication

Une image dérivée n’est pas plus sûre que son image de base : celle-ci doit être reconstruite, corrigée et maintenue. Ajouter une couche applicative ne supprime pas les vulnérabilités héritées de la base.

12. Pour respecter le principe de conception Docker présenté, comment organiser une application composée de plusieurs services ?

Placer chaque service dans son propre conteneur et utiliser Docker Compose pour les démarrer ensemble
Regrouper tous les services dans un seul conteneur et le démarrer comme une machine virtuelle
Créer un conteneur par application et utiliser Docker Compose pour fusionner leurs services
Placer les services dans des images séparées, puis les démarrer manuellement sans coordination

Placer chaque service dans son propre conteneur et utiliser Docker Compose pour les démarrer ensemble

Explication

Le principe consiste à faire correspondre un conteneur à un service, puis à utiliser Docker Compose pour démarrer ensemble les services de l’application. Regrouper tous les services dans un seul conteneur correspond à la confusion avec une organisation de type machine virtuelle.

13. Dans une architecture en microservices, que peut-il se passer si un service tombe en panne ?

La panne empêche les autres services d’être mis à jour indépendamment
La panne entraîne nécessairement l’arrêt de tous les services de l’application
La panne peut être limitée à ce service, tandis que les autres restent distincts
La panne est automatiquement transférée à un conteneur qui remplace l’ensemble des services

La panne peut être limitée à ce service, tandis que les autres restent distincts

Explication

Les microservices peuvent être mis à jour indépendamment, et la panne d’un service peut rester limitée à ce service. Une panne isolée ne signifie pas nécessairement que tous les autres services s’arrêtent.

14. Quelle démarche décrit l’installation de Docker sur Debian présentée ici ?

Installer Docker depuis un dépôt non officiel, puis ajouter sudo et containerd après le premier lancement
Suivre la documentation officielle depuis le dépôt APT, installer sudo, puis installer Docker CE et ses composants associés
Télécharger un paquet Docker isolé, puis installer Docker CE sans la CLI ni les outils de construction
Compiler le moteur Docker manuellement, puis installer uniquement Docker CE et Docker Compose

Suivre la documentation officielle depuis le dépôt APT, installer sudo, puis installer Docker CE et ses composants associés

Explication

La démarche passe par la documentation officielle et le dépôt APT, après l’installation de sudo, puis installe Docker CE, sa CLI, containerd, Buildx et le plugin Compose. Installer un paquet isolé sans ces composants ne correspond pas à cette procédure.

15. Quel est l’effet de l’ajout d’un utilisateur au groupe docker sur une machine Debian ?

Il peut utiliser Docker sans être root et reçoit des droits limités aux conteneurs lancés
Il peut gérer Docker uniquement après être devenu root avec su -
Il peut lancer des conteneurs, mais ne peut pas accéder aux ressources de la machine hôte
Il peut utiliser Docker sans être root, mais obtient des droits équivalents à ceux de root

Il peut utiliser Docker sans être root, mais obtient des droits équivalents à ceux de root

Explication

L’appartenance au groupe docker permet d’utiliser Docker sans être root, mais confère des droits équivalents à root sur la machine. Ces droits ne sont donc pas limités aux seuls conteneurs.

16. Un conteneur cesse de fonctionner lorsque son processus principal se termine. Quel principe explique ce comportement ?

La durée de vie du conteneur dépend de celle de son processus principal.
La durée de vie du conteneur dépend du maintien de sa connexion réseau.
La durée de vie du conteneur dépend du nombre de fichiers qu’il contient.
La durée de vie du conteneur dépend de la présence d’un terminal ouvert.

La durée de vie du conteneur dépend de celle de son processus principal.

Explication

Le conteneur s’arrête lorsque son processus principal prend fin, car sa durée de vie est liée à celle de ce processus. Une connexion réseau active ne suffit pas à maintenir le conteneur en marche si ce processus est terminé.

17. Quelle commande permet de voir les conteneurs arrêtés en plus de ceux qui sont en cours d’exécution ?

docker run -a
docker ps -a
docker ps
docker stop

docker ps -a

Explication

La commande docker ps -a affiche les conteneurs actifs ainsi que ceux qui sont arrêtés. docker ps, qui peut être confondue avec elle, ne liste que les conteneurs en cours d’exécution.

18. Que se passe-t-il lorsqu’un conteneur est créé sans qu’un nom lui soit précisé ?

Docker reprend le nom du processus principal et lui associe un identifiant.
Docker le laisse sans nom et l’identifie uniquement par son adresse réseau.
Docker lui attribue un nom dérivé de l’image et lui associe un identifiant.
Docker lui attribue un nom généré aléatoirement et lui associe un identifiant.

Docker lui attribue un nom généré aléatoirement et lui associe un identifiant.

Explication

Chaque conteneur possède un identifiant et un nom, que Docker génère aléatoirement si aucun nom n’est indiqué. Le nom de l’image ne devient pas automatiquement le nom du conteneur.

19. Vous voulez afficher les conteneurs associés au label « env=prod ». Quelle commande convient ?

docker ps -n env=prod
docker ps --no-trunc env=prod
docker ps --size env=prod
docker ps -f label=env=prod

docker ps -f label=env=prod

Explication

L’option -f applique un filtre, notamment sur un label comme env=prod. --size affiche des informations d’espace disque et ne sert pas à sélectionner les conteneurs selon un label.

20. Quelle séquence permet de lancer un conteneur en arrière-plan, puis de l’arrêter et de le supprimer ?

docker run -d, puis docker stop, puis docker rm
docker run, puis docker stop, puis docker ps
docker run -d, puis docker rm, puis docker stop
docker run -it, puis docker rm, puis docker ps

docker run -d, puis docker stop, puis docker rm

Explication

L’option -d lance le conteneur en arrière-plan, docker stop l’arrête, puis docker rm le supprime. La suppression avec docker rm avant l’arrêt ne suit pas la séquence normale pour un conteneur en marche.

21. Pour éviter qu’un service ne bascule automatiquement vers une version potentiellement incompatible, que faut-il faire ?

Nommer le conteneur httpd:2.4, car le nom fixe la version de l’image utilisée.
Préciser un tag de version, par exemple httpd:2.4, au lieu de laisser Docker utiliser latest.
Lancer l’image sans tag, puisque Docker conserve alors la version initialement téléchargée.
Redémarrer régulièrement le conteneur afin qu’il conserve la version la plus récente.

Préciser un tag de version, par exemple httpd:2.4, au lieu de laisser Docker utiliser latest.

Explication

Sans tag explicite, Docker utilise implicitement latest ; préciser un tag comme httpd:2.4 permet de choisir une version déterminée. Donner ce texte comme nom au conteneur ne fixe pas le tag de l’image.

22. Quel réseau Docker est créé par défaut avec l’interface docker0 et des règles automatiques de NAT et de redirection ?

Un réseau bridge dans le sous-réseau 172.18.0.0/16
Un réseau macvlan dans le sous-réseau 172.17.0.0/16
Un réseau bridge dans le sous-réseau 172.17.0.0/16
Un réseau overlay dans le sous-réseau 172.17.0.0/16

Un réseau bridge dans le sous-réseau 172.17.0.0/16

Explication

Docker crée l’interface docker0 et un réseau bridge par défaut dans le sous-réseau 172.17.0.0/16, en gérant automatiquement les règles de NAT et de redirection. Le sous-réseau 172.18.0.0/16 peut être attribué à un autre réseau, mais il ne correspond pas au réseau bridge par défaut décrit ici.

23. Un conteneur n’a pas de port publié : quelle situation décrit correctement son accessibilité ?

L’hôte et les autres équipements peuvent le joindre par son IP interne
Les autres équipements peuvent le joindre par son IP interne, mais l’hôte ne le peut pas
Ni l’hôte ni les autres équipements ne peuvent le joindre par son IP interne
L’hôte peut le joindre par son IP interne, mais les autres équipements du réseau n’y accèdent pas

L’hôte peut le joindre par son IP interne, mais les autres équipements du réseau n’y accèdent pas

Explication

Sans publication de port, l’hôte peut joindre le conteneur à son adresse IP interne, tandis que les autres équipements du réseau ne le peuvent pas. La possibilité de joindre cette adresse depuis l’hôte ne rend pas le service accessible aux autres équipements.

24. Quelle différence y a-t-il entre `docker run -p 80` et `docker run -p 80:80` pour la publication des ports ?

Les deux commandes choisissent un port hôte aléatoire, mais la seconde publie tous les ports du conteneur
La première commande choisit un port hôte aléatoire pour le port 80 du conteneur, tandis que la seconde fixe le port hôte à 80
Les deux commandes fixent le port hôte à 80, mais la seconde change le port du conteneur
La première commande fixe le port hôte à 80, tandis que la seconde choisit un port hôte aléatoire pour le conteneur

La première commande choisit un port hôte aléatoire pour le port 80 du conteneur, tandis que la seconde fixe le port hôte à 80

Explication

Avec `-p 80`, Docker publie le port 80 du conteneur sur un port hôte choisi aléatoirement ; `-p 80:80` associe le port 80 de l’hôte à celui du conteneur. La commande avec deux numéros ne choisit donc pas un port hôte aléatoire.

25. Pourquoi exécuter `docker pull` avant `docker run` lorsqu’on veut lancer une image ?

Pour afficher la consommation des conteneurs avant de choisir une image
Pour supprimer l’ancien conteneur avant de télécharger une image de remplacement
Pour conserver dans un volume les données du conteneur qui sera lancé
Pour télécharger l’image à l’avance et ne pas attendre son téléchargement au lancement

Pour télécharger l’image à l’avance et ne pas attendre son téléchargement au lancement

Explication

`docker pull` télécharge l’image à l’avance, ce qui évite d’attendre ce téléchargement au moment où `docker run` lance le conteneur. La suppression de l’ancien conteneur intervient dans le processus de mise à jour d’un service, et non dans le rôle de `docker pull`.

26. Quelle séquence permet de mettre à jour un service avec une nouvelle image Docker ?

Supprimer l’ancien conteneur, lancer un nouveau conteneur, puis télécharger l’image mise à jour
Télécharger la nouvelle image, remplacer l’image locale, puis conserver l’ancien conteneur en service
Télécharger la nouvelle image, supprimer l’ancien conteneur, puis en lancer un nouveau avec cette image
Lancer un nouveau conteneur, supprimer la nouvelle image, puis télécharger l’image utilisée

Télécharger la nouvelle image, supprimer l’ancien conteneur, puis en lancer un nouveau avec cette image

Explication

La mise à jour consiste à télécharger la nouvelle image, à supprimer l’ancien conteneur, puis à lancer un nouveau conteneur à partir de cette image. Conserver l’ancien conteneur en service ne réalise pas son remplacement par la nouvelle version.

27. Lors du remplacement d’un conteneur par une nouvelle version, que deviennent les données qui n’étaient pas conservées dans un volume ?

Elles sont transférées dans le volume utilisé par le nouveau conteneur
Elles sont automatiquement copiées dans le nouveau conteneur
Elles sont perdues avec la suppression de l’ancien conteneur
Elles sont conservées sur l’hôte sous forme d’image locale

Elles sont perdues avec la suppression de l’ancien conteneur

Explication

Les données présentes uniquement dans le conteneur sont perdues lorsque celui-ci est supprimé pour être remplacé. À l’inverse, les données conservées dans un volume persistent lors du remplacement.

28. Deux conteneurs sont rattachés au réseau bridge par défaut : quelle communication est possible entre eux ?

Ils communiquent entre eux uniquement si leurs ports hôte sont différents
Ils ne communiquent entre eux qu’au moyen de l’option `--link`
Ils communiquent entre eux seulement après avoir été rattachés à des réseaux distincts
Ils peuvent communiquer entre eux sur ce réseau

Ils peuvent communiquer entre eux sur ce réseau

Explication

Les conteneurs rattachés au réseau bridge par défaut peuvent communiquer entre eux. Des réseaux distincts servent plutôt à isoler des groupes de conteneurs, et ne sont pas requis pour cette communication sur le bridge par défaut.

29. Pour isoler deux groupes de services Docker, quelle démarche faut-il appliquer ?

Créer un réseau commun puis distinguer les groupes par leurs adresses IP internes
Créer des réseaux dédiés puis rattacher chaque conteneur au réseau voulu lors de son lancement
Publier des ports différents puis rattacher tous les conteneurs au bridge par défaut
Lancer tous les conteneurs sur le bridge par défaut puis désactiver leur DNS intégré

Créer des réseaux dédiés puis rattacher chaque conteneur au réseau voulu lors de son lancement

Explication

L’isolation de groupes se réalise en créant des réseaux Docker dédiés et en rattachant chaque conteneur au réseau voulu lors de son lancement. Publier des ports différents ne remplace pas cette séparation par réseaux.

Révisez avec les flashcards

Mémorisez les réponses avec 94 flashcards sur Docker et conteneurisation.

Que décrit l’Infrastructure as Code (IaC) dans des fichiers ou des recettes ?

Le fonctionnement d’une infrastructure afin de pouvoir la reproduire automatiquement.

Qu’est-ce qu’un conteneur informatique ?

Une enveloppe virtuelle qui distribue une application et ses composants.

À quoi sert une image Docker ?

À servir de référence immuable pour créer des conteneurs.

Voir les flashcards →

Approfondir avec la fiche

Consultez la fiche de révision complète sur Docker et conteneurisation.

Voir la fiche →

Cours similaires

UML et modélisation des systèmes PLM

Informatique et outils bureautiques

Initiation à l’informatique et aux logiciels

Architecture matérielle et démarrage

Commandes Linux et environnement shell

Essentiel de l’IA générative

Intelligence Artificielle

Crée tes propres QCM

Importe ton cours et l'IA génère des QCM avec corrections en 30 secondes.

Générateur de QCM