Pour un architecte cloud AWS, les questions d'entretien doivent coller à ce qu'il fera dans ses premiers mois. Sur la plupart des postes, il dessine ou reprend une landing zone avec AWS Organizations et Control Tower, choisit la topologie réseau entre les comptes et le datacenter, puis tranche entre serverless, conteneurs et machines virtuelles pour chaque application. Il rédige les dossiers d'architecture et défend ses choix devant la sécurité et la finance.
Le titre recouvre des profils très différents. Certains viennent de l'infrastructure et connaissent bien le réseau. D'autres viennent du développement et pensent d'abord en Lambda et en API. La certification Solutions Architect Professional, dont l'examen actuel porte le code SAP-C03, montre une connaissance large des services. Elle ne dit pas si la personne a déjà mené une bascule de région ou expliqué une facture à un directeur financier.
Un schéma dessiné par le candidat lui-même sert de fil : le nombre de comptes, ce qui passait par le Transit Gateway, ce qu'il referait autrement. Le PDF contient l'entretien complet, avec un cas de 20 minutes sur la migration d'une plateforme de réservation.
Ce qu'un architecte cloud AWS doit connaître du catalogue
AWS Organizations et Control Tower
Le socle multi-comptes. Organizations regroupe les comptes en unités organisationnelles (OU) et leur applique des politiques : les SCP plafonnent ce que les identités peuvent faire, les RCP plafonnent l'accès aux ressources. Control Tower ajoute une landing zone prête à l'emploi, avec un compte de journaux, un compte d'audit et des contrôles. Un architecte doit savoir expliquer pourquoi il découpe les comptes de telle façon.
IAM et IAM Identity Center
IAM définit les rôles et les politiques de chaque compte. Identity Center donne aux personnes un accès unique à tous les comptes, relié à Entra ID ou Okta, sans utilisateur IAM ni clé d'accès permanente. Les permission boundaries laissent une équipe créer ses propres rôles sans dépasser un plafond fixé par la plateforme.
VPC, Transit Gateway et Cloud WAN
Le réseau. Chaque compte a ses VPC, reliés entre eux et au datacenter par un Transit Gateway, ou par Cloud WAN quand le réseau couvre plusieurs régions. PrivateLink expose un service d'un VPC à un autre sans ouvrir le routage. Le plan d'adressage IP se décide au début, car un chevauchement coûte cher à corriger.
Direct Connect et Route 53
Direct Connect relie le datacenter à AWS par un lien privé, souvent doublé d'un VPN en secours. Route 53 gère le DNS public et privé, et ses Resolver endpoints assurent la résolution entre le datacenter et les VPC. Le DNS hybride revient souvent dans les incidents des premières semaines.
Lambda, ECS sur Fargate et EKS
Trois façons de faire tourner du code. Lambda exécute des fonctions à la demande et facture à l'appel. ECS sur Fargate fait tourner des conteneurs sans serveur à gérer. EKS fournit Kubernetes, avec plus de liberté et plus d'exploitation. Un bon architecte choisit selon la charge et selon l'équipe qui maintiendra le service.
API Gateway, SQS, EventBridge et Step Functions
Les services des architectures événementielles. API Gateway expose les API, SQS met les messages en file, EventBridge route les événements entre services et entre comptes, Step Functions enchaîne les étapes d'un traitement avec reprise sur erreur. Les erreurs sont un bon terrain : rejeu, file de messages en échec, idempotence.
Aurora, DynamoDB et S3
Les bases et le stockage les plus fréquents. Aurora pour le relationnel, avec Global Database pour répliquer vers une autre région. DynamoDB pour les accès par clé à fort volume, avec des tables globales. S3 pour les fichiers et les sauvegardes, avec réplication entre régions.
KMS, CloudTrail, GuardDuty et Security Hub
KMS chiffre les données avec des clés que l'entreprise contrôle. CloudTrail trace chaque appel d'API, Config enregistre l'état des ressources, GuardDuty détecte les comportements suspects et Security Hub regroupe les constats de tous les comptes. L'architecte décide où ces informations sont centralisées et qui les traite.
Well-Architected et outils de coût
Le cadre Well-Architected d'AWS compte six piliers : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts et durabilité. Cost Explorer, les Savings Plans et Compute Optimizer servent à expliquer et à réduire la facture. Une revue Well-Architected menée par le candidat, et ce qu'elle a changé, vaut mieux qu'une liste de piliers.
Le poste prend plusieurs formes. Certains architectes cloud AWS construisent le socle multi-comptes d'une organisation qui arrive sur AWS. D'autres accompagnent les équipes produit dans le choix de leurs services, ou reprennent une plateforme qui a grandi sans règles et qu'il faut remettre en ordre sans arrêter la production. Les migrations depuis un datacenter, en rehost puis en modernisation, restent fréquentes. L'architecte n'écrit pas forcément tout le Terraform, mais il doit savoir lire un module et une politique IAM. La certification AWS Certified Solutions Architect Professional, valable trois ans, atteste une connaissance large du catalogue. L'expérience se vérifie sur des décisions réelles et leurs conséquences.
Six compétences à vérifier chez un architecte AWS
- Organisation multi-comptes et garde-fous
- Réseau AWS et connectivité hybride
- Identité, chiffrement et détection
- Résilience et reprise multi-région
- Choix de services et architectures événementielles
- Coûts, migration et infrastructure as code
Cinq questions posées à un architecte cloud AWS
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.
Question 1 · senior
Une entreprise utilise AWS depuis trois ans avec un seul compte où cohabitent développement et production. Comment organisez-vous les comptes et les garde-fous avant d'accueillir dix nouvelles applications ?
Une bonne réponseUne organisation AWS avec des OU par fonction : sécurité (comptes de journaux et d'audit), infrastructure (réseau, services partagés), charges de travail séparées entre production et hors production, bac à sable, comptes suspendus. Un compte par application et par environnement, créé à partir d'un modèle. Control Tower ou Landing Zone Accelerator pour poser le socle, un CloudTrail d'organisation, des SCP qui interdisent de quitter l'organisation, de couper les journaux ou d'utiliser des régions non prévues. Le compte historique devient un compte de charge parmi d'autres, vidé progressivement.
Signal d'alerteGarder un compte unique avec un VPC par environnement, des utilisateurs IAM avec clés d'accès, ou une organisation calquée sur l'organigramme. Croire qu'une SCP accorde des droits.
Question 2 · senior
Trente VPC répartis dans quinze comptes doivent communiquer entre eux et joindre le datacenter par Direct Connect. Quelle topologie proposez-vous ?
Une bonne réponseUn Transit Gateway dans un compte réseau, partagé aux autres comptes par AWS RAM, avec des tables de routage séparées pour isoler production et hors production. Direct Connect arrive sur une Direct Connect Gateway reliée au Transit Gateway, avec un VPN en secours. Un plan d'adressage sans chevauchement, géré dans VPC IPAM. Un VPC d'inspection avec Network Firewall si la sécurité exige de filtrer les flux entre VPC, et des Route 53 Resolver endpoints pour le DNS entre le datacenter et AWS. Sur plusieurs régions, il évoque Cloud WAN.
Signal d'alerteUn peering entre chaque paire de VPC, la même plage 10.0.0.0/16 dans tous les comptes, ou un plan qui oublie le DNS.
Question 3 · senior
Une équipe produit demande les droits administrateur sur son compte de production pour aller plus vite. Comment lui donnez-vous de l'autonomie sans perdre le contrôle ?
Une bonne réponseLes déploiements passent par une pipeline qui assume un rôle dédié. Les humains gardent un accès en lecture, plus un accès d'urgence tracé. L'équipe peut créer ses rôles applicatifs dans la limite d'une permission boundary. Les SCP de l'OU interdisent de toucher aux journaux, au réseau partagé et aux rôles de la plateforme. L'accès humain passe par IAM Identity Center, avec des permission sets et des sessions courtes.
Signal d'alerteDonner AdministratorAccess et faire confiance, ou tout refuser et imposer un ticket pour chaque rôle.
Question 4 · senior
Le métier demande que l'application de commande reste disponible si la région de Paris tombe, avec au plus cinq minutes de données perdues. Que proposez-vous, et que coûte chaque option ?
Une bonne réponseIl fait préciser l'objectif de reprise (RTO) à côté des cinq minutes de perte de données (RPO), puis présente les quatre stratégies décrites par AWS : sauvegarde et restauration, pilot light, warm standby, actif-actif. Pour cinq minutes de RPO, la sauvegarde ne suffit pas : Aurora Global Database ou des tables globales DynamoDB, une réplication S3 entre régions, l'infrastructure décrite en code pour la seconde région. La bascule passe par Route 53 ou ARC Region switch, et elle se teste. Il pose aussi la question de la région de secours au regard des données.
Signal d'alerte« Le multi-AZ suffit », confondre panne de zone et panne de région, ou un plan jamais testé.
Question 5 · confirmé
Une API reçoit une cinquantaine de requêtes par seconde en journée, presque rien la nuit, et 2 000 pendant les campagnes. Lambda, ECS sur Fargate ou EKS : comment choisissez-vous ?
Une bonne réponseIl part de la charge, de la latence attendue, des compétences de l'équipe et du coût à volume. Lambda derrière API Gateway convient bien à cette charge irrégulière, à condition de surveiller les démarrages à froid, le quota de concurrence du compte et les connexions à la base (RDS Proxy). Fargate convient si l'application est déjà conteneurisée ou si les requêtes sont longues. EKS se justifie quand une plateforme Kubernetes existe déjà et qu'une équipe l'exploite.
Signal d'alerteEKS d'office parce que « c'est le standard », ou un choix qui ignore qui maintiendra le service.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Architecte cloud AWS, les questions fréquentes
Architecte cloud AWS ou ingénieur cloud AWS : où passe la frontière ?
L'ingénieur cloud construit et exploite : il écrit le Terraform, déploie, corrige les incidents. L'architecte décide de la structure : découpage des comptes, topologie réseau, choix des services, objectifs de reprise, et il défend ces choix devant la sécurité et la finance. Sur beaucoup de postes, l'architecte reste proche du code. Les questions de décision et les options écartées font la différence. Un ingénieur raconte ce qu'il a fait, un architecte explique pourquoi il l'a fait.
La certification Solutions Architect Professional est-elle indispensable ?
Non, mais c'est un bon signal. L'examen actuel, SAP-C03, couvre la conception, la sécurité et la gouvernance, les coûts, la résilience et la migration, et l'excellence opérationnelle. La certification est valable trois ans. Elle prouve une connaissance large du catalogue, pas l'expérience d'une plateforme en production. Un profil certifié sans exemple de bascule, de facture expliquée ou de landing zone construite reste à vérifier sur un cas.
Quel test technique est donné à un architecte cloud AWS ?
Une étude de cas en entretien fonctionne mieux qu'un questionnaire. Le contexte est court : une application, des contraintes de disponibilité, de données et de budget. La personne dessine l'architecture pendant vingt minutes, puis une contrainte change, par exemple une panne de région ou un budget divisé par deux. La façon dont elle reprend son schéma montre sa maîtrise mieux qu'une liste de services récitée.
Faut-il exiger une expérience Kubernetes pour ce poste ?
Seulement si le poste l'impose. Beaucoup d'architectures AWS tiennent avec Lambda et ECS sur Fargate, sans cluster à exploiter. Si l'entreprise a déjà une plateforme EKS, l'architecte doit connaître son réseau, les identités par pod et les montées de version. Dans les autres cas, il doit surtout savoir dire quand il choisirait EKS et ce que ce choix coûte en exploitation à l'équipe.
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.
