Questions d'entretien ingénieur DevOps AWS : comptes, rôles IAM et EKS

Terraform, Kubernetes sur EKS, GitLab CI ou GitHub Actions, CloudWatch avec Prometheus et Grafana : c'est la pile que décrivent presque toutes les offres d'ingénieur DevOps AWS. Le poste couvre la mise en place des comptes et du réseau, les pipelines de déploiement, puis le run de ce qui a été livré. L'entretien d'ingénieur DevOps AWS part de ces trois blocs, avec chaque fois un exemple que la personne a mis en production elle-même.

Le CV dit peu de choses sur IAM, alors que c'est là que les erreurs coûtent le plus cher. Un profil habitué à AWS parle de rôles assumés, de fédération OIDC pour la CI, de SCP dans AWS Organizations et de comptes séparés par environnement. Un profil moins exposé décrit des utilisateurs IAM avec des clés d'accès et un seul compte pour tout.

Au moins une question porte sur le réseau. Beaucoup de pannes sur EKS viennent d'un subnet sans route, d'un endpoint VPC manquant ou d'adresses IP épuisées, et la façon de chercher compte plus que la réponse finale. La certification AWS DevOps Engineer Professional, valable trois ans, couvre ces sujets sans remplacer un exemple vécu. Le PDF déroule l'entretien en 30 questions, avec un cas de migration vers EKS.

Les services AWS qu'un ingénieur DevOps opère au quotidien

IAM et IAM Identity Center

IAM décide qui peut faire quoi sur chaque ressource AWS. Les personnes se connectent par IAM Identity Center, relié à l'annuaire de l'entreprise, et les applications comme les pipelines utilisent des rôles aux identifiants temporaires. Un candidat qui parle encore d'utilisateurs IAM avec des clés d'accès travaille avec des pratiques datées.

AWS Organizations et Control Tower

Organizations range les comptes AWS en unités d'organisation et leur applique des SCP, des règles qui plafonnent ce que même un administrateur peut faire. Control Tower installe une landing zone prête à l'emploi : comptes de journaux et de sécurité, contrôles, fabrique de comptes. Les offres le citent souvent sous le nom de landing zone.

VPC et réseau

Le VPC est le réseau privé de chaque compte, découpé en subnets publics et privés. Les security groups filtrent le trafic, les NAT gateways et les VPC endpoints donnent une sortie aux machines privées, Transit Gateway relie les VPC entre eux et au datacenter. Une grande partie des pannes d'un ingénieur DevOps AWS se règle ici.

Amazon EKS

Kubernetes managé par AWS. AWS gère le plan de contrôle, l'équipe gère les nœuds (groupes managés, Karpenter) ou les délègue à EKS Auto Mode. Les points à creuser : les montées de version, les droits des pods par EKS Pod Identity ou IRSA, et la consommation d'adresses IP du VPC CNI.

ECS, Fargate et Lambda

Les autres façons d'exécuter du code. ECS orchestre des conteneurs sans Kubernetes, Fargate évite de gérer des serveurs, Lambda exécute des fonctions courtes à la demande derrière API Gateway ou une file SQS. Un bon profil sait dire quand EKS est de trop.

Terraform, CloudFormation et CDK

L'infrastructure décrite en code. Terraform est le plus demandé dans les offres, avec un state stocké dans S3 et verrouillé. CloudFormation est l'outil natif d'AWS et CDK permet d'écrire les mêmes ressources en TypeScript ou en Python.

GitLab CI, GitHub Actions et ECR

Les pipelines tournent le plus souvent sur GitLab CI ou GitHub Actions, plus rarement sur CodePipeline et CodeBuild. Les images sont stockées dans ECR, qui peut les analyser à la recherche de vulnérabilités. Le pipeline s'authentifie sur AWS par OIDC, sans clé stockée.

CloudWatch, X-Ray et CloudTrail

CloudWatch collecte métriques, logs et alarmes, X-Ray suit une requête de service en service, CloudTrail enregistre chaque appel à l'API AWS pour l'audit. Beaucoup d'équipes ajoutent Prometheus et Grafana pour Kubernetes. Les logs CloudWatch pèsent vite sur la facture si personne ne règle leur rétention.

Secrets Manager et KMS

Secrets Manager stocke mots de passe et jetons, avec rotation automatique pour certaines bases. KMS gère les clés de chiffrement utilisées par S3, EBS ou RDS. Les droits sur une clé KMS se règlent dans sa propre policy, une source fréquente d'erreurs AccessDenied.

Le poste prend plusieurs formes. Sur un projet de construction, l'ingénieur DevOps AWS monte la landing zone avec Control Tower ou Terraform, puis le réseau et les premiers clusters. Sur un poste de run, il maintient des comptes existants, applique les montées de version d'EKS et répond aux alertes, parfois en astreinte. Beaucoup d'offres demandent les deux. Les outils changent peu d'une offre à l'autre : Terraform plus souvent que CloudFormation, GitLab CI ou GitHub Actions plus souvent que CodePipeline, Argo CD pour le déploiement continu sur Kubernetes. L'offre précise la part de build et de run, et si une astreinte est prévue.

