En un entorno de AWS Organizations de múltiples cuentas, un arquitecto de soluciones debe permitir que un usuario de IAM en la Cuenta A asuma un rol en la Cuenta B. El entorno ya utiliza SCPs, políticas basadas en recursos, políticas basadas en identidad, políticas de confianza y políticas de sesión. ¿Qué combinación de pasos se requiere? (Elija tres).

Para permitir que un usuario de IAM en la Cuenta A asuma un rol en la Cuenta B, se requieren tres pasos clave. Primero, el SCP (Service Control Policy) adjunto a la Cuenta A debe permitir (o no denegar explícitamente) la acción sts:AssumeRole, ya que los SCPs actúan como un guardián de permisos máximo en AWS Organizations. Segundo, el usuario de IAM en la Cuenta A necesita una política basada en identidad que le otorgue permiso para ejecutar sts:AssumeRole en el ARN específico del rol de destino en la Cuenta B. Sin esta política, el usuario no tendrá la autorización necesaria. Tercero, la política de confianza del rol de destino en la Cuenta B debe ser actualizada para confiar en el usuario de IAM (o la cuenta) de la Cuenta A como principal, permitiéndole asumir el rol. Las políticas basadas en recursos no son el mecanismo principal para asumir roles entre cuentas. Agregar una política basada en identidad en la Cuenta B para el usuario de IAM no es aplicable, ya que el usuario reside en la Cuenta A. Configurar una política de sesión es un paso opcional para refinar los permisos después de asumir un rol, no un requisito para la acción inicial de asumir el rol.