Questions d'entretien AWS

Ce que couvrent les entretiens AWS

Exemples de questions d'entretien AWS

• Expliquez la différence entre un groupe de sécurité et une ACL réseau. Quand utiliseriez-vous chacun ?
  Ce qu'une bonne réponse couvre

  • Les groupes de sécurité sont stateful, les ACL réseau sont stateless.
  • Les groupes de sécurité s'appliquent au niveau de l'instance, les ACL réseau au niveau du subnet.
  • Les groupes de sécurité autorisent uniquement (allow rules), les ACL réseau autorisent et refusent (allow/deny).
  • Par défaut, les groupes de sécurité refusent tout trafic entrant et autorisent tout sortant ; les ACL réseau autorisent tout trafic entrant et sortant par défaut.
  • Les ACL réseau sont utiles pour ajouter une couche de contrôle supplémentaire au niveau du subnet, notamment pour bloquer des IP spécifiques.

  Voir un exemple de réponse

  La différence principale entre un groupe de sécurité et une ACL réseau (Network ACL) réside dans leur nature stateful vs stateless. Un groupe de sécurité est stateful : il mémorise l'état des connexions et autorise automatiquement le trafic de retour pour les requêtes sortantes autorisées. Une ACL réseau est stateless : elle nécessite des règles explicites pour le trafic entrant et sortant. De plus, les groupes de sécurité opèrent au niveau de l'instance (attaché à une interface réseau ENI) tandis que les ACL réseau opèrent au niveau du subnet. Les groupes de sécurité ne prennent en charge que des règles d'autorisation (allow), alors que les ACL réseau peuvent avoir des règles d'autorisation et de refus (allow/deny). Par défaut, un groupe de sécurité refuse tout trafic entrant et autorise tout trafic sortant ; une ACL réseau autorise tout le trafic entrant et sortant. On utilise les groupes de sécurité pour la segmentation fine au niveau des instances, par exemple pour autoriser le trafic HTTP vers un serveur web. Les ACL réseau sont utiles pour une couche de protection supplémentaire au niveau du subnet, par exemple pour bloquer des plages IP malveillantes avant qu'elles n'atteignent les groupes de sécurité. Un piège courant est de confondre les deux et d'oublier d'ouvrir le trafic de retour dans les ACL réseau, ce qui peut bloquer les connexions légitimes.

• Concevez une application web hautement disponible et tolérante aux pannes sur AWS. Incluez les composants de calcul, de stockage et de réseau.
  Ce qu'une bonne réponse couvre

  • Utiliser un Elastic Load Balancer (ALB) pour répartir le trafic entre plusieurs zones de disponibilité.
  • Déployer des instances EC2 dans un Auto Scaling Group avec au moins deux AZs.
  • Base de données RDS Multi-AZ pour la haute disponibilité et le basculement automatique.
  • Stockage d'objets S3 pour les assets statiques avec CloudFront pour la distribution mondiale.
  • Route 53 pour le DNS avec le routage de latence ou le DNS failover.
  • VPC avec des sous-réseaux publics et privés pour la sécurité.

  Voir un exemple de réponse

  Pour concevoir une application web hautement disponible et tolérante aux pannes sur AWS, on commence par un équilibreur de charge (ALB) qui répartit le trafic entrant entre plusieurs zones de disponibilité (AZs). Les instances EC2 sont regroupées dans un Auto Scaling Group configuré pour maintenir un nombre minimum d'instances réparties sur au moins deux AZs. Pour la base de données, on utilise RDS en mode Multi-AZ avec un réplica de secours dans une autre AZ pour assurer le basculement automatique. Les assets statiques (images, CSS, JS) sont stockés sur S3, et CloudFront sert de CDN pour réduire la latence. Route 53 gère le DNS avec un routage de latence ou une configuration de basculement pour rediriger le trafic vers une région secondaire en cas de panne. Le réseau est segmenté en sous-réseaux publics (pour l'ALB et les NAT) et privés (pour les instances EC2 et RDS). Un piège courant est de négliger les quotas de service ou les limites de performance, par exemple sous-estimer le nombre de connexions simultanées au niveau de l'ALB. De plus, il faut configurer les health checks appropriés et planifier la reprise après sinistre avec des sauvegardes inter-régions.

