Une entreprise héberge une application web à partir d'un compartiment Amazon S3. L'application utilise Amazon Cognito pour authentifier les utilisateurs et renvoie un jeton web JSON (JWT) qui accorde l'accès aux ressources protégées stockées dans un autre compartiment S3. Après le déploiement, les utilisateurs signalent des erreurs et ne peuvent pas accéder au contenu protégé. Un architecte de solutions doit fournir les autorisations correctes afin que les utilisateurs puissent accéder au contenu protégé. Quelle solution répond à ces exigences ?

La solution correcte est de mettre à jour le groupe d'identités Amazon Cognito pour assumer le rôle IAM approprié. Amazon Cognito Identity Pools (groupes d'identités) permettent d'accorder des autorisations AWS temporaires aux utilisateurs authentifiés via des fournisseurs d'identité comme Cognito User Pools. En associant un rôle IAM avec les autorisations nécessaires pour accéder au compartiment S3 protégé au groupe d'identités, les utilisateurs peuvent obtenir des informations d'identification AWS temporaires pour accéder aux ressources. Les autres options sont incorrectes car : Mettre à jour l'ACL S3 n'est pas la méthode recommandée pour gérer les autorisations d'accès aux ressources S3 pour les utilisateurs authentifiés via Cognito. Les politiques de compartiment ou les politiques IAM sont préférables. Redéployer l'application sur Amazon S3 pour des problèmes de cohérence éventuelle n'est pas pertinent ici, car le problème concerne l'accès aux ressources protégées, pas la disponibilité ou la cohérence des données. Mettre à jour le groupe d'utilisateurs Amazon Cognito avec des mappages d'attributs personnalisés est pour la gestion des attributs utilisateur, pas pour l'octroi direct d'autorisations d'accès aux ressources AWS. C'est le groupe d'identités qui gère l'accès aux rôles IAM.