Un architecte de solutions conçoit un VPC avec plusieurs sous-réseaux pour héberger des instances EC2 et des instances de base de données Amazon RDS. Le VPC dispose de six sous-réseaux répartis sur deux zones de disponibilité : dans chaque AZ, il y a un sous-réseau public, un sous-réseau privé et un sous-réseau dédié aux bases de données. Seules les instances EC2 des sous-réseaux privés doivent pouvoir accéder aux bases de données RDS. Quelle solution applique cette exigence ?

La bonne réponse est de créer un groupe de sécurité qui autorise le trafic entrant provenant du groupe de sécurité attribué aux instances des sous-réseaux privés et de l'attacher aux instances de base de données. Les groupes de sécurité agissent comme des pare-feu virtuels au niveau de l'instance, contrôlant le trafic entrant et sortant. En spécifiant le groupe de sécurité des instances EC2 privées comme source autorisée, seules ces instances pourront se connecter aux bases de données RDS. Les autres options sont incorrectes : Modifier les tables de routage n'est pas la bonne approche pour contrôler l'accès entre les sous-réseaux au niveau de l'instance ; les tables de routage gèrent le flux de trafic entre les sous-réseaux, pas les autorisations d'accès spécifiques aux instances. Créer un groupe de sécurité qui refuse le trafic entrant n'est pas la méthode standard pour autoriser l'accès ; les groupes de sécurité sont par défaut refusés et nécessitent des règles d'autorisation explicites. Les connexions de peering ne sont pas nécessaires ici car tous les sous-réseaux sont dans le même VPC. Le peering est utilisé pour connecter des VPC distincts.