--- title: "Guide d'entretien technique — Candidat 2 (Junior DevOps/Cloud)" type: career area: career status: draft interview_role: "Interviewer (Me)" category: "Conducting Interview" target_candidate: "Candidat 2 (Junior DevOps/Cloud)" role: "DevOps / Cloud Engineer" stage: "Technical Interview Assessment" date: 2026-09-08 created: 2026-09-08 updated: 2026-09-08 tags: - career - conducting-interviews --- # Guide d’entretien technique Profil ciblé : ingénieure junior DevOps/Cloud avec des expériences en traitements batch serverless, automatisation CI/CD, conteneurs, infrastructure AWS et supervision. Contexte du poste : exploitation de plusieurs applications métier, amélioration des pipelines CI/CD, déploiement AWS/Terraform, supervision, diagnostic et automatisation. > Entretien volontairement centré à 100 % sur le DevOps. Les questions sont formulées sans citer le nom des applications internes. ## Format recommandé — 90 minutes - 10 min : parcours et responsabilités réelles - 10 min : Linux, Git et Docker - 20 min : Kubernetes et exploitation du cluster - 15 min : migration AWS vers Kubernetes on-premises - 10 min : AWS et traitements batch - 10 min : Terraform et Infrastructure as Code - 5 min : CI/CD et observabilité - 10 min : cas pratique final Pour 90 minutes, sélectionner environ 18 à 22 questions. Les questions marquées **Prioritaire** sont les plus discriminantes. ## 1. Parcours et validation du CV ### 1. Contribution personnelle — Prioritaire **FR :** Choisissez l’expérience DevOps la plus importante de votre CV. Quel était le problème initial, quelles parties avez-vous réalisées personnellement et quel résultat avez-vous observé ? **EN:** Choose the most important DevOps experience on your résumé. What was the initial problem, which parts did you personally implement, and what outcome did you observe? **Attendu :** contribution personnelle clairement séparée du travail collectif, contraintes, décisions, difficultés et résultat observable. #### Réponse attendue détaillée Une bonne réponse précise : - l’état initial du système ; - le problème opérationnel ou métier ; - les composants réellement configurés par la candidate ; - les décisions proposées ou appliquées ; - la méthode de validation ; - un résultat mesurable. Une simple énumération d’AWS, Docker, Terraform ou Jenkins ne suffit pas. La candidate doit expliquer comment les outils étaient reliés et ce qu’elle a personnellement livré. ### 2. Réduction du temps de configuration **FR :** Vous indiquez avoir réduit la configuration CI/CD de plusieurs jours à quelques minutes. Comment cette durée a-t-elle été mesurée, quelles étapes ont été automatisées et lesquelles sont restées manuelles ? **EN:** You state that you reduced CI/CD configuration time from several days to a few minutes. How was that measured, which steps were automated, and which remained manual? **Attendu :** comparaison avant/après, périmètre mesuré, entrées, sorties, validations et limites. #### Réponse attendue détaillée La candidate doit décrire le processus avant l’automatisation, les informations demandées à l’utilisateur et les éléments générés. Elle doit distinguer le temps humain économisé de la durée d’exécution du pipeline. Une réponse solide mentionne aussi : - les technologies et variantes prises en charge ; - la validation des entrées ; - le traitement des secrets ; - les approbations conservées ; - les cas non automatisés ; - la manière de vérifier qu’un pipeline généré est correct. ### 3. Choix d’architecture **FR :** Donnez un exemple de choix entre deux solutions DevOps. Quelles contraintes avez-vous comparées et quel compromis avez-vous accepté ? **EN:** Give an example of choosing between two DevOps solutions. Which constraints did you compare, and what trade-off did you accept? **Attendu :** alternatives concrètes, coût, sécurité, compétences, exploitation, délai et maintenabilité. #### Réponse attendue détaillée Il n’est pas attendu d’une candidate junior qu’elle ait décidé seule. Elle doit cependant pouvoir expliquer le raisonnement collectif. Une bonne réponse compare au moins deux options réalistes, par exemple EKS et ECS Fargate, Jenkins et GitHub Actions, ou traitement planifié et traitement événementiel. ### 4. Problème difficile **FR :** Décrivez un incident ou un problème technique que vous n’avez pas résolu immédiatement. Comment avez-vous organisé le diagnostic et à quel moment avez-vous demandé de l’aide ? **EN:** Describe an incident or technical problem you did not solve immediately. How did you organize the investigation, and when did you ask for help? **Attendu :** reproduction, collecte de preuves, hypothèses, essais isolés, communication et apprentissage. #### Réponse attendue détaillée Une démarche structurée consiste à : 1. clarifier le symptôme et son impact ; 2. consulter les changements récents ; 3. collecter logs, métriques et événements ; 4. formuler une hypothèse ; 5. modifier un seul facteur à la fois ; 6. demander de l’aide avec les preuves déjà obtenues ; 7. vérifier puis documenter la solution. ### 5. Maintenance et exploitation **FR :** Le poste comprend de la maintenance, des incidents, des mises à niveau et de petites améliorations. Qu’est-ce qui vous intéresse dans ce travail opérationnel ? **EN:** The role includes maintenance, incidents, upgrades, and small improvements. What interests you about this operational work? **Attendu :** fiabilité, compréhension de l’existant, amélioration progressive, utilisateurs et responsabilité opérationnelle. #### Réponse attendue détaillée La candidate doit comprendre qu’un poste DevOps ne consiste pas uniquement à créer une nouvelle infrastructure. Il faut aussi diagnostiquer, sécuriser, documenter, réduire le risque des changements et améliorer progressivement un système existant. ## 2. Linux, Git et Docker ### 6. Diagnostic Linux — Prioritaire **FR :** Une machine ou un conteneur devient lent. Quelles vérifications Linux effectuez-vous avant de conclure à un manque de ressources ? **EN:** A machine or container becomes slow. Which Linux checks do you perform before concluding that it lacks resources? **Attendu :** CPU, mémoire, swap, disque, I/O, processus, réseau, logs et corrélation temporelle. #### Réponse attendue détaillée La candidate devrait examiner : - charge CPU et processus dominants ; - mémoire disponible, swap et éventuel OOM kill ; - espace disque et inodes ; - latence et saturation I/O ; - sockets et connexions réseau ; - logs système et applicatifs ; - heure de début et changements récents. Ajouter des ressources sans identifier le goulot peut seulement reporter le problème. ### 7. Script Bash fiable **FR :** Comment écrivez-vous un script Bash utilisé dans un pipeline pour qu’il échoue proprement et ne continue pas après une commande critique en erreur ? **EN:** How do you write a Bash script used in a pipeline so that it fails cleanly and does not continue after a critical command fails? **Attendu :** mode strict, validation des entrées, quoting, codes de sortie, `trap`, logs et idempotence. #### Réponse attendue détaillée Le script doit notamment : - utiliser `set -Eeuo pipefail` lorsque compatible ; - citer les variables ; - vérifier les paramètres obligatoires ; - propager un code de sortie non nul ; - nettoyer les ressources temporaires avec `trap` ; - ne pas afficher de secret ; - être relançable sans produire d’état incohérent. Le mode strict ne remplace pas la gestion explicite des erreurs attendues. ### 8. Git et protection de la branche principale **FR :** Quelles protections mettez-vous en place pour empêcher qu’un changement non validé soit déployé depuis la branche principale ? **EN:** Which protections do you configure to prevent an unvalidated change from being deployed from the main branch? **Attendu :** pull request, revue, checks obligatoires, branche protégée, permissions, signatures éventuelles et environnement protégé. #### Réponse attendue détaillée La branche principale doit refuser les pushes directs, exiger une revue et attendre les contrôles CI requis. La production doit ajouter une seconde frontière : environnement protégé, approbation, rôle AWS limité et artifact immuable. Une condition présente uniquement dans le fichier du pipeline n’est pas une frontière de sécurité suffisante si l’auteur peut modifier cette condition dans la même branche. ### 9. Image Docker de production **FR :** Comment construisez-vous une image Docker de production petite, reproductible et sécurisée ? **EN:** How do you build a small, reproducible, and secure production Docker image? **Attendu :** multi-stage, base minimale fixée, utilisateur non root, `.dockerignore`, aucun secret, scan et tag immuable. #### Réponse attendue détaillée Une image de production doit : - séparer compilation et runtime ; - contenir uniquement les dépendances nécessaires ; - fixer les versions ou digests importants ; - s’exécuter sans privilèges root ; - exclure dépôt Git, fichiers temporaires et secrets ; - définir clairement la commande de démarrage ; - être analysée pour les vulnérabilités ; - être publiée avec un identifiant immuable lié au commit. ### 10. Conteneur qui redémarre — Prioritaire **FR :** Un conteneur démarre puis redémarre continuellement. Dans quel ordre recherchez-vous la cause ? **EN:** A container starts and then continuously restarts. In what order do you investigate the cause? **Attendu :** raison d’arrêt, code de sortie, logs précédents, commande, configuration, health check, réseau, permissions et mémoire. #### Réponse attendue détaillée Commencer par les événements de l’orchestrateur, la raison d’arrêt, le code de sortie et les logs du conteneur précédent. Vérifier ensuite : - `ENTRYPOINT` et arguments ; - variables et secrets ; - accès aux dépendances ; - health check et délai de grâce ; - architecture de l’image ; - permissions sur les fichiers et ports ; - limites CPU et mémoire ; - éventuel OOM kill. Il faut éviter de modifier plusieurs paramètres simultanément avant d’avoir une hypothèse. ### 11. Docker Compose **FR :** Quel rôle Docker Compose joue-t-il en développement et quelles garanties supplémentaires attendez-vous d’un orchestrateur en production ? **EN:** What role does Docker Compose play in development, and which additional guarantees do you expect from a production orchestrator? **Attendu :** environnement local reproductible, puis scheduling, remplacement, haute disponibilité, autoscaling, secrets et rollout. #### Réponse attendue détaillée Compose permet de lancer localement plusieurs services, réseaux et volumes de manière reproductible. Un orchestrateur apporte notamment le remplacement automatique, le déploiement progressif, la distribution multi-nœuds, la gestion des ressources, l’intégration des secrets et la découverte de services. ## 3. Kubernetes, EKS et ECS Fargate ### 12. Objets Kubernetes **FR :** Expliquez les rôles d’un Pod, d’un Deployment, d’un Service, d’un ConfigMap, d’un Secret et d’un Ingress. **EN:** Explain the roles of a Pod, Deployment, Service, ConfigMap, Secret, and Ingress. **Attendu :** unité d’exécution, état désiré, réseau stable, configuration, données sensibles et routage HTTP. #### Réponse attendue détaillée - **Pod :** unité d’exécution remplaçable. - **Deployment :** maintient l’état désiré et gère les rollouts. - **Service :** fournit une adresse stable vers les Pods. - **ConfigMap :** configuration non sensible. - **Secret :** données sensibles, nécessitant aussi chiffrement et RBAC adaptés. - **Ingress :** règles HTTP/HTTPS appliquées par un Ingress Controller. Un Secret Kubernetes encodé en base64 n’est pas chiffré par ce seul fait. ### 13. Readiness et liveness — Prioritaire **FR :** Quelle différence existe-t-il entre readiness et liveness ? Pourquoi est-il dangereux de tester une dépendance externe dans la liveness ? **EN:** What is the difference between readiness and liveness? Why is testing an external dependency in liveness dangerous? **Attendu :** readiness retire du trafic, liveness redémarre, risque de redémarrage en cascade. #### Réponse attendue détaillée La liveness vérifie que le processus doit rester en vie ; son échec provoque un redémarrage. La readiness détermine si l’instance peut recevoir du trafic. Si la liveness échoue quand une base ou un service secondaire est indisponible, tous les Pods peuvent redémarrer et aggraver l’incident. Les checks doivent être rapides, bornés par un timeout et adaptés à leur objectif. ### 14. Pod en `CrashLoopBackOff` **FR :** Un Pod est en `CrashLoopBackOff`. Quelles informations et commandes utilisez-vous pour diagnostiquer le problème ? **EN:** A Pod is in `CrashLoopBackOff`. Which information and commands do you use to diagnose the problem? **Attendu :** `describe`, événements, logs courants et précédents, état/exit code, configuration, probes et ressources. #### Réponse attendue détaillée La candidate doit citer une démarche proche de : - `kubectl describe pod` pour les événements et états ; - `kubectl logs` et `kubectl logs --previous` ; - inspection de la commande, de l’image et des variables ; - vérification des ConfigMaps, Secrets, volumes et ServiceAccounts ; - vérification des probes et limites mémoire ; - comparaison avec un Pod sain ou la révision précédente. ### 15. Déploiement Kubernetes sans interruption **FR :** Comment configurez-vous un déploiement Kubernetes pour réduire le risque d’interruption pendant une mise à jour ? **EN:** How do you configure a Kubernetes deployment to reduce the risk of downtime during an update? **Attendu :** plusieurs replicas, rolling update, readiness, `maxUnavailable`, `maxSurge`, arrêt gracieux et rollback. #### Réponse attendue détaillée Le système doit disposer de capacité redondante. Le Deployment lance progressivement les nouveaux Pods, attend leur readiness et retire les anciens selon `maxUnavailable` et `maxSurge`. Il faut aussi prévoir : - délai de démarrage réaliste ; - arrêt gracieux et drainage des requêtes ; - image immuable ; - métriques pendant le rollout ; - rollback ; - changements de données compatibles avec les deux versions. ### 16. Requests, limits et autoscaling **FR :** À quoi servent les requests et limits CPU/mémoire ? Sur quelles métriques baseriez-vous un autoscaling ? **EN:** What are CPU/memory requests and limits used for? Which metrics would you use for autoscaling? **Attendu :** scheduling, réservation, throttling CPU, OOM mémoire, HPA et métriques liées à la charge réelle. #### Réponse attendue détaillée Les requests guident le scheduler et représentent les ressources garanties. Les limits plafonnent la consommation : le CPU peut être throttlé et un dépassement mémoire peut tuer le conteneur. L’autoscaling peut utiliser CPU ou mémoire, mais une métrique métier comme la profondeur d’une file, le nombre de travaux en attente ou la concurrence active peut mieux représenter la demande. Les seuils doivent être mesurés avec une charge réaliste. ### 17. EKS ou ECS Fargate — Prioritaire **FR :** Dans quels cas choisiriez-vous EKS, et dans quels cas ECS Fargate serait-il plus simple ? **EN:** When would you choose EKS, and when would ECS Fargate be simpler? **Attendu :** besoins Kubernetes et écosystème contre simplicité AWS, compétences, contrôle, coût et charge opérationnelle. #### Réponse attendue détaillée EKS est pertinent si l’organisation standardise Kubernetes ou nécessite ses primitives et son écosystème. ECS Fargate est souvent plus simple pour exécuter des services ou batches conteneurisés sans besoin Kubernetes explicite. La candidate doit considérer : - compétences de l’équipe ; - effort d’exploitation ; - besoin de portabilité ; - réseau et sécurité ; - autoscaling ; - observabilité ; - coût et niveau de contrôle. ### 18. Rôles d’une tâche ECS **FR :** Quelle différence existe-t-il entre le rôle d’exécution ECS et le rôle de tâche ECS ? **EN:** What is the difference between the ECS task execution role and the ECS task role? **Attendu :** rôle d’exécution pour lancer la tâche ; rôle de tâche pour les appels AWS effectués par l’application. #### Réponse attendue détaillée Le rôle d’exécution permet à ECS de récupérer l’image, publier les logs et lire les secrets nécessaires au démarrage. Le rôle de tâche est assumé par le code du conteneur pour appeler S3 ou d’autres services AWS. Les deux rôles doivent appliquer le moindre privilège et rester séparés pour faciliter la sécurité et l’audit. ## 4. AWS et traitements batch ### 19. Architecture batch AWS — Prioritaire **FR :** Décrivez une architecture AWS pour traiter périodiquement un grand ensemble de documents, stocker les résultats dans S3 et superviser chaque exécution. **EN:** Describe an AWS architecture for periodically processing a large set of documents, storing the results in S3, and monitoring each execution. **Attendu :** EventBridge, ECS Fargate, S3, IAM, état durable, CloudWatch, idempotence et alerte. #### Réponse attendue détaillée Une règle EventBridge peut déclencher une tâche ECS Fargate. La tâche lit les entrées autorisées, traite les documents de manière bornée puis écrit les résultats dans S3. L’architecture doit inclure : - identifiant unique d’exécution ; - rôle IAM limité aux préfixes nécessaires ; - état ou checkpoint durable ; - opérations idempotentes ; - logs structurés ; - métriques de progression, succès et rejet ; - alarme sur échec ou absence de progression. ### 20. Reprise après interruption **FR :** Un traitement d’un million de documents s’arrête après 650 000. Comment reprenez-vous sans tout recommencer et sans créer de doublons ? **EN:** A one-million-document job stops after 650,000. How do you resume without starting over or creating duplicates? **Attendu :** manifeste, checkpoint durable, statut par unité, clés déterministes, idempotence et rapprochement final. #### Réponse attendue détaillée Le système doit enregistrer hors du conteneur l’identité et l’état de chaque unité de travail. La reprise sélectionne uniquement les éléments absents, échoués ou restés en cours au-delà d’un timeout. Une bonne solution combine : - identifiant métier ou checksum ; - transition d’état atomique ; - résultat écrit sous une clé déterministe ; - checkpoint durable ; - relance sûre ; - comparaison finale entre manifeste source et résultats. ### 21. Fichier volumineux **FR :** Une tâche Fargate dépasse sa mémoire lorsqu’elle traite un fichier très volumineux. Comment corrigez-vous la cause ? **EN:** A Fargate task runs out of memory while processing a very large file. How do you fix the cause? **Attendu :** mesure, streaming, chunks, multipart upload, concurrence limitée et espace éphémère maîtrisé. #### Réponse attendue détaillée Il faut mesurer où la mémoire augmente puis éviter de charger tout le fichier ou tous les résultats. Les options incluent lecture en streaming, traitement par chunks, multipart upload, limitation de concurrence et nettoyage des buffers. L’espace éphémère doit également être surveillé. Augmenter uniquement la mémoire reporte le problème si l’algorithme reste non borné. ### 22. S3 et sécurité **FR :** Comment sécurisez-vous un bucket contenant des documents internes ? **EN:** How do you secure a bucket containing internal documents? **Attendu :** blocage public, TLS, chiffrement, IAM minimal, bucket policy, versioning/rétention et audit. #### Réponse attendue détaillée Le bucket doit bloquer l’accès public, imposer TLS et utiliser un chiffrement adapté. Les rôles IAM sont limités aux actions, buckets et préfixes nécessaires. Il faut aussi considérer : - SSE-S3 ou SSE-KMS selon les exigences ; - politique de bucket ; - versioning et protection contre la suppression ; - journalisation des accès sensibles ; - durée de rétention ; - lifecycle pour les archives et fichiers temporaires. ### 23. EventBridge, retries et doublons **FR :** Une règle EventBridge doit déclencher un traitement. Que prévoyez-vous si la cible échoue ou si le même événement est livré plusieurs fois ? **EN:** An EventBridge rule must trigger a job. What do you plan for if the target fails or the same event is delivered more than once? **Attendu :** retry borné, DLQ, alarme, rôle minimal, identifiant d’exécution et idempotence. #### Réponse attendue détaillée Configurer une politique de retry bornée et une dead-letter queue, puis alerter sur les événements non livrés. Le rôle EventBridge doit pouvoir lancer uniquement la cible nécessaire. La cible ne doit pas supposer une livraison exactement une fois. Un identifiant déterministe lié à l’événement ou à la période métier doit rendre le double déclenchement sans effet indésirable. ### 24. IAM `AccessDenied` **FR :** Une tâche ECS reçoit `AccessDenied` lors d’une écriture dans S3. Comment recherchez-vous précisément la permission manquante ? **EN:** An ECS task receives `AccessDenied` when writing to S3. How do you precisely investigate the missing permission? **Attendu :** identité effective, action et ressource, rôle de tâche, policy IAM, bucket policy, KMS, conditions et CloudTrail. #### Réponse attendue détaillée Il faut identifier l’appel exact, l’ARN de ressource et le principal utilisé. Vérifier ensuite : - rôle de tâche, pas seulement rôle d’exécution ; - policy IAM autorisant l’action précise ; - bucket policy et éventuel deny explicite ; - conditions sur préfixe, VPC endpoint ou organisation ; - permissions et key policy KMS ; - événement CloudTrail lorsque disponible. Ajouter temporairement `AdministratorAccess` n’est pas une correction acceptable. ### 25. Réseau AWS **FR :** Où placez-vous un load balancer public, les tâches ECS/EKS et une base de données dans un VPC ? Comment les tâches privées accèdent-elles aux services AWS ? **EN:** Where do you place a public load balancer, ECS/EKS workloads, and a database in a VPC? How do private workloads access AWS services? **Attendu :** ALB public, workloads et DB privés, security groups par source, NAT ou VPC endpoints. #### Réponse attendue détaillée Un ALB Internet-facing utilise des subnets publics multi-AZ. Les workloads et la base restent dans des subnets privés sans exposition directe. Les security groups autorisent uniquement les flux nécessaires depuis le security group source. Pour accéder aux services AWS, les tâches peuvent utiliser des VPC endpoints lorsque disponibles ou une sortie NAT. Le choix dépend du service, du coût, de la sécurité et du besoin d’accès Internet général. ## 5. Terraform et Infrastructure as Code ### 26. State Terraform — Prioritaire **FR :** Pourquoi le state Terraform est-il sensible ? Comment le partagez-vous et empêchez-vous deux pipelines de le modifier simultanément ? **EN:** Why is Terraform state sensitive? How do you share it and prevent two pipelines from modifying it simultaneously? **Attendu :** backend distant chiffré, IAM, versioning, verrouillage et states séparés. #### Réponse attendue détaillée Le state associe les ressources déclarées aux ressources réelles et peut contenir des valeurs sensibles. Il doit être stocké dans un backend distant chiffré, versionné, protégé par IAM et verrouillé pendant les opérations. Les environnements doivent avoir des states séparés. Le pipeline doit également sérialiser les `apply`. Une variable marquée `sensitive` peut toujours apparaître dans le state. ### 27. `plan` et `apply` **FR :** Comment garantissez-vous que l’infrastructure appliquée correspond au plan qui a été relu et approuvé ? **EN:** How do you ensure that the applied infrastructure matches the plan that was reviewed and approved? **Attendu :** plan sauvegardé, artefact protégé, même commit/variables/versions, verrouillage et approbation. #### Réponse attendue détaillée Le pipeline produit un fichier de plan depuis un commit et un contexte déterminés. Ce plan devient un artefact protégé et l’étape approuvée applique exactement cet artefact. Il faut fixer les providers, empêcher les modifications concurrentes et invalider le plan si le code, les variables ou l’état pertinent ont changé. ### 28. Dérive d’infrastructure **FR :** Une ressource gérée par Terraform a été modifiée manuellement pendant un incident. Que faites-vous après le retour à la normale ? **EN:** A Terraform-managed resource was manually changed during an incident. What do you do after service is restored? **Attendu :** documenter, comparer, décider de la source correcte, mettre à jour le code ou restaurer la ressource. #### Réponse attendue détaillée Un `terraform plan` permet d’identifier la dérive. Il faut comprendre pourquoi la modification a été effectuée, puis soit intégrer la configuration correcte dans le code, soit remettre la ressource dans son état déclaré. L’objectif est de retrouver une source de vérité unique sans écraser aveuglément un changement encore nécessaire au service. ### 29. Modules et environnements **FR :** Comment organisez-vous Terraform pour développement, QA et production sans copier tout le code ni partager un seul state ? **EN:** How do you organize Terraform for development, QA, and production without copying all the code or sharing a single state? **Attendu :** modules simples, racines par environnement, variables explicites, backends et states séparés. #### Réponse attendue détaillée Les composants réellement communs peuvent devenir des modules. Chaque environnement conserve une configuration racine, ses valeurs, son backend et son state. Les différences importantes doivent rester visibles plutôt que cachées derrière de nombreuses conditions. Un seul state pour tous les environnements crée un rayon d’impact et une contention inutiles. ### 30. Échec partiel d’un `terraform apply` **FR :** Un `terraform apply` échoue après avoir créé certaines ressources. Relancez-vous immédiatement ? Quelle démarche suivez-vous ? **EN:** A `terraform apply` fails after creating some resources. Do you rerun it immediately? What process do you follow? **Attendu :** lire l’erreur, préserver state et lock, vérifier le réel, corriger la cause, recalculer le plan puis appliquer. #### Réponse attendue détaillée Terraform enregistre normalement les ressources créées avec succès. Il faut lire l’erreur, vérifier le state et la console AWS, puis corriger la cause avant de produire un nouveau plan. Une ressource créée hors state peut nécessiter un import. Il ne faut ni supprimer le state ni lancer des commandes manuelles destructrices pour « repartir de zéro ». ## 6. CI/CD ### 31. Pipeline de livraison — Prioritaire **FR :** Concevez oralement un pipeline CI/CD pour une application conteneurisée déployée sur AWS. **EN:** Verbally design a CI/CD pipeline for a containerized application deployed on AWS. **Attendu :** contrôles, tests existants, build unique, scan, registry, QA, smoke test, approbation, production et rollback. #### Réponse attendue détaillée Un pipeline cohérent contient : 1. contrôles statiques et tests du dépôt ; 2. build reproductible ; 3. construction d’une image unique ; 4. scan des dépendances et de l’image ; 5. publication avec tag immuable ; 6. déploiement automatique en QA ; 7. smoke test sur l’environnement ; 8. approbation de production ; 9. rollout progressif ; 10. vérification par métriques ; 11. rollback automatique ou contrôlé. L’image validée doit être la même que celle promue en production. ### 32. GitHub Actions et Jenkins **FR :** Quelles différences pratiques avez-vous rencontrées entre GitHub Actions et Jenkins ? Quand choisiriez-vous l’un plutôt que l’autre ? **EN:** What practical differences have you encountered between GitHub Actions and Jenkins? When would you choose one over the other? **Attendu :** intégration GitHub et runners contre contrôle Jenkins, plugins, maintenance, réseau, sécurité et compétences. #### Réponse attendue détaillée GitHub Actions s’intègre directement aux événements, permissions et pull requests GitHub. Jenkins offre un contrôle important sur l’hébergement et les agents, mais impose l’exploitation du contrôleur, des plugins, des sauvegardes et des mises à niveau. Le choix dépend des systèmes existants, de l’accès au réseau privé, de la conformité et de la capacité de l’équipe à maintenir la plateforme. ### 33. Authentification AWS depuis le pipeline — Prioritaire **FR :** Comment permettez-vous à GitHub Actions ou Jenkins de déployer sur AWS sans stocker une clé AWS permanente ? **EN:** How do you allow GitHub Actions or Jenkins to deploy to AWS without storing a permanent AWS key? **Attendu :** OIDC lorsque disponible, rôle IAM, STS, credentials temporaires et trust policy limitée. #### Réponse attendue détaillée Avec GitHub Actions, le job peut recevoir un jeton OIDC et assumer un rôle IAM via STS. La trust policy limite le dépôt, la branche ou l’environnement et l’audience. Pour Jenkins, utiliser également une identité de workload ou un rôle attaché à l’agent selon son environnement, plutôt qu’une clé longue durée partagée. Le rôle de déploiement doit rester limité au périmètre nécessaire. ### 34. Pipeline généré incorrect **FR :** Un outil génère un pipeline syntaxiquement valide, mais configuré pour le mauvais environnement. Comment empêchez-vous cette classe d’erreur ? **EN:** A tool generates a syntactically valid pipeline configured for the wrong environment. How do you prevent this class of error? **Attendu :** validation métier, configuration contrôlée, environnements protégés, séparation IAM, plan et tests des modèles. #### Réponse attendue détaillée La validation de syntaxe ne suffit pas. Il faut contrôler la relation entre dépôt, branche, compte AWS, région et environnement. Les identifiants critiques doivent provenir d’une configuration approuvée plutôt que d’un champ libre. Des protections indépendantes doivent limiter l’impact : rôles IAM séparés, approbation de production, branches et environnements protégés, affichage du plan et tests des modèles générés. ### 35. Rollback après pipeline vert **FR :** Le pipeline est vert, mais l’application devient instable après le déploiement. Comment détectez-vous l’échec réel et organisez-vous le rollback ? **EN:** The pipeline is green, but the application becomes unstable after deployment. How do you detect the real failure and organize rollback? **Attendu :** readiness, smoke tests, métriques, image immuable, version précédente et changement de données compatible. #### Réponse attendue détaillée La réussite du job ne prouve pas la santé du service. Le pipeline doit attendre la readiness, exécuter un smoke test et observer erreurs, latence et saturation pendant le rollout. En cas d’échec : 1. arrêter la progression ; 2. restaurer l’image ou la définition précédente ; 3. attendre les health checks ; 4. confirmer le retour à la normale ; 5. conserver les preuves ; 6. analyser la cause racine. ## 7. Observabilité et exploitation ### 36. Prometheus, Grafana et CloudWatch **FR :** Comment répartissez-vous les usages entre Prometheus, Grafana et CloudWatch dans une architecture AWS ? **EN:** How do you divide responsibilities between Prometheus, Grafana, and CloudWatch in an AWS architecture? **Attendu :** métriques applicatives, visualisation, données natives AWS, logs, alarmes et source de vérité claire. #### Réponse attendue détaillée Prometheus collecte des métriques exposées par les workloads et composants compatibles. Grafana visualise plusieurs sources. CloudWatch fournit métriques, logs, événements et alarmes natifs AWS. Une combinaison est possible, mais il faut éviter de dupliquer toutes les données sans besoin, définir où se trouvent les alertes et préciser qui les traite. ### 37. Supervision d’un batch — Prioritaire **FR :** Quelles métriques et alertes minimales mettez-vous en place pour un traitement batch documentaire ? **EN:** Which minimum metrics and alerts do you configure for a document-processing batch job? **Attendu :** lancement, succès, échec, progression, durée, absence de progrès, ressources et erreurs par catégorie. #### Réponse attendue détaillée Le minimum comprend : - exécutions attendues, lancées, réussies et échouées ; - éléments attendus, traités, rejetés et restants ; - durée et débit ; - dernière progression ; - CPU, mémoire et stockage temporaire ; - erreurs d’accès, validation et dépendances ; - absence d’exécution planifiée ; - éléments présents dans une DLQ. Les logs incluent un identifiant d’exécution sans exposer le contenu sensible des documents. ### 38. Alerte de qualité **FR :** Qu’est-ce qui distingue une alerte utile d’une alerte bruyante ? **EN:** What distinguishes a useful alert from a noisy alert? **Attendu :** impact utilisateur, seuil justifié, durée, action possible, ownership, runbook et réduction des doublons. #### Réponse attendue détaillée Une alerte doit correspondre à un problème nécessitant une action. Elle précise le service, l’environnement, l’impact probable, le contexte et le runbook. Les seuils et fenêtres évitent de signaler chaque variation normale. Une alerte sans propriétaire, sans action ou systématiquement ignorée doit être corrigée ou supprimée. ### 39. Tableau de bord opérationnel **FR :** Que mettez-vous sur un dashboard pour permettre à l’équipe de savoir en moins de cinq minutes si le service fonctionne correctement ? **EN:** What do you put on a dashboard so the team can determine within five minutes whether the service is operating correctly? **Attendu :** trafic, erreurs, latence, saturation, santé des dépendances, déploiements et indicateurs métier. #### Réponse attendue détaillée Le dashboard doit présenter les signaux essentiels : volume, taux d’erreur, percentiles de latence, CPU/mémoire, instances saines, files ou travaux en attente et dépendances critiques. Il doit aussi afficher les déploiements récents et quelques indicateurs métier, par exemple nombre de traitements réussis. Un dashboard rempli de métriques système sans lien avec l’expérience utilisateur n’est pas suffisant. ### 40. Communication d’incident **FR :** Une application utilisée sur plusieurs sites devient lente. Que communiquez-vous pendant l’incident et que conservez-vous pour l’analyse après incident ? **EN:** An application used across several sites becomes slow. What do you communicate during the incident, and what do you preserve for post-incident analysis? **Attendu :** impact, périmètre, faits, actions, prochaine mise à jour, chronologie et preuves. #### Réponse attendue détaillée La communication indique les symptômes, utilisateurs affectés, contournements, actions en cours et heure de prochaine mise à jour. Elle distingue les faits des hypothèses. Conserver la chronologie, les logs, métriques, événements d’infrastructure, version déployée, changements récents et décisions prises. Le compte rendu doit identifier la cause racine et les mesures de prévention sans rechercher un responsable individuel. ## 8. Scénarios liés aux systèmes à exploiter ### 41. Export qui dépasse la mémoire **FR :** Un export de plusieurs millions de lignes fait dépasser la mémoire du conteneur. Quelle solution DevOps proposez-vous sans modifier immédiatement le code applicatif ? **EN:** An export of several million rows causes the container to exceed its memory limit. What DevOps solution do you propose without immediately changing application code? **Attendu :** diagnostiquer d’abord, traitement asynchrone ou worker dédié, limites, autoscaling prudent, stockage objet et coopération avec les développeurs. #### Réponse attendue détaillée Le rôle DevOps est d’abord de confirmer l’OOM, la volumétrie et le profil mémoire. Une mitigation peut isoler l’export dans un worker ou une tâche batch avec ressources et concurrence maîtrisées, puis stocker le résultat dans S3. La correction durable nécessitera probablement un traitement streaming ou par chunks côté application. Augmenter la mémoire peut servir de mitigation temporaire mesurée, pas de solution finale automatique. ### 42. Déploiement sur plusieurs applications **FR :** Plusieurs applications utilisent des pipelines presque identiques, mais avec des versions et environnements différents. Comment mutualisez-vous sans créer un modèle trop rigide ? **EN:** Several applications use nearly identical pipelines but have different versions and environments. How do you share pipeline logic without creating an overly rigid template? **Attendu :** étapes communes, composant/version partagée, entrées explicites, exceptions limitées, migration progressive et ownership. #### Réponse attendue détaillée Commencer par inventorier les étapes réellement communes. Extraire uniquement les blocs stables dans un template ou composant versionné, avec des entrées explicites. Chaque application conserve les différences métier ou de déploiement visibles. La migration doit être progressive et une version du template ne doit pas casser simultanément toutes les applications. Il faut un propriétaire et une procédure de mise à jour. ### 43. Secrets entre plusieurs environnements **FR :** Comment séparez-vous les secrets de développement, QA et production dans les pipelines et les workloads ? **EN:** How do you separate development, QA, and production secrets in pipelines and workloads? **Attendu :** stores et rôles séparés, environnements protégés, accès runtime, rotation, audit et absence dans les logs/state. #### Réponse attendue détaillée Chaque environnement possède ses secrets et permissions. Les workloads les obtiennent au runtime via Secrets Manager ou Parameter Store avec un rôle IAM limité. Les jobs de développement ne peuvent pas lire les secrets de production. Il faut prévoir rotation, audit, révocation, masquage des logs et protection du state Terraform. Un secret ne doit être présent ni dans Git ni dans l’image Docker. ### 44. Changement urgent en production **FR :** Une correction de configuration urgente doit être appliquée en production. Comment allez-vous vite sans contourner définitivement Terraform et le pipeline ? **EN:** An urgent configuration fix must be applied in production. How do you move quickly without permanently bypassing Terraform and the pipeline? **Attendu :** procédure d’urgence, changement minimal, revue, sauvegarde/rollback, preuve, puis réconciliation IaC. #### Réponse attendue détaillée Le changement doit rester minimal, traçable et réversible. Utiliser si possible un pipeline d’urgence protégé ou un `apply` ciblé par la procédure normale. Si une action manuelle est indispensable, documenter l’auteur, l’heure, l’ancienne valeur et la nouvelle. Après stabilisation, réconcilier immédiatement le code Terraform et vérifier la dérive afin que l’action manuelle ne devienne pas une seconde source de vérité. ## 9. Migration AWS vers Kubernetes on-premises ### 45. Stratégie de migration — Prioritaire **FR :** Comment organiseriez-vous la migration progressive d’applications actuellement exécutées sur AWS vers un cluster Kubernetes on-premises sans interruption majeure ? **EN:** How would you organize the progressive migration of applications currently running on AWS to an on-premises Kubernetes cluster without major downtime? **Attendu :** inventaire des dépendances, migration par vagues, environnement pilote, double exploitation temporaire, critères de bascule, rollback et validation. #### Réponse attendue détaillée La candidate doit commencer par inventorier les workloads, flux réseau, dépendances AWS, données, secrets, volumes, exigences de disponibilité et contraintes de latence. La migration doit se faire par vagues, en commençant par un service peu critique. Chaque vague doit prévoir : - manifests ou charts versionnés ; - tests en environnement représentatif ; - synchronisation des données si nécessaire ; - observabilité équivalente avant la bascule ; - stratégie DNS ou routage progressif ; - critères mesurables de succès ; - fenêtre de coexistence ; - rollback vers l’environnement précédent. Une migration « big bang » sans dépendances cartographiées est un signal d’alerte. ### 46. Remplacement des services AWS **FR :** Avant de migrer, comment identifiez-vous les dépendances d’une application à des services AWS comme S3, IAM, CloudWatch, EventBridge ou un load balancer ? Comment décidez-vous lesquelles conserver ou remplacer ? **EN:** Before migrating, how do you identify an application's dependencies on AWS services such as S3, IAM, CloudWatch, EventBridge, or a load balancer? How do you decide which ones to retain or replace? **Attendu :** inventaire technique et fonctionnel, trafic sortant, SDK/configuration, criticité, équivalent on-premises, coût et risque de dépendance hybride. #### Réponse attendue détaillée Il faut examiner le code et la configuration, les rôles IAM, les appels observés, les flux réseau, les dashboards et les pipelines. Pour chaque dépendance, décider : - si elle reste consommée depuis le cluster on-premises ; - si elle est remplacée par un service interne ; - si les données doivent être migrées ; - quel niveau de disponibilité et de sécurité doit être reproduit. Conserver temporairement un service AWS peut réduire le risque, mais introduit latence, coût de transfert, dépendance WAN et exigences d’authentification. Le choix doit être explicite. ### 47. Haute disponibilité du cluster — Prioritaire **FR :** Quelle architecture minimale proposez-vous pour rendre un cluster Kubernetes on-premises hautement disponible ? **EN:** What minimum architecture would you propose to make an on-premises Kubernetes cluster highly available? **Attendu :** plusieurs nœuds control plane, quorum etcd, load balancer API, workers répartis, alimentation/réseau redondants et sauvegardes. #### Réponse attendue détaillée Une production critique nécessite généralement au moins trois membres de control plane/etcd afin de maintenir un quorum, un endpoint API hautement disponible et plusieurs workers. Les nœuds doivent être répartis autant que possible entre domaines de panne réels : racks, alimentations, switches et hôtes de virtualisation. Il faut également prévoir : - capacité suffisante pendant la perte d’un nœud ; - anti-affinité ou topology spread ; - PodDisruptionBudgets adaptés ; - sauvegardes etcd testées ; - supervision du control plane ; - procédure de remplacement d’un nœud. Trois VM sur le même hyperviseur ne constituent pas une haute disponibilité complète. ### 48. Stockage persistant on-premises — Prioritaire **FR :** Comment choisissez-vous et validez-vous une solution de stockage persistant pour les StatefulSets et les traitements qui utilisaient auparavant du stockage AWS ? **EN:** How do you choose and validate persistent storage for StatefulSets and jobs that previously used AWS storage? **Attendu :** CSI, StorageClass, modes d’accès, performance, réplication, snapshots, sauvegarde, expansion et comportement lors d’une panne. #### Réponse attendue détaillée La candidate doit partir des besoins de chaque workload : capacité, IOPS, latence, `ReadWriteOnce` ou `ReadWriteMany`, rétention et disponibilité. La solution doit exposer un driver CSI maintenu et des StorageClasses explicites. La validation doit couvrir : - création et rattachement d’un PVC ; - rescheduling du Pod sur un autre nœud ; - panne d’un nœud ou du stockage ; - snapshots et restauration ; - extension de volume ; - politique `Retain` ou `Delete` ; - performances avec une charge représentative. Un snapshot de volume ne remplace pas toujours une sauvegarde cohérente au niveau applicatif. ### 49. Réseau, Ingress et exposition **FR :** Quels composants faut-il prévoir on-premises pour remplacer l’intégration réseau fournie par AWS : CNI, load balancer, Ingress, DNS et certificats TLS ? **EN:** Which on-premises components are needed to replace AWS-provided networking integration: CNI, load balancer, Ingress, DNS, and TLS certificates? **Attendu :** choix CNI, plages Pod/Service sans chevauchement, MetalLB ou équipement externe, Ingress Controller, DNS et gestion des certificats. #### Réponse attendue détaillée Le design doit préciser : - le CNI et son modèle de routage ; - les CIDR Pods et Services, sans chevauchement avec le réseau existant ; - l’annonce ou l’attribution des adresses de type LoadBalancer ; - l’Ingress Controller ; - l’intégration DNS interne et éventuellement externe ; - l’émission et le renouvellement des certificats ; - les règles firewall entre utilisateurs, cluster et dépendances. Il faut vérifier le MTU, le routage asymétrique et les flux retour. Un Service `LoadBalancer` ne reçoit pas automatiquement une adresse utilisable dans un cluster bare metal. ### 50. NetworkPolicies et segmentation **FR :** Comment évitez-vous qu’un Pod compromis puisse communiquer librement avec toutes les applications et tout le réseau interne ? **EN:** How do you prevent a compromised Pod from communicating freely with every application and the entire internal network? **Attendu :** CNI compatible, default deny ingress/egress, autorisations explicites, DNS, namespaces, firewall externe et tests. #### Réponse attendue détaillée Le cluster doit utiliser un CNI appliquant les NetworkPolicies. Une base robuste consiste à définir un refus par défaut en entrée et sortie, puis à autoriser explicitement les flux requis entre namespaces, workloads, DNS et services externes. La segmentation Kubernetes doit être complétée par : - RBAC minimal ; - séparation des namespaces ; - filtrage réseau externe ; - contrôle des accès aux interfaces d’administration ; - tests réels des flux autorisés et refusés. Créer une NetworkPolicy sans vérifier que le CNI l’applique donne une fausse impression de sécurité. ### 51. Secrets sans IAM AWS **FR :** Après la migration on-premises, comment gérez-vous les secrets et les identités des workloads sans dépendre des rôles IAM AWS ? **EN:** After migrating on-premises, how do you manage workload secrets and identities without relying on AWS IAM roles? **Attendu :** gestionnaire de secrets, authentification workload, CSI/External Secrets, chiffrement etcd, RBAC, rotation et audit. #### Réponse attendue détaillée Les secrets doivent rester dans un gestionnaire dédié, avec une identité propre au workload et des credentials courts lorsque possible. Ils peuvent être montés via un CSI driver ou synchronisés par un opérateur, en comprenant le risque de copie dans les Secrets Kubernetes. Il faut prévoir : - chiffrement des Secrets dans etcd ; - RBAC limitant lecture et écriture ; - rotation et révocation ; - audit des accès ; - séparation des environnements ; - absence dans Git, les images et les logs ; - procédure en cas de compromission. Le simple encodage base64 d’un Secret Kubernetes n’est pas une protection. ### 52. Registre d’images et fonctionnement sans Internet **FR :** Comment fournissez-vous les images et dépendances au cluster si l’accès Internet est limité ou indisponible ? **EN:** How do you provide images and dependencies to the cluster when Internet access is restricted or unavailable? **Attendu :** registry privé redondant, réplication, cache/proxy, signatures, scans, pull secrets, CA interne et procédure de mise à jour. #### Réponse attendue détaillée Le cluster doit utiliser un registre privé accessible localement. Les pipelines publient des images immuables et scannées, idéalement signées. Les nœuds doivent faire confiance à la CA interne et les namespaces utilisent des identités ou pull secrets limités. Pour un environnement isolé, il faut aussi gérer : - miroir des images système et des charts ; - proxy ou dépôt des dépendances ; - réplication et sauvegarde du registre ; - promotion contrôlée entre environnements ; - procédure d’import de correctifs de sécurité ; - fonctionnement si le registre principal est indisponible. ### 53. Sauvegarde et reprise du cluster **FR :** Que sauvegardez-vous dans un cluster Kubernetes on-premises et comment prouvez-vous que la restauration fonctionne ? **EN:** What do you back up in an on-premises Kubernetes cluster, and how do you prove restoration works? **Attendu :** etcd, objets Kubernetes, données persistantes, configuration externe, registre, sauvegarde hors site et tests de restauration. #### Réponse attendue détaillée Le plan doit distinguer : - état du control plane et snapshots etcd ; - manifests et configuration conservés dans Git ; - données des volumes persistants ; - bases de données avec sauvegardes cohérentes ; - secrets ou configuration du gestionnaire de secrets ; - registre d’images si nécessaire. Les sauvegardes doivent être chiffrées, protégées contre la suppression et copiées dans un autre domaine de panne. La preuve est un exercice de restauration documenté mesurant RPO et RTO, pas seulement un job de sauvegarde marqué réussi. ### 54. Mises à niveau et capacité **FR :** Comment préparez-vous une mise à niveau du cluster et comment garantissez-vous que les applications continuent de fonctionner pendant la maintenance d’un nœud ? **EN:** How do you prepare a cluster upgrade, and how do you ensure applications continue running while a node is under maintenance? **Attendu :** compatibilité API, environnement de test, sauvegarde etcd, upgrade progressif, cordon/drain, PDB, capacité et rollback. #### Réponse attendue détaillée Avant la mise à niveau, vérifier les versions supportées, APIs dépréciées, compatibilité du CNI, CSI, Ingress Controller et autres add-ons. Valider les manifests contre la version cible et tester l’opération sur un environnement représentatif. La maintenance d’un nœud utilise `cordon` puis `drain`, avec une capacité restante suffisante. Les workloads critiques doivent avoir plusieurs replicas, une répartition entre nœuds, des probes correctes et des PodDisruptionBudgets qui protègent la disponibilité sans rendre tout drain impossible. Sauvegarder etcd et définir une procédure de rollback avant l’opération. ## 10. Cas pratique final — 10 minutes ### 55. Migration et incident après bascule — Prioritaire **FR :** Une application vient d’être basculée d’AWS vers le cluster Kubernetes on-premises : - certains utilisateurs atteignent encore l’ancien environnement ; - la latence augmente ; - quelques Pods restent `Pending` ; - un volume persistant ne se rattache pas après le déplacement d’un Pod ; - les métriques ne sont disponibles que pour une partie des workloads. Expliquez votre démarche pendant les 30 premières minutes et vos critères de rollback. **EN:** An application has just been switched from AWS to the on-premises Kubernetes cluster: - some users still reach the old environment; - latency increases; - some Pods remain `Pending`; - a persistent volume does not reattach after a Pod is moved; - metrics are available for only part of the workloads. Explain your approach during the first 30 minutes and your rollback criteria. **Bonne réponse attendue :** 1. confirmer l’impact, le périmètre et la chronologie de la bascule ; 2. geler les changements et communiquer l’incident ; 3. vérifier DNS, TTL, caches, load balancer et routage vers les deux environnements ; 4. examiner événements et conditions des Pods `Pending` : ressources, taints, affinité et PVC ; 5. vérifier le CSI, les événements du volume, sa zone/topologie et les erreurs d’attachement ; 6. mesurer latence réseau, saturation des nœuds et dépendances encore hébergées sur AWS ; 7. vérifier les targets de scraping, ServiceMonitors ou annotations et règles réseau ; 8. comparer aux critères de succès définis avant la bascule ; 9. revenir au routage précédent si disponibilité, intégrité des données ou observabilité minimale ne sont pas assurées ; 10. préserver les preuves avant toute relance ou suppression. Un rollback doit tenir compte des écritures déjà réalisées dans le nouvel environnement afin d’éviter perte de données ou divergence. ## 11. Cas pratique complémentaire — 10 minutes ### 56. Diagnostic après déploiement — Prioritaire **FR :** Après le déploiement d’une application conteneurisée sur AWS : - le service devient lent ; - certains traitements sont exécutés deux fois ; - la mémoire des conteneurs augmente progressivement ; - le nombre de connexions à la base approche de sa limite ; - le pipeline CI/CD et ses contrôles sont pourtant verts. Expliquez votre démarche pendant les 30 premières minutes. Indiquez ce que vous vérifiez, ce que vous communiquez et dans quelles conditions vous déclenchez un rollback. **EN:** After deploying a containerized application on AWS: - the service becomes slow; - some jobs are executed twice; - container memory gradually increases; - database connections approach their limit; - the CI/CD pipeline and its checks are nevertheless green. Explain your approach during the first 30 minutes. State what you investigate, what you communicate, and under which conditions you trigger a rollback. **Bonne réponse attendue :** 1. confirmer l’impact, le périmètre et l’heure de début ; 2. annoncer l’incident et la prochaine mise à jour ; 3. arrêter le rollout si l’impact augmente ; 4. comparer la version actuelle à la précédente ; 5. examiner latence, erreurs, mémoire, redémarrages et connexions DB ; 6. corréler logs, événements de l’orchestrateur et changements de configuration ; 7. vérifier les retries, déclenchements en double et mécanismes d’idempotence ; 8. rechercher une fuite, une collection non bornée ou trop de workers ; 9. vérifier le pool de connexions par instance et le nombre d’instances ; 10. revenir à l’image précédente si le déploiement est corrélé et le rollback sûr ; 11. confirmer le retour à la normale avec smoke tests et métriques ; 12. préserver les preuves puis conduire l’analyse de cause racine. La candidate doit éviter de redémarrer tous les composants ou d’augmenter immédiatement les ressources sans collecter de preuves. ## Questions de relance pour distinguer théorie et pratique - « Quel était précisément votre rôle dans cette étape ? » - « Quelle commande, quel écran ou quelle métrique avez-vous utilisé ? » - « Comment avez-vous vérifié que la correction fonctionnait ? » - « Quel compromis ou quelle limite avait cette solution ? » - « Que se passe-t-il si l’opération est exécutée deux fois ? » - « Comment revenez-vous à l’état précédent ? » - « Quelle partie était automatisée et quelle partie restait manuelle ? » ## Signaux à observer ### Signaux positifs - distingue clairement son travail de celui de l’équipe ; - commence le diagnostic par les faits et les mesures ; - comprend idempotence, rollback et pannes partielles ; - sait expliquer pourquoi un outil a été choisi ; - considère sécurité et observabilité dès la conception ; - reconnaît les limites de son expérience sans inventer ; - propose des solutions proportionnées à un profil junior. ### Signaux d’alerte - récite des définitions sans exemple concret ; - attribue tout problème à un manque de CPU ou de mémoire ; - suppose qu’un événement ou job est exécuté exactement une fois ; - place des secrets dans Git, une image Docker ou Terraform ; - considère un pipeline vert comme preuve d’un déploiement réussi ; - choisit Kubernetes sans besoin précis ; - ne distingue pas contribution personnelle et réalisation collective. ## Grille de notation Noter chaque question de 0 à 4 : - **0 :** aucune connaissance ou réponse dangereuse - **1 :** notions théoriques très faibles - **2 :** réponse correcte mais peu de pratique ou de précision - **3 :** réponse précise avec expérience, diagnostic et compromis - **4 :** maîtrise solide, raisonnement structuré et anticipation des risques ### Pondération recommandée - Parcours, communication et validation du CV : 10 % - Linux, Git et Docker : 10 % - Kubernetes et exploitation du cluster : 20 % - Migration vers Kubernetes on-premises : 20 % - AWS et traitements batch : 15 % - Terraform et Infrastructure as Code : 10 % - CI/CD : 5 % - Observabilité et diagnostic : 10 % Pour ce profil junior, ne pas exiger une expertise approfondie de chaque service. Évaluer surtout la compréhension réelle, la capacité de diagnostic, les pratiques de sécurité et la vitesse d’apprentissage. ## Feuille de notation — sélection recommandée de 20 questions | Question | Domaine | Note / 4 | Observation | | -------: | ---------------------------------------- | :------: | ------------------------------ | | 1 | Contribution personnelle | ____ / 4 | ______________________________ | | 2 | Résultat et mesure | ____ / 4 | ______________________________ | | 4 | Diagnostic et apprentissage | ____ / 4 | ______________________________ | | 6 | Diagnostic Linux | ____ / 4 | ______________________________ | | 9 | Image Docker | ____ / 4 | ______________________________ | | 10 | Diagnostic conteneur | ____ / 4 | ______________________________ | | 13 | Readiness et liveness | ____ / 4 | ______________________________ | | 14 | Diagnostic Kubernetes | ____ / 4 | ______________________________ | | 16 | Ressources et autoscaling | ____ / 4 | ______________________________ | | 17 | EKS ou ECS Fargate | ____ / 4 | ______________________________ | | 19 | Architecture batch AWS | ____ / 4 | ______________________________ | | 20 | Reprise et idempotence | ____ / 4 | ______________________________ | | 22 | Sécurité S3 | ____ / 4 | ______________________________ | | 24 | Diagnostic IAM | ____ / 4 | ______________________________ | | 26 | State Terraform | ____ / 4 | ______________________________ | | 27 | Plan et apply | ____ / 4 | ______________________________ | | 31 | Pipeline CI/CD | ____ / 4 | ______________________________ | | 33 | Authentification AWS du pipeline | ____ / 4 | ______________________________ | | 37 | Supervision | ____ / 4 | ______________________________ | | 55 | Migration et incident après bascule | ____ / 4 | ______________________________ | | 56 | Cas pratique complémentaire | ____ / 4 | ______________________________ | ### Résultat - Total brut : ______ / 84 - Score pondéré : ______ % - Décision : Favorable / À discuter / Défavorable - Points forts : ____________________________________________________________ - Risques ou accompagnement nécessaire : ___________________________________ - Commentaire général : ____________________________________________________