Una empresa desea que los desarrolladores adquieran software de terceros aprobado únicamente a través de un Private Marketplace en AWS Marketplace. La empresa utiliza AWS Organizations con todas las características habilitadas y tiene una cuenta de servicios compartidos en cada OU para los gerentes de adquisiciones. La administración de adquisiciones debe limitarse a un rol llamado procurement-manager-role (asumible por los gerentes de adquisiciones). A todos los demás usuarios, grupos, roles de IAM y administradores de cuentas se les debe denegar el acceso administrativo a Private Marketplace. ¿Cuál es la arquitectura MÁS eficiente para cumplir con estos requisitos?

La opción correcta es la más eficiente porque utiliza Controles de Servicio (SCP) a nivel de la organización para aplicar restricciones de forma centralizada. Al adjuntar la política administrada AWSPrivateMarketplaceAdminFullAccess al rol procurement-manager-role en las cuentas de servicios compartidos, se otorga el permiso necesario. El SCP a nivel de raíz que deniega la administración de Private Marketplace a todos, excepto a ese rol específico, asegura que solo los gerentes de adquisiciones puedan realizar estas acciones. El segundo SCP que deniega la creación de un rol con el mismo nombre evita que otros usuarios eludan la restricción creando un rol idéntico. Las opciones incorrectas no son tan eficientes o seguras: La primera opción requiere la creación de roles y la aplicación de políticas en línea en todas las cuentas, lo cual es menos escalable que los SCP. Además, PowerUserAccess no es la política correcta para administrar Private Marketplace. La segunda opción usa AdministratorAccess y límites de permisos, lo cual es excesivo y no restringe la creación de roles o el acceso a Private Marketplace de manera efectiva a través de la organización. La cuarta opción aplica el SCP solo a las cuentas de servicios compartidos, lo que dejaría a otras cuentas de la organización sin la restricción deseada.