À l'aide d'un modèle AWS CloudFormation, un architecte de solutions déploie une application web à trois niveaux. Les niveaux web et application s'exécutent sur des instances EC2, et le niveau de base de données n'est pas accessible publiquement. Les instances de l'application doivent accéder à Amazon DynamoDB sans exposer les informations d'identification de l'API dans le modèle. Que doit faire l'architecte ?

La bonne approche consiste à créer un rôle IAM avec les autorisations nécessaires pour accéder à DynamoDB et à l'associer aux instances EC2 via un profil d'instance. Cela permet aux instances d'assumer le rôle et d'obtenir des informations d'identification temporaires, éliminant ainsi le besoin de stocker des clés d'accès statiques dans le modèle ou sur les instances, ce qui est une bonne pratique de sécurité. La première option est incorrecte car elle ne mentionne que les autorisations de lecture, alors que l'application pourrait avoir besoin d'écrire dans DynamoDB. Les deux autres options sont incorrectes car elles impliquent l'utilisation de clés d'accès et secrètes directement dans le modèle ou via les données utilisateur, ce qui expose les informations d'identification et est une mauvaise pratique de sécurité.