• Comment migrer une application monolithique sur site vers AWS avec un temps d'arrêt minimal ? Discutez de la stratégie et des outils.
  Ce qu'une bonne réponse couvre

  • Adopter une stratégie de migration progressive (lift-and-shift puis refactorisation).
  • Utiliser AWS DMS pour la réplication continue de la base de données avec un temps d'arrêt minimal.
  • Utiliser AWS CloudEndure (ou MGN) pour la réplication en continu des serveurs.
  • Utiliser un équilibreur de charge (ALB) pour basculer le trafic progressivement.
  • Planifier une fenêtre de maintenance et tester le rollback.
  • Valider les performances et la sécurité après migration.

  Voir un exemple de réponse

  Pour migrer une application monolithique sur site vers AWS avec un temps d'arrêt minimal, on peut adopter une approche « lift-and-shift » (réhébergement) en utilisant AWS CloudEndure (maintenant AWS MGN - Migration Hub Replication) pour répliquer les serveurs en continu vers AWS. Cela permet de synchroniser les données et de basculer rapidement. Pour la base de données, AWS DMS (Database Migration Service) réplique les modifications en continu vers une instance RDS cible, réduisant l'arrêt à quelques minutes lors du basculement. On peut également utiliser un équilibreur de charge pour rediriger progressivement le trafic de l'ancienne infrastructure vers la nouvelle, en commençant par un petit pourcentage pour valider le comportement. Après la migration, on peut refactoriser progressivement l'application (passage à des microservices, conteneurs). Les pièges incluent la gestion des données volumineuses, les dépendances réseau, et les différences de performances. Il est crucial de bien dimensionner les instances et de tester en conditions réelles avant le basculement final.

• Écrivez une fonction Lambda en Python qui traite les notifications d'événements S3 (par exemple, redimensionnement d'images). Montrez le gestionnaire et la politique IAM.
  Ce qu'une bonne réponse couvre

  • Fonction Lambda déclenchée par un événement S3 (PutObject).
  • Téléchargement de l'image, redimensionnement avec Pillow, enregistrement dans un autre bucket.
  • Gestion des erreurs et journalisation.
  • Politique IAM minimale : permission de lire/écrire sur S3 et d'envoyer des logs à CloudWatch.

  Voir un exemple de réponse

  Voici une fonction Lambda en Python qui redimensionne une image lorsqu'elle est déposée dans un bucket S3. La fonction utilise la bibliothèque Pillow pour traiter l'image et la sauvegarder dans un bucket de destination. La politique IAM associée doit autoriser les actions s3:GetObject sur le bucket source et s3:PutObject sur le bucket de destination, ainsi que logs:CreateLogGroup, logs:CreateLogStream et logs:PutLogEvents pour les logs. Un piège courant est la limite de mémoire et de temps d'exécution de Lambda ; pour des images volumineuses, il faut augmenter la mémoire et éventuellement utiliser une couche Lambda incluant Pillow.

  import boto3
  import os
  from PIL import Image
  from io import BytesIO
  
  s3 = boto3.client('s3')
  
  def lambda_handler(event, context):
      # Récupérer les informations de l'événement S3
      bucket = event['Records'][0]['s3']['bucket']['name']
      key = event['Records'][0]['s3']['object']['key']
      
      # Vérifier que l'objet est une image
      if not key.lower().endswith(('.png', '.jpg', '.jpeg', '.gif')):
          print(f"Fichier ignoré : {key}")
          return
      
      # Télécharger l'image depuis S3
      response = s3.get_object(Bucket=bucket, Key=key)
      image_content = response['Body'].read()
      
      # Redimensionner l'image
      img = Image.open(BytesIO(image_content))
      max_size = (300, 300)
      img.thumbnail(max_size, Image.Resampling.LANCZOS)
      
      # Convertir en octets
      buffer = BytesIO()
      img.save(buffer, format=img.format or 'JPEG')
      buffer.seek(0)
      
      # Sauvegarder dans un bucket de destination (configuré via variable d'environnement)
      dest_bucket = os.environ['DEST_BUCKET']
      dest_key = f"resized/{key}"
      s3.put_object(Bucket=dest_bucket, Key=dest_key, Body=buffer)
      
      print(f"Image redimensionnée et sauvegardée dans {dest_bucket}/{dest_key}")