Six compétences à noter chez un ingénieur DevOps AWS

• IAM, rôles et accès de la CI
• Organisation multi-comptes et SCP
• Réseau VPC et exposition des services
• EKS et ECS en production
• Terraform et gestion du state
• Observabilité, coûts et reprise

Questions d'entretien pour un ingénieur DevOps AWS, avec les réponses attendues

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Votre pipeline GitLab déploie sur AWS avec une clé d'accès stockée en variable CI. Comment vous en débarrassez-vous ?

   Une bonne réponsePar la fédération OIDC. GitLab (ou GitHub) est déclaré comme fournisseur d'identité dans IAM, et le job échange son jeton contre les identifiants temporaires d'un rôle (AssumeRoleWithWebIdentity). La trust policy du rôle vérifie l'audience et le champ sub, qui contient le projet et la branche ou l'environnement. Un rôle par environnement, avec des droits limités à ce que le déploiement fait. Ensuite, la clé est désactivée, puis supprimée une fois que CloudTrail et la date de dernière utilisation confirment que plus rien ne s'en sert.

   Signal d'alerte« Je mets la clé dans Secrets Manager », qui déplace le problème sans le régler. Une rotation tous les 90 jours présentée comme la solution. Un rôle AdministratorAccess pour la CI parce que c'est plus simple.

2. Question 2 · confirmé à senior

   Une équipe a les droits administrateur dans son compte AWS. Comment l'empêchez-vous de couper CloudTrail ou de créer des ressources hors d'Europe ?

   Une bonne réponseAvec des SCP dans AWS Organizations, attachées à l'unité d'organisation : un refus explicite sur cloudtrail:StopLogging et DeleteTrail, et un refus conditionné sur aws:RequestedRegion pour les régions non autorisées. Les services globaux (IAM, CloudFront, Route 53, Support) sont exclus de la règle de région, sinon ils cassent. Une SCP n'accorde aucun droit, elle fixe un plafond, et elle ne s'applique pas au compte de gestion. Le trail d'organisation écrit dans un compte d'archive des journaux. Control Tower fournit ces contrôles tout faits. La SCP est testée sur une OU de bac à sable avant d'être généralisée.

   Signal d'alerte« On retire les droits admin » sans rien proposer à la place, ou « on relit CloudTrail chaque semaine ». Une confusion entre SCP et policy IAM, ou l'idée qu'une SCP donne des permissions.

3. Question 3 · confirmé

   Des pods EKS placés dans des subnets privés n'arrivent pas à tirer leurs images depuis ECR. Comment cherchez-vous ?

   Une bonne réponseD'abord le message exact dans kubectl describe pod : un délai dépassé oriente vers le réseau, un AccessDenied vers IAM. Côté réseau, la table de routage du subnet doit mener à une NAT gateway, ou bien des VPC endpoints existent pour ecr.api et ecr.dkr, plus un endpoint de type gateway pour S3, où sont stockées les couches des images. Le security group des endpoints accepte le 443 depuis les nœuds et le DNS privé est activé. Côté IAM, le rôle des nœuds a le droit de lire ECR.

   Signal d'alertePasser les nœuds dans un subnet public ou ouvrir le security group à 0.0.0.0/0. Oublier l'endpoint S3 et ne pas comprendre pourquoi le pull échoue encore.

4. Question 4 · confirmé

   Un pod sur EKS doit écrire dans un bucket S3. Comment lui donnez-vous ce droit, et à lui seul ?

   Une bonne réponseUn rôle IAM dédié, associé au service account Kubernetes du pod. Soit par EKS Pod Identity : une association déclarée dans EKS, une trust policy sur pods.eks.amazonaws.com et l'agent Pod Identity sur les nœuds (déjà présent en Auto Mode). Soit par IRSA, avec le fournisseur OIDC du cluster et une annotation sur le service account. La policy se limite au bucket et au préfixe utiles. Un bon profil ajoute qu'il faut empêcher les pods de lire le rôle du nœud par le service de métadonnées (IMDSv2 avec une limite de saut à 1).

   Signal d'alerteAjouter la policy S3 au rôle des nœuds, ce qui la donne à tous les pods du nœud. Mettre une clé d'accès dans un Secret Kubernetes.

5. Question 5 · junior à confirmé

   Deux personnes lancent terraform apply en même temps sur la même infrastructure. Qu'est-ce qui l'empêche chez vous, et où se trouve le state ?

   Une bonne réponseLe state est dans un bucket S3 versionné et chiffré, accessible à peu de rôles. Le verrou est posé par le backend S3 lui-même avec use_lockfile, qui crée un fichier .tflock à côté du state ; le verrou par table DynamoDB est déprécié dans la documentation Terraform. Les apply passent par la CI après un plan relu dans la merge request, pas depuis un poste. Le state est découpé par environnement et par composant pour limiter les dégâts d'une erreur.

   Signal d'alerteUn state en local ou commité dans Git. « On se prévient sur Slack. » Un terraform force-unlock lancé par réflexe, sans vérifier qu'aucun apply ne tourne.

Ingénieur DevOps AWS : questions fréquentes

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.