Une application sur EC2 utilisait auparavant les clés d'accès d'un utilisateur IAM stockées dans des variables d'environnement pour appeler DynamoDB via boto. Le développeur a attaché un rôle d'instance avec les mêmes autorisations, puis a supprimé l'utilisateur IAM. Après le redémarrage, les journaux de l'application affichent AccessDeniedException, mais le développeur peut exécuter des commandes CLI DynamoDB en utilisant son compte personnel sur le serveur. Quelle est la cause la PLUS probable de l'exception ?

L'application utilise toujours les clés d'accès de l'utilisateur IAM stockées dans les variables d'environnement, même après la suppression de l'utilisateur. Les applications vérifient d'abord les variables d'environnement pour les informations d'identification avant de rechercher d'autres sources, comme les rôles d'instance. Puisque l'utilisateur IAM a été supprimé, ces informations d'identification sont maintenant invalides, ce qui entraîne une AccessDeniedException. Le développeur peut utiliser la CLI car il utilise ses propres informations d'identification valides. La propagation des politiques IAM est généralement rapide et n'est pas la cause la plus probable ici. Le SDK AWS prend en charge les informations d'identification des rôles d'instance. Le groupe de sécurité n'est pas en cause car l'accès à 169.254.169.254 (le service de métadonnées d'instance) est requis pour récupérer les informations d'identification du rôle d'instance, mais le problème est que l'application n'essaie même pas de les récupérer.