• Comparez RDS, DynamoDB et ElastiCache. Pour un classement en temps réel, lequel choisiriez-vous et pourquoi ?
  Ce qu'une bonne réponse couvre

  • RDS : base de données relationnelle avec schéma fixe, transactions ACID, adaptée aux requêtes complexes.
  • DynamoDB : base NoSQL clé-valeur et document, haute performance à grande échelle, sans schéma.
  • ElastiCache : cache en mémoire (Redis/Memcached), latence extrêmement faible, données éphémères.
  • Pour un classement en temps réel, ElastiCache (Redis) est le meilleur choix grâce à sa structure de données 'sorted set' et ses opérations atomiques.

  Voir un exemple de réponse

  RDS, DynamoDB et ElastiCache sont trois services de base de données AWS aux usages distincts. RDS est un service de base de données relationnelle avec support de MySQL, PostgreSQL, Oracle, etc. Il offre des transactions ACID et est idéal pour les applications avec des schémas complexes et des requêtes SQL. DynamoDB est une base NoSQL clé-valeur et document entièrement gérée, avec une faible latence et une évolutivité horizontale automatique. Elle convient aux charges de travail nécessitant une haute disponibilité et une mise à l'échelle massive, mais ne supporte pas les jointures complexes. ElastiCache est un service de cache en mémoire compatible Redis ou Memcached, offrant une latence inférieure à la milliseconde. Pour un classement en temps réel, ElastiCache (Redis) est le plus adapté car il fournit des structures de données comme les sorted sets qui permettent de gérer les scores et le classement de manière atomique et efficace. DynamoDB pourrait également fonctionner avec des index secondaires et des expressions de condition, mais les performances en écriture et lecture peuvent être moins bonnes pour des mises à jour fréquentes du classement. RDS serait inapproprié en raison de la latence plus élevée et de la difficulté à gérer les mises à jour concurrentes. Un piège serait de négliger la persistance des données : ElastiCache est volatil par défaut, mais Redis peut être configuré avec des snapshots pour la persistance.

• Décrivez un scénario où vous utiliseriez un point de terminaison VPC au lieu d'une passerelle NAT. En quoi diffèrent-ils en termes de coût et de performance ?
  Ce qu'une bonne réponse couvre

  • Un VPC Endpoint (Gateway) permet une connexion privée aux services AWS (S3, DynamoDB) sans passer par Internet.
  • Une NAT Gateway permet aux instances privées d'accéder à Internet (mises à jour, API externes).
  • Le VPC Endpoint est généralement moins coûteux que la NAT Gateway (pas de frais de données par Go pour le trafic vers le service).
  • Le VPC Endpoint offre une meilleure performance (latence plus faible, bande passante plus élevée) car le trafic reste dans le réseau AWS.
  • Scénario typique : instances privées qui doivent accéder à S3 pour des logs ou des artefacts, sans passer par Internet.

  Voir un exemple de réponse

  On utilise un point de terminaison VPC (VPC Endpoint) au lieu d'une passerelle NAT lorsque l'on souhaite que des instances dans des sous-réseaux privés accèdent de manière privée à des services AWS comme S3 ou DynamoDB, sans nécessiter d'accès à Internet. Par exemple, des instances de traitement de données dans un sous-réseau privé qui doivent télécharger des fichiers depuis S3. En termes de coût, le VPC Endpoint est moins cher : il n'y a pas de frais horaires pour le point de terminaison lui-même (seulement des frais de transfert de données), tandis que la NAT Gateway facture à l'heure et par Go de données traitées. De plus, le trafic via un VPC Endpoint reste entièrement sur le réseau AWS, ce qui offre une latence plus faible et une bande passante plus élevée. En revanche, la NAT Gateway est nécessaire pour tout accès à Internet non AWS (ex : télécharger des patches depuis un dépôt externe). Un piège fréquent est de ne pas associer la politique de point de terminaison correcte : il faut spécifier les actions et ressources autorisées via la politique IAM attachée au VPC Endpoint.

