Questions d’entretien pour un DevOps Engineer

Lors de l’entretien, l’évaluateur cherche des signaux concrets de maturité : design de pipeline, fiabilité des déploiements et maîtrise des risques. Par exemple, vous devez expliquer comment vous orchestrez GitHub Actions ou GitLab CI pour obtenir un feedback rapide et reproductible, avec des artefacts immuables. Il attend aussi une approche sécurité intégrée, pas ajoutée en fin de chaîne, incluant des scans comme Trivy et une gestion des secrets via Vault ou AWS Secrets Manager. Enfin, il vous demandera des KPI opérationnels : taux d’échec, lead time, et changement failure rate, afin de relier vos choix à des résultats.

Un pipeline solide est pensé pour évoluer : modularité, réutilisation et gouvernance des changements. Vous pouvez présenter une stratégie par environnement (dev/staging/prod) avec des workflows GitHub Actions, et des contrôles de qualité automatiques (lint, tests, build Docker) avant toute promotion. Côté déploiement, montrez que vous savez limiter l’impact via des méthodes comme canary ou blue/green sur Kubernetes, avec des tests smoke et des garde-fous. Pour renforcer votre crédibilité, citez des mesures précises : objectif de < 10 minutes pour les PR, ou une réduction du MTTR grâce à des rollback scripts et des artefacts signés. Vous pouvez aussi mentionner le rôle des feature flags pour découpler déploiement et activation fonctionnelle.

Sur l’Infrastructure as Code, l’enjeu n’est pas seulement d’utiliser Terraform, mais de garantir que l’infrastructure reste cohérente dans le temps. Expliquez comment vous gérez le state à distance (S3 + DynamoDB locking par exemple) pour éviter les conflits et sécuriser l’exécution en CI. Mettez en avant la détection du drift via des plans réguliers et une politique de PR obligatoire pour tout changement. Côté sécurité, évoquez des garde-fous comme tfsec/Checkov, et l’application de principes de moindre privilège pour le runner CI. Terminez par un principe opérationnel : si ça ne passe pas par le code, alors ça n’existe pas — ce qui se traduit par zéro action manuelle en console hors procédures exceptionnelles documentées.

Quand la production tombe, le recruteur veut voir une méthode structurée, pas une réaction émotionnelle. Montrez votre triage : corrélation alertes/métriques (Grafana), analyse logs (ELK/Datadog) et examen des changements récents. Précisez vos actions immédiates, comme l’utilisation de PagerDuty/OpsGenie pour cadrer l’on-call et l’impact, puis des décisions comme rollback Kubernetes ou scaling temporaire. Ensuite, décrivez la communication : messages factuels dans Slack et mise à jour de status page, avec un owner et une ETA. Enfin, insistez sur le post-mortem blameless avec des actions mesurables qui réduisent la récidive et améliorent le MTTR. Cette continuité de l’apprentissage est ce qui transforme un incident en progression durable.