Una AWS Organization tiene una única OU llamada Production que contiene todas las cuentas. Se utilizan SCPs de lista de denegación (deny-list) a nivel de raíz para restringir el acceso a ciertos servicios. Una cuenta recién invitada de una unidad de negocio adquirida no puede actualizar las reglas existentes de AWS Config para cumplir con la política de la empresa. ¿Qué enfoque permite a los administradores de la nueva cuenta realizar los cambios necesarios ahora, al tiempo que preserva y aplica las políticas existentes con un mantenimiento continuo mínimo?

La opción correcta permite la actualización de AWS Config mientras mantiene las restricciones de seguridad. Al crear una OU de "Onboarding" temporal con un SCP que permite las acciones de AWS Config, la nueva cuenta puede realizar los cambios necesarios. Mover los SCPs de denegación de la raíz a la OU de "Production" asegura que esas políticas se apliquen a todas las cuentas existentes, excepto a la de "Onboarding". Una vez completado el proceso, la cuenta se mueve a "Production", donde los SCPs existentes se aplican automáticamente. Las opciones incorrectas son: Eliminar los SCPs de denegación a nivel de raíz debilitaría la seguridad de toda la organización. Crear una OU de "Onboarding" y adjuntar un SCP que permita AWS Config es un buen primer paso, pero no aborda cómo se aplicarían los SCPs de denegación existentes una vez que la cuenta se mueva a "Production" sin una gestión adicional. Convertir los SCPs de denegación en SCPs de lista de permisos a nivel de raíz es un cambio significativo que podría requerir un esfuerzo considerable para identificar todos los servicios necesarios y podría introducir riesgos de seguridad si no se gestiona correctamente.