1. Compétences Techniques (40 points)
15 pts Kubernetes & Container Orchestration
❓ Expliquez comment vous débogueriez un pod Kubernetes qui crashe en boucle.
✅ Réponse Attendue :
• kubectl logs [pod-name] --previous (logs du container crashé)
• kubectl describe pod [pod-name] (events, resource limits, status)
• kubectl get events --sort-by='.lastTimestamp' (événements récents)
• Vérifier resource requests/limits, liveness/readiness probes
• Analyser OOMKilled, CrashLoopBackOff, ImagePullBackOff
• kubectl exec -it [pod] -- /bin/sh (si possible, debug interactif)
• kubectl describe pod [pod-name] (events, resource limits, status)
• kubectl get events --sort-by='.lastTimestamp' (événements récents)
• Vérifier resource requests/limits, liveness/readiness probes
• Analyser OOMKilled, CrashLoopBackOff, ImagePullBackOff
• kubectl exec -it [pod] -- /bin/sh (si possible, debug interactif)
🚩 Red Flags :
Ne connaît pas kubectl logs, approche non méthodique, ignore les resource limits
❓ Quelle est votre expérience avec les stratégies de déploiement Kubernetes (Rolling, Blue/Green, Canary) ?
✅ Réponse Attendue :
• Rolling Update : déploiement progressif, maxUnavailable/maxSurge
• Blue/Green : 2 environnements, switch instantané, rollback facile
• Canary : déploiement progressif avec métriques, 5%-10%-50%-100%
• Outils : Argo Rollouts, Flagger, Istio pour canary avancé
• Trade-offs : complexité, coûts, temps de déploiement
• Blue/Green : 2 environnements, switch instantané, rollback facile
• Canary : déploiement progressif avec métriques, 5%-10%-50%-100%
• Outils : Argo Rollouts, Flagger, Istio pour canary avancé
• Trade-offs : complexité, coûts, temps de déploiement
🚩 Red Flags :
Ne connaît que Rolling Update, jamais fait de Canary deployment
10 pts Infrastructure as Code
❓ Comment gérez-vous le state management avec Terraform en équipe ?
✅ Réponse Attendue :
• Remote backend : S3 + DynamoDB (locking), Terraform Cloud, Azure Blob
• State locking pour éviter concurrence
• Workspaces pour environnements (dev/staging/prod)
• terraform.tfstate en .gitignore (jamais commit)
• State encryption at rest
• Backup régulier du state
• terraform state mv/rm pour refactoring
• State locking pour éviter concurrence
• Workspaces pour environnements (dev/staging/prod)
• terraform.tfstate en .gitignore (jamais commit)
• State encryption at rest
• Backup régulier du state
• terraform state mv/rm pour refactoring
🚩 Red Flags :
State local sans backup, pas de locking, commit state dans Git
8 pts CI/CD & GitOps
❓ Décrivez votre pipeline CI/CD idéal pour une application conteneurisée.
✅ Réponse Attendue :
• CI : Build → Test (unit, integration) → Security scan → Build image → Push registry
• CD GitOps : ArgoCD/Flux sync Git → K8s deployment
• Quality gates : code coverage >80%, security scan passed
• Rollback automatique si healthcheck fail
• Notifications : Slack/Teams/PagerDuty
• Outils : GitLab CI, GitHub Actions, ArgoCD, Harbor/ECR
• CD GitOps : ArgoCD/Flux sync Git → K8s deployment
• Quality gates : code coverage >80%, security scan passed
• Rollback automatique si healthcheck fail
• Notifications : Slack/Teams/PagerDuty
• Outils : GitLab CI, GitHub Actions, ArgoCD, Harbor/ECR
🚩 Red Flags :
Pipeline manuel, pas de tests automatisés, pas de rollback
7 pts Monitoring & Observability
❓ Quelle stack d'observability utilisez-vous ? Comment détectez-vous les anomalies ?
✅ Réponse Attendue :
• Metrics : Prometheus + Grafana (dashboards, alerting)
• Logs : ELK/Loki + centralized logging
• Tracing : Jaeger, Tempo pour distributed tracing
• APM : Datadog, New Relic (si budget)
• Alerting : AlertManager, PagerDuty avec escalation
• SLI/SLO : définition et tracking (latency p95, error rate, uptime)
• Anomaly detection : baselines, ML-based alerts (ex: Datadog Watchdog)
• Logs : ELK/Loki + centralized logging
• Tracing : Jaeger, Tempo pour distributed tracing
• APM : Datadog, New Relic (si budget)
• Alerting : AlertManager, PagerDuty avec escalation
• SLI/SLO : définition et tracking (latency p95, error rate, uptime)
• Anomaly detection : baselines, ML-based alerts (ex: Datadog Watchdog)
🚩 Red Flags :
Logs manuels, pas de métriques, alerting réactif seulement
2. Soft Skills & SRE Mindset (35 points)
12 pts Incident Management & On-Call
❓ Décrivez votre processus de gestion d'incident production (P1/P2).
✅ Réponse Attendue :
• Détection : alerting automatique → PagerDuty escalation
• Triage : Incident Commander, War room (Slack/Teams)
• Investigation : Logs, metrics, tracing → root cause
• Mitigation : rollback, scaling, traffic shifting
• Communication : status page, stakeholders updates
• Post-mortem : blameless, action items, incident timeline
• Prevention : runbooks, automation, monitoring improvements
• Triage : Incident Commander, War room (Slack/Teams)
• Investigation : Logs, metrics, tracing → root cause
• Mitigation : rollback, scaling, traffic shifting
• Communication : status page, stakeholders updates
• Post-mortem : blameless, action items, incident timeline
• Prevention : runbooks, automation, monitoring improvements
🚩 Red Flags :
Pas d'expérience on-call, pas de post-mortem, blâme les devs
10 pts Automation & Toil Reduction
❓ Donnez un exemple de toil que vous avez automatisé et l'impact obtenu.
✅ Réponse Attendue :
• Exemple concret : déploiements manuels → GitOps
• Avant : 2h/déploiement, 10 déploiements/semaine = 20h/semaine
• Après : automatisé, 5 min/déploiement, 0 erreur
• Impact : 20h économisées/semaine, -80% incidents déploiement
• Outils : scripts Python/Bash, Terraform, Ansible, GitLab CI
• ROI mesuré et documenté
• Avant : 2h/déploiement, 10 déploiements/semaine = 20h/semaine
• Après : automatisé, 5 min/déploiement, 0 erreur
• Impact : 20h économisées/semaine, -80% incidents déploiement
• Outils : scripts Python/Bash, Terraform, Ansible, GitLab CI
• ROI mesuré et documenté
🚩 Red Flags :
"J'aime les tâches manuelles", pas d'exemples concrets, pas de mesure d'impact
8 pts Collaboration Dev/Ops
❓ Comment collaborez-vous avec les équipes de développement ?
✅ Réponse Attendue :
• Embedded SRE : participations sprints, code reviews
• Documentation : runbooks, architecture diagrams, ADR
• Self-service : CI/CD templates, infra modules Terraform
• Observability : formation devs sur métriques, logs, tracing
• Blameless culture : post-mortems partagés
• Exemple concret : projet collaboratif dev/ops réussi
• Documentation : runbooks, architecture diagrams, ADR
• Self-service : CI/CD templates, infra modules Terraform
• Observability : formation devs sur métriques, logs, tracing
• Blameless culture : post-mortems partagés
• Exemple concret : projet collaboratif dev/ops réussi
🚩 Red Flags :
"Ce n'est pas mon problème", silos dev/ops, pas de documentation
5 pts Veille Technologique
❓ Comment vous tenez-vous à jour sur les évolutions DevOps/SRE ?
✅ Réponse Attendue :
• Sources : SRE Weekly, DevOps Weekly, Reddit r/kubernetes, r/devops
• Livres : SRE Book (Google), Phoenix Project
• Conférences : KubeCon, HashiConf, DevOps Days
• Certifications : CKA, AWS/GCP certifications
• Expérimentation : homelab, side projects, contributions open-source
• Exemple : dernière techno testée (ex: Cilium, Istio ambient mesh)
• Livres : SRE Book (Google), Phoenix Project
• Conférences : KubeCon, HashiConf, DevOps Days
• Certifications : CKA, AWS/GCP certifications
• Expérimentation : homelab, side projects, contributions open-source
• Exemple : dernière techno testée (ex: Cilium, Istio ambient mesh)
🚩 Red Flags :
Pas de veille active, connaissances datées, résistance au changement
3. Fit Culturel & Motivation (15 points)
8 pts Alignement Pyl.Tech
❓ Pourquoi rejoindre Pyl.Tech en tant que DevOps SRE ?
✅ Réponse Attendue :
• Recherche effectuée : connaît nos projets cloud, stack technique
• Intérêt : infrastructure moderne, cloud native, observability
• Valeurs : souveraineté numérique, automatisation, reliability
• Challenge : infrastructure scalable, haute disponibilité
• Croissance : apprendre, partager, améliorer la plateforme
• Intérêt : infrastructure moderne, cloud native, observability
• Valeurs : souveraineté numérique, automatisation, reliability
• Challenge : infrastructure scalable, haute disponibilité
• Croissance : apprendre, partager, améliorer la plateforme
🚩 Red Flags :
Réponse générique, aucune recherche, motivations uniquement financières
7 pts On-Call & Responsibility
❓ Comment gérez-vous le stress de l'on-call et la responsabilité production ?
✅ Réponse Attendue :
• Expérience on-call : rotation équitable, escalation claire
• Préparation : runbooks à jour, alerting bien configuré
• Work-life balance : respect des horaires, compensation
• Team support : backup, pair on-call si besoin
• Gestion stress : méthodique, reste calme sous pression
• Ownership mindset : responsabilité partagée, amélioration continue
• Préparation : runbooks à jour, alerting bien configuré
• Work-life balance : respect des horaires, compensation
• Team support : backup, pair on-call si besoin
• Gestion stress : méthodique, reste calme sous pression
• Ownership mindset : responsabilité partagée, amélioration continue
🚩 Red Flags :
Refuse l'on-call, panique sous pression, burnout récent
4. Cas Pratiques (10 points)
🧪 Cas 1 : Outage Production - Debugging Sous Pression
Contexte : API critique down depuis 5 min, 500 errors, users impactés. Vous êtes on-call.
Tâche : Décrivez votre approche step-by-step pour investiguer et résoudre.
Évaluation : Méthodologie, priorisation, communication, mitigation rapide
🧪 Cas 2 : Migration Cloud-Native
Contexte : Application monolithe sur VMs → Kubernetes. 20 microservices, 100K users/jour.
Tâche : Concevoir le plan de migration avec stratégie de déploiement.
Évaluation : Architecture K8s, stratégie migration (strangler fig?), rollback plan
🧪 Cas 3 : Optimisation Coûts Cloud
Contexte : Facture AWS 50K€/mois. Management veut réduire 30% sans dégrader performance.
Tâche : Proposer 5 actions concrètes avec impact estimé.
Évaluation : Analyse coûts, actions pragmatiques, mesure impact, priorités
5. Tableau de Scoring
| Catégorie | Critère | Points Max | Score |
|---|---|---|---|
| Compétences Techniques (40) | Kubernetes & Containers | 15 | |
| Infrastructure as Code | 10 | ||
| CI/CD & GitOps | 8 | ||
| Monitoring & Observability | 7 | ||
| Soft Skills (35) | Incident Management & On-Call | 12 | |
| Automation & Toil Reduction | 10 | ||
| Collaboration Dev/Ops | 8 | ||
| Veille Technologique | 5 | ||
| Fit Culturel (15) | Alignement Pyl.Tech | 8 | |
| On-Call & Responsibility | 7 | ||
| Cas Pratiques | 10 | ||
| SCORE TOTAL | 100 | ||
📊 Interprétation
- 85-100 : ⭐⭐⭐ Excellent - Fortement recommandé
- 70-84 : ⭐⭐ Bon - À considérer
- 55-69 : ⭐ Moyen - Avec réserves
- < 55 : ❌ Insuffisant