Organizacja AWS ma jedną jednostkę organizacyjną (OU) o nazwie Production, która zawiera wszystkie konta. Korzysta z SCP typu deny-list na poziomie głównym, aby ograniczyć dostęp do niektórych usług. Nowo zaproszone konto z przejętej jednostki biznesowej nie może aktualizować istniejących reguł AWS Config w celu zapewnienia zgodności z polityką firmy. Które podejście pozwoli administratorom nowego konta na wprowadzenie wymaganych zmian teraz, zachowując i egzekwując istniejące polityki przy minimalnym bieżącym utrzymaniu?

Prawidłowa odpowiedź zakłada utworzenie tymczasowej jednostki organizacyjnej (OU) Onboarding z SCP zezwalającym na działania AWS Config. Przeniesienie istniejącego SCP typu deny-list na poziom OU Production, a nie na poziom główny, pozwala na dziedziczenie tego SCP przez konta w OU Production, jednocześnie umożliwiając nowemu kontu w OU Onboarding wykonywanie wymaganych zmian. Po zakończeniu modyfikacji, konto można przenieść do OU Production, gdzie będzie podlegać istniejącym politykom. Pozostałe opcje są mniej optymalne: Usunięcie SCP na poziomie głównym jest zbyt szerokie i narusza istniejące polityki. Service Catalog to dobre narzędzie, ale nie rozwiązuje problemu blokady dostępu do Config. Tworzenie tymczasowego OU z zezwalającym SCP, ale bez przeniesienia głównego SCP, oznacza, że główne SCP nadal będzie blokować Config, nawet jeśli OU Onboarding ma zezwalające SCP (deny-list ma pierwszeństwo). Przekształcenie SCP na allow-list jest znaczącą zmianą architektoniczną i wymagałoby zezwolenia na wszystkie usługi, co jest sprzeczne z zasadą najmniejszych uprawnień. Tymczasowe dołączenie SCP zezwalającego na poziomie głównym również jest zbyt szerokie.