Eine AWS Organization hat eine einzige OU namens Production, die alle Konten enthält. Auf Root-Ebene werden Deny-List-SCPs verwendet, um den Zugriff auf bestimmte Services einzuschränken. Ein neu eingeladenes Konto einer akquirierten Geschäftseinheit kann bestehende AWS Config-Regeln nicht aktualisieren, um die Unternehmensrichtlinien einzuhalten. Welcher Ansatz ermöglicht es den neuen Kontoadministratoren, die erforderlichen Änderungen jetzt vorzunehmen, während die bestehenden Richtlinien beibehalten und durchgesetzt werden, mit minimalem laufendem Wartungsaufwand?

Die korrekte Option löst das Problem, indem sie eine temporäre Onboarding-OU erstellt. Dies ermöglicht die Anwendung eines spezifischen SCPs, der AWS Config-Aktionen erlaubt, ohne die bestehenden Deny-List-SCPs auf Root-Ebene zu ändern. Das Verschieben der Root-SCPs unter die Production-OU ist entscheidend, da SCPs hierarchisch wirken und ein SCP auf einer untergeordneten OU (Onboarding-OU) die Deny-Anweisungen eines übergeordneten SCPs (Root-SCP) nicht außer Kraft setzen kann. Nachdem die Änderungen vorgenommen wurden, kann das Konto in die Production-OU verschoben werden, wodurch es den ursprünglichen Deny-List-SCPs unterliegt. Die erste Option ist falsch, da das Entfernen von Deny-List-SCPs auf Root-Ebene die Sicherheit für alle Konten beeinträchtigen würde. Die zweite Option ist falsch, da ein SCP auf einer untergeordneten OU (Onboarding-OU) die Deny-Anweisungen eines übergeordneten Root-SCPs nicht außer Kraft setzen kann. Die dritte Option ist falsch, da das Umwandeln von Deny-List-SCPs in Allow-List-SCPs eine erhebliche Umstrukturierung darstellt und das Problem nicht sofort löst, da temporäre Ausnahmen für einzelne Prinzipale nicht über SCPs gesteuert werden.