CHAPITRE 1 — DevOps / DevSecOps /
SRE / Platform Engineering / FinOps /
MLOps
1) Définition et fondamentaux DevOps
Q1. Définir DevOps et expliquer son objectif principal.
Réponse :
DevOps est une approche qui combine des pratiques, une culture et des outils visant à
améliorer la collaboration entre développement et opérations afin de permettre la livraison
de logiciels à haute vélocité, tout en garantissant un niveau élevé de qualité et de fiabilité.
Son objectif principal est de réduire le délai entre l’idéation et la mise en production grâce à
l’automatisation et à l’amélioration continue.
Q2. Quels sont les piliers fondamentaux de DevOps ?
Réponse :
Les piliers fondamentaux du DevOps sont :
1. Culture : collaboration, transparence et responsabilité partagée
2. Automatisation : automatiser tests, intégration, déploiement
3. Mesure (Measurement) : suivi des performances, qualité, incidents
4. Partage (Sharing) : documentation, feedback, transversalité
Ces piliers sont souvent résumés par : Culture + Automation + Measurement +
Sharing.
Q3. DevOps est-il une équipe ou un outil ?
Réponse :
Non. DevOps n’est ni une équipe séparée ni un outil. Il s’agit d’une transformation
organisationnelle basée sur la collaboration entre équipes, et sur l’implémentation de
pratiques et d’autatisations permettant une livraison continue plus fiable.
Q4. Pourquoi DevOps est-il considéré comme un processus continu ?
Réponse :
DevOps s’inscrit dans une logique de continual improvement, car l’environnement, les
exigences et les risques évoluent constamment. Il nécessite donc des itérations
permanentes d’amélioration sur les pipelines, la surveillance, la sécurité, l’automatisation et
la collaboration.
2) Cycle DevOps (CD / CT / CI / CD / Monitoring)
Q5. Expliquer la notion de Continuous Integration (CI).
Réponse :
La CI est une pratique qui consiste à intégrer fréquemment de petits changements de code
dans un dépôt central, et à valider automatiquement ces changements via un pipeline de
build et de tests. Elle permet de détecter tôt les erreurs et de réduire le coût des défauts.
Q6. Quel est le rôle du SCM dans la phase de continuous development ?
Réponse :
Le SCM (Source Code Management) centralise le code, conserve l’historique des
modifications, permet la collaboration simultanée et facilite le rollback en cas de déploiement
défectueux. Il constitue un prérequis indispensable à la CI/CD.
Q7. Donner des exemples d’outils associés aux étapes DevOps.
Réponse :
● SCM : Git, SVN
● CI/CD : Jenkins
● Testing : Selenium, JUnit
● Containerisation : Docker
● Configuration management : Ansible, Puppet
● Monitoring : ELK, Prometheus, Nagios
Q8. Comment tous les outils DevOps fonctionnent-ils ensemble dans
une chaîne CI/CD ?
Réponse :
Les développeurs poussent le code sur Git, Jenkins récupère le code, exécute build et tests,
puis les outils de gestion de configuration provisionnent les environnements et déclenchent
le déploiement. Enfin, des outils de monitoring surveillent les systèmes et déclenchent des
alertes en cas d’anomalies.
3) DevSecOps
Q9. Définir DevSecOps et expliquer pourquoi il est devenu
indispensable.
Réponse :
DevSecOps est l’extension de DevOps intégrant la sécurité à chaque étape du cycle de vie
logiciel (SDLC). Il est indispensable en raison de la multiplication des surfaces d’attaque
liées aux microservices, containers, cloud, et dépendances open source.
Q10. Citer des pratiques DevSecOps intégrables dans un pipeline CI/CD.
Réponse :
● Pre-commit hooks
● SCA (analyse de dépendances)
● SAST (analyse statique de code)
● DAST (tests dynamiques)
● Scans de sécurité des containers
● Secret management
● Security sur IaC
Q11. Pourquoi “shift-left security” est un principe clé ?
Réponse :
Shift-left signifie déplacer la sécurité vers les phases initiales du développement. Cela
permet une détection précoce des vulnérabilités, un coût de correction réduit, et une
réduction des risques en production.
4) SRE
Q12. Définir SRE et son but principal.
Réponse :
Le Site Reliability Engineering est une discipline visant à assurer la fiabilité des systèmes de
manière durable via des principes d’ingénierie logicielle. Son objectif principal est d’assurer
un niveau de fiabilité mesurable et acceptable tout en permettant l’innovation.
Q13. Différencier SLA, SLO, SLI.
Réponse :
● SLI : indicateur mesuré (ex : latence, taux d’erreur)
● SLO : objectif interne basé sur des SLI (ex : 99.9% uptime)
● SLA : engagement contractuel envers l’utilisateur (et pénalités)
Q14. Qu’est-ce que le “toil” en SRE ?
Réponse :
Le toil désigne les tâches répétitives, manuelles, non scalables et à faible valeur ajoutée (ex
: redémarrer des services). Un objectif SRE majeur est de réduire le toil via automatisation.
Q15. Quels sont les 5 Golden Signals ?
Réponse :
1. Latency
2. Traffic
3. Errors
4. Saturation
5. Availability
5) Autres disciplines : Platform Eng / FinOps / MLOps
Q16. Définir Platform Engineering.
Réponse :
Le Platform Engineering consiste à concevoir et maintenir des plateformes internes
fournissant aux équipes dev des services et standards réutilisables permettant la livraison
plus rapide et plus fiable.
Q17. Définir FinOps et ses étapes principales.
Réponse :
FinOps est un cadre opérationnel visant à maximiser la valeur business du cloud via
accountability financière et collaboration. Ses étapes :
Analyse → Benchmarking → Optimization → Negotiation.
Q18. Définir MLOps.
Réponse :
MLOps est l’application des pratiques DevOps au cycle de vie des modèles machine
learning, incluant entraînement, déploiement, monitoring, reproductibilité et gouvernance.
CHAPITRE 2 — Docker / Docker
Compose / Kubernetes
Je vais te donner 25 questions ici (très bonnes, niveau entretien).
Docker : concepts
Q1. Différencier virtualisation et containerisation.
Réponse :
La virtualisation exécute plusieurs VMs avec leurs OS complets, ce qui augmente
l’overhead. La containerisation exécute plusieurs containers partageant le même kernel,
offrant un démarrage plus rapide, une meilleure efficacité et une portabilité supérieure.
Q2. Définir une image Docker et un container Docker.
Réponse :
Une image Docker est un modèle immuable contenant l’application et ses dépendances. Un
container est l’instance en cours d’exécution de cette image.
Q3. Comment Docker assure-t-il l’isolation ?
Réponse :
L’isolation est assurée via namespaces (isolation des processus, réseau, FS) et cgroups
(limitation et gestion CPU/MEM/disk).
Q4. Qu’est-ce qu’un Dockerfile et quelle est sa finalité ?
Réponse :
Un Dockerfile est un fichier déclaratif définissant la construction d’une image Docker via des
instructions successives, permettant reproductibilité et automatisation.
Q5. Donner des bonnes pratiques de Dockerfile.
Réponse :
● Tag explicite pour base image
● Minimiser layers (combiner RUN)
● Utiliser un user non-root
● Utiliser .dockerignore
● Multi-stage builds
● Base image minimaliste (alpine)
Docker-compose
Q6. Définir Docker Compose.
Réponse :
Docker Compose est un outil permettant d’orchestrer des applications multi-containers via
un fichier YAML décrivant services, réseaux et volumes.
Q7. Quel est le rôle de depends_on dans docker-compose ?
Réponse :
depends_on définit des dépendances entre services afin d’assurer l’ordre de démarrage
logique. Il ne garantit pas la disponibilité applicative, seulement le démarrage.
Q8. Quelle est la différence entre volumes et bind mounts ?
Réponse :
Les volumes sont gérés par Docker et stockés dans un espace dédié. Les bind mounts
mappent un répertoire hôte spécifique vers le container.
Kubernetes
Q9. Pourquoi Kubernetes a-t-il été créé ?
Réponse :
Kubernetes répond à la complexité de gestion de milliers de containers, en automatisant
déploiement, scaling, disponibilité et self-healing.
Q10. Définir un pod.
Réponse :
Le pod est la plus petite unité déployable. Il encapsule un ou plusieurs containers partageant
réseau et stockage.
Q11. Différence entre Deployment et StatefulSet.
Réponse :
Deployment gère des workloads stateless. StatefulSet gère des workloads stateful
nécessitant identités stables et stockage persistant.
Q12. Quel est le rôle d’un Service dans Kubernetes ?
Réponse :
Un Service fournit un point d’accès stable (IP/DNS) vers des pods dynamiques et assure
l’équilibrage de charge.
Q13. Différence ConfigMap vs Secret.
Réponse :
ConfigMap stocke des configurations non sensibles. Secret stocke des informations
sensibles (tokens, mots de passe), avec mécanismes de protection supplémentaires.
CHAPITRE 3 — Linux / Shell / Git / Maven
/ npm
Je continue et je t’en donne un lot très solide.
Linux / Shell
Q1. Définir le kernel Linux.
Réponse :
Le kernel est le noyau du système d’exploitation responsable de la gestion mémoire,
processus, I/O, fichiers et périphériques, constituant le composant central de Linux.
Q2. Définir un shell.
Réponse :
Le shell est un interpréteur de commandes permettant à l’utilisateur de communiquer avec le
système en traduisant les commandes en appels compréhensibles par le noyau.
Q3. Pourquoi utiliser #!/usr/bin/env bash au lieu de
#!/usr/bin/bash ?
Réponse :
env bash améliore la portabilité car il recherche bash dans le PATH, contrairement à un
chemin statique.
Q4. Comment déboguer un script shell ?
Réponse :
On peut utiliser set -x pour afficher l’exécution des commandes et set -e pour arrêter en
cas d’erreur.
Git
Q5. Définir Git et expliquer pourquoi il est “distributed”.
Réponse :
Git est un système de contrôle de version distribué où chaque développeur possède une
copie complète de l’historique localement, améliorant vitesse, résilience et flexibilité.
Q6. Différence entre git fetch et git pull.
Réponse :
fetch récupère les changements sans les fusionner. pull exécute fetch + merge/rebase.
Q7. Définir le staging area.
Réponse :
Le staging area est une zone intermédiaire permettant de sélectionner précisément les
modifications à inclure dans un commit.
Maven / npm
Q8. Qu’est-ce que la gestion des dépendances et pourquoi est-elle
critique ?
Réponse :
C’est la gestion des bibliothèques externes nécessaires au projet. Elle est critique pour
garantir reproductibilité, cohérence des builds, sécurité et compatibilité.
Q9. Différence entre dépendance directe et transitive.
Réponse :
Une dépendance directe est explicitement déclarée. Une dépendance transitive est requise
indirectement par une dépendance directe.
CHAPITRE 4 — Jenkins / GitHub Actions
/ GitOps / ArgoCD
Q1. Définir Jenkins et son rôle en CI.
Réponse :
Jenkins est un serveur open-source d’intégration continue automatisant build, tests et
déploiements via des jobs et pipelines extensibles par plugins.
Q2. Pourquoi Jenkins est considéré comme extensible ?
Réponse :
Grâce à son écosystème de plugins supportant SCM, build tools, test frameworks,
analyzers, notifications et intégrations cloud.
Q3. Différence Jenkins vs GitHub Actions.
Réponse :
Jenkins est auto-hébergé, extensible via plugins, très flexible mais requiert maintenance.
GitHub Actions est intégré GitHub, pipeline-as-code simple, et gère l’infrastructure via
runners.
Q4. Définir GitOps.
Réponse :
GitOps est une approche de gestion des environnements où Git représente la source de
vérité. Les changements sont appliqués automatiquement via un moteur de synchronisation
déclaratif.
Q5. Pourquoi GitOps est basé sur le déclaratif ?
Réponse :
Le déclaratif décrit l’état souhaité plutôt que la suite d’étapes. Cela améliore traçabilité,
audit, reproductibilité et rollback.