Une AWS Organization possède une seule OU nommée Production qui contient tous les comptes. Des SCPs de type "deny-list" au niveau de la racine sont utilisés pour restreindre l'accès à certains services. Un compte nouvellement invité d'une unité commerciale acquise ne peut pas mettre à jour les règles AWS Config existantes pour se conformer à la politique de l'entreprise. Quelle approche permet aux administrateurs du nouveau compte d'effectuer les modifications requises dès maintenant tout en préservant et en appliquant les politiques existantes avec un minimum de maintenance continue ?

La bonne approche est de créer une OU d'intégration temporaire pour le nouveau compte. En attachant un SCP à cette OU qui autorise les actions AWS Config, le nouveau compte peut effectuer les modifications nécessaires. Déplacer les SCPs de la racine vers l'OU Production est crucial car les SCPs sont hérités. Si les SCPs "deny-list" restent à la racine, ils continueront de bloquer les actions même avec un SCP "allow" sur l'OU d'intégration, car un "deny" explicite prévaut toujours. Une fois les modifications terminées, le compte est déplacé dans l'OU Production, où les SCPs existants s'appliqueront, assurant la conformité continue avec un minimum de maintenance. Les autres options sont incorrectes car : Supprimer les SCPs à la racine et utiliser Service Catalog ne résout pas le problème immédiat et introduit une complexité inutile pour une tâche ponctuelle. Créer une OU d'intégration sans déplacer les SCPs de la racine ne fonctionnera pas, car les SCPs "deny" à la racine prévaudront sur tout "allow" dans une OU enfant. Convertir tous les SCPs en "allow-list" est une tâche complexe et risquée qui va au-delà de la résolution du problème immédiat et n'est pas une solution temporaire.