Questions d'entretien AWS

Vous avez lu la liste des services et vous ne savez toujours pas à quoi ressemblera l'entretien. Cet écart est normal, et cette section le comble : les entretiens AWS sont conçus pour déterminer si vous avez exploité quelque chose, pas si vous pouvez le nommer.

Le schéma apparaît dans la relance. Un recruteur demande quel service vous utiliseriez, vous répondez correctement, et la question suivante est pourquoi pas l'autre. Quelqu'un qui a fait tourner la charge de travail répond à partir d'une facture, d'une panne ou d'une migration. Quelqu'un qui a lu la documentation bloque. C'est cette seconde question, pas la première, qui décide de l'entretien AWS.

Trois types d'étapes reviennent : une étape de fondamentaux sur le réseau, l'identité, le stockage et le calcul ; une étape de mise en situation ou de conception où vous architecturez quelque chose sous contraintes ; et une étape de dépannage où l'on vous donne un symptôme et on vous demande ce que vous vérifieriez. Les attentes de profondeur augmentent avec l'ancienneté, mais la forme reste la même. D'autres banques de questions par rôle et par sujet se trouvent sur le hub des questions d'entretien.

Voici les questions fondamentales qui reviennent dans les entretiens AWS, regroupées comme les étapes ont tendance à être organisées.

Réseau et VPC

• Qu'est-ce qu'un VPC, et en quoi les sous-réseaux publics et privés diffèrent-ils ?
• Quand avez-vous besoin d'une passerelle NAT, et quel en est le coût ?
• En quoi les groupes de sécurité diffèrent-ils des listes de contrôle d'accès réseau ?
• Comment relieriez-vous deux VPC, et quand le peering est-il le mauvais choix ?

Identité et sécurité

• Expliquez les rôles, politiques et utilisateurs IAM, et quand utiliser chacun.
• Comment une instance EC2 obtient-elle des identifiants sans stocker de clé ?
• À quoi ressemble le principe du moindre privilège dans une politique réelle ?
• Comment faites-vous pivoter et auditez-vous les secrets sur AWS ?

Stockage et bases de données

• Comparez les classes de stockage S3 et expliquez quand utiliser chacune.
• Quelle est la différence entre EBS et le stockage d'instance ?
• Quand choisissez-vous DynamoDB plutôt que RDS, et à quoi renoncez-vous ?
• En quoi les répliques de lecture diffèrent-elles d'un déploiement multi-AZ ?

Calcul et disponibilité

• Expliquez les groupes d'auto-scaling et les métriques sur lesquelles vous vous baseriez.
• Quand Lambda est-il la mauvaise réponse ?
• Quelle est la différence entre une zone de disponibilité et une région ?
• Comment concevriez-vous pour survivre à la perte d'une zone de disponibilité entière ?

Les questions de mise en situation sont celles qui distinguent les candidats, car il n'existe pas de réponse à mémoriser. Questions types :

• Notre facture mensuelle a doublé et le trafic non. Comment trouvez-vous pourquoi ?
• Concevez un pipeline de téléversement de fichiers qui gère les fichiers trop volumineux pour une seule requête.
• Un service est lent uniquement dans une zone de disponibilité. Que vérifiez-vous en premier ?
• Migrez une base de données sur site vers AWS avec un temps d'arrêt minimal. Expliquez-moi comment.
• Comment feriez-vous survivre cette architecture à une panne régionale, et combien cela coûterait-il ?

Répondez toujours dans le même ordre : reformulez la contrainte que vous jugez importante, énoncez votre hypothèse à voix haute, choisissez un service, puis nommez le compromis que vous avez accepté. C'est cette phrase de compromis que les recruteurs attendent, car elle prouve que vous savez ce que le choix a coûté.

Une ingénieure backend qui passe un entretien pour un poste plateforme dans une entreprise de taille moyenne doit concevoir un pipeline de téléversement. Au lieu de nommer S3 immédiatement, elle demande si les téléversements sont destinés aux utilisateurs et quelle taille atteignent les fichiers, puis choisit des URL présignées avec un téléversement multipart, expliquant qu'elle a écarté le passage par les serveurs d'application car cela aurait fait du débit un problème de mise à l'échelle. Le choix du service était ordinaire ; c'est le raisonnement dont on se souvient.

Lire une liste de questions n'est pas de l'entraînement. L'échec typique dans les entretiens AWS consiste à connaître la réponse mais à la livrer comme un monologue sans structure, et cela ne se révèle que lorsque vous parlez.

Parcourez les listes ci-dessus à voix haute, une question à la fois, et tenez-vous à l'ordre en quatre parties : contrainte, hypothèse, choix, compromis. Enregistrez-en quelques-unes et réécoutez-les pour repérer le moment où votre réponse perd sa structure. Refaire le même exercice en entretien simulé ajoute la question de relance, la partie que vous ne pouvez pas répéter seul et celle sur laquelle les recruteurs AWS s'appuient le plus.

Une limite à énoncer clairement : certaines épreuves AWS sont des évaluations automatisées, enregistrées ou surveillées plutôt que des conversations en direct. Cela dépasse le cadre de tout assistant en direct, SubcueAI y compris. La préparation est la seule chose qui aide dans ce cas, et le hub des types d'entretien explique quels formats se comportent comment.