Une entreprise utilise AWS Organizations et déploie toutes les ressources (y compris les politiques IAM et S3) via CloudFormation depuis CodeCommit. Récemment, les développeurs de certains comptes ne peuvent plus accéder à un compartiment S3. Le compartiment a une politique attachée (non montrée ici). Que doit faire l'ingénieur DevOps pour résoudre le problème d'accès ?

La bonne réponse est de s'assurer qu'aucune SCP ou limite d'autorisations IAM ne bloque l'accès. Les politiques de contrôle de service (SCP) dans AWS Organizations peuvent restreindre les autorisations maximales pour les comptes, et les limites d'autorisations IAM peuvent restreindre les autorisations maximales pour les entités IAM (utilisateurs/rôles). Ces deux mécanismes peuvent refuser l'accès même si une politique de compartiment S3 l'autorise. Étant donné que toutes les ressources sont gérées via CloudFormation depuis CodeCommit, toute modification doit être effectuée dans le référentiel et redéployée. Les autres options sont incorrectes car : Modifier la politique de compartiment S3 et désactiver le blocage d'accès public ne résoudrait pas un problème causé par les SCP ou les limites d'autorisations. L'ajout d'une condition aws:SourceAccount est une bonne pratique mais ne résout pas le problème sous-jacent. Vérifier les limites d'autorisations est pertinent, mais utiliser AWS Config pour annuler les modifications bloquantes n'est pas la bonne approche pour résoudre un problème de configuration persistant géré par CloudFormation. Créer une SCP pour empêcher la modification des ressources IAM n'est pas directement lié à la résolution du problème d'accès S3 et pourrait introduire d'autres restrictions non désirées.