Un développeur débogue une application qui utilise Amazon DynamoDB (us-west-2). L'application s'exécute sur une instance Amazon EC2 et a besoin d'un accès en lecture seule à une table nommée Cars. L'instance EC2 possède un rôle IAM avec une politique attachée, mais lorsque l'application tente de lire la table Cars, elle reçoit une erreur Access Denied. Comment le développeur devrait-il résoudre ce problème ?

La bonne réponse est de créer une politique de confiance qui liste le principal de service EC2 et d'attacher cette politique de confiance au rôle. Une politique de confiance (Trust Policy) définit qui peut assumer le rôle IAM. Dans ce scénario, l'instance EC2 a besoin de la permission d'assumer le rôle pour que les applications s'exécutant sur l'instance puissent utiliser les permissions du rôle. Si la politique de confiance est incorrecte ou manquante, l'instance EC2 ne pourra pas assumer le rôle, ce qui entraînera une erreur d'accès refusé même si la politique d'autorisations du rôle est correcte. Modifier la ressource de la politique IAM en "arn:aws:dynamodb:us-west-2:account-id:table/" ou mettre à jour la politique IAM pour inclure l'action dynamodb: ne résoudrait pas le problème si l'instance EC2 ne peut pas assumer le rôle en premier lieu. Créer une relation de confiance entre le rôle IAM et le principal de service dynamodb.amazonaws.com est incorrect car DynamoDB n'a pas besoin d'assumer ce rôle ; c'est l'instance EC2 qui en a besoin.