• Comment S3 atteint-il une cohérence forte pour les opérations PUT et DELETE ? Expliquez le modèle sous-jacent.
  Ce qu'une bonne réponse couvre

  • Depuis décembre 2020, S3 offre une cohérence forte en lecture après écriture pour toutes les opérations PUT et DELETE.
  • Auparavant, les opérations de recréation (PUT sur une clé existante) et DELETE pouvaient montrer une cohérence éventuelle.
  • Le modèle sous-jacent repose sur une réplication synchrone dans au moins trois zones de disponibilité.
  • Les opérations PUT et DELETE sont confirmées une fois que la donnée est écrite de manière durable dans toutes les copies.

  Voir un exemple de réponse

  S3 atteint une cohérence forte (read-after-write) pour les opérations PUT et DELETE grâce à un modèle de réplication synchrone. Lorsqu'un objet est créé ou supprimé, la requête est répliquée de manière synchrone sur au moins trois zones de disponibilité distinctes au sein de la région. La demande n'est confirmée au client que lorsque toutes les copies ont été écrites ou supprimées avec succès, garantissant ainsi que les lectures ultérieures reflètent la dernière modification. Avant 2020, S3 offrait une cohérence éventuelle pour les mises à jour (remplacement d'un objet existant par un PUT) et les suppressions, ce qui pouvait entraîner des retards de propagation. Aujourd'hui, toutes les opérations PUT, POST, DELETE et GET (HEAD) bénéficient d'une cohérence forte. Le modèle sous-jacent utilise un mécanisme de quorum basé sur la majorité avec des réplicas dans chaque zone de disponibilité. Un piège à éviter est de supposer que cette cohérence forte s'applique aux opérations de listage (ListObjects) : ListObjects n'est que éventuellement cohérent, donc il peut ne pas refléter immédiatement les nouveaux objets ou les suppressions.

• Écrivez un extrait de modèle CloudFormation qui crée une instance EC2 avec un groupe de sécurité personnalisé et des balises.
  Ce qu'une bonne réponse couvre

  • La ressource AWS::EC2::Instance pour l'instance EC2.
  • La ressource AWS::EC2::SecurityGroup pour le groupe de sécurité avec des règles d'entrée.
  • Utilisation de paramètres pour l'AMI et la KeyName.
  • Ajout de balises (Tags) pour l'instance et le groupe de sécurité.
  • Bonne pratique : définir des sorties pour récupérer des informations comme l'ID de l'instance.

  Voir un exemple de réponse

  L'extrait de modèle CloudFormation ci-dessous crée une instance EC2 avec un groupe de sécurité personnalisé qui autorise les connexions SSH (port 22) et HTTP (port 80) depuis tout le monde (attention, c'est pour l'exemple ; en production, limitez les IP). L'instance et le groupe de sécurité reçoivent des balises pour les identifier. On utilise des paramètres pour rendre le template réutilisable (par exemple, le type d'instance, l'AMI). Des sorties sont définies pour afficher l'ID de l'instance et le nom DNS public. Un piège courant est d'oublier de mapper les groupes de sécurité correctement : on doit d'abord définir le groupe de sécurité, puis l'instance le référence via son ID logique.

  AWSTemplateFormatVersion: '2010-09-09'
  Parameters:
    KeyName:
      Description: Nom de la paire de clés EC2
      Type: AWS::EC2::KeyPair::KeyName
    ImageId:
      Description: AMI ID (ex: ami-xxxxxxxx)
      Type: String
    InstanceType:
      Description: Type d'instance (ex: t2.micro)
      Type: String
      Default: t2.micro
  Resources:
    WebServerSecurityGroup:
      Type: AWS::EC2::SecurityGroup
      Properties:
        GroupDescription: Security group for web server
        SecurityGroupIngress:
          - IpProtocol: tcp
            FromPort: 22
            ToPort: 22
            CidrIp: 0.0.0.0/0
          - IpProtocol: tcp
            FromPort: 80
            ToPort: 80
            CidrIp: 0.0.0.0/0
        Tags:
          - Key: Name
            Value: WebServerSG
          - Key: Environment
            Value: Production
    WebServerInstance:
      Type: AWS::EC2::Instance
      Properties:
        InstanceType: !Ref InstanceType
        ImageId: !Ref ImageId
        KeyName: !Ref KeyName
        SecurityGroupIds:
          - !Ref WebServerSecurityGroup
        Tags:
          - Key: Name
            Value: WebServer
          - Key: Role
            Value: Web
        UserData:
          Fn::Base64: !Sub |
            #!/bin/bash
            yum update -y
            yum install -y httpd
            systemctl start httpd
            systemctl enable httpd
  Outputs:
    InstanceId:
      Description: ID de l'instance EC2
      Value: !Ref WebServerInstance
    PublicDNS:
      Description: Nom DNS public de l'instance
      Value: !GetAtt WebServerInstance.PublicDnsName

Comment se préparer

• Entraînez-vous en pratique : déployez une petite application en utilisant EC2, S3 et RDS. Cassez-la et déboguez en utilisant CloudWatch Logs et VPC Flow Logs.
• Maîtrisez les piliers du AWS Well-Architected Framework (coût, performance, fiabilité, sécurité, excellence opérationnelle) et soyez prêt à discuter des compromis.
• Comprenez les motifs de conception courants : multi-AZ, réplicas de lecture, auto-scaling et déploiements blue/green. Utilisez l'offre gratuite AWS pour expérimenter.
• Soyez à l'aise avec au moins un outil d'infrastructure en tant que code (CloudFormation, CDK ou Terraform) et un langage de script (Python, Node.js).
• Révisez les sessions AWS re:Invent et la documentation officielle des services dont vous revendiquez l'expertise. Les intervieweurs demandent souvent des 'dernières fonctionnalités'.

Questions fréquemment posées