Em um ambiente AWS Organizations multi-conta, um arquiteto de soluções deve permitir que um usuário IAM na Conta A assuma uma role na Conta B. O ambiente já usa SCPs, políticas baseadas em recursos, políticas baseadas em identidade, políticas de confiança e políticas de sessão. Qual combinação de etapas é necessária? (Escolha três.)

Para permitir que um usuário IAM na Conta A assuma uma role na Conta B, três componentes principais devem estar configurados corretamente. Primeiro, o Service Control Policy (SCP) aplicado à Conta A (ou a qualquer OU pai) não deve negar explicitamente a ação sts:AssumeRole, pois SCPs podem restringir permissões em toda a organização. Segundo, o usuário IAM na Conta A precisa de uma política baseada em identidade que conceda a permissão sts:AssumeRole no ARN da role de destino na Conta B. Terceiro, a política de confiança da role de destino na Conta B deve permitir que o principal (o usuário IAM ou a conta da qual o usuário faz parte) da Conta A assuma essa role. Modificar políticas baseadas em recursos não é o método correto para permitir sts:AssumeRole entre contas, pois a assunção de role é controlada por políticas de identidade e confiança. Adicionar uma política baseada em identidade na Conta B para o usuário IAM não faz sentido, pois o usuário está na Conta A. Configurar uma política de sessão com GetSessionToken não é o mecanismo principal para permitir a assunção de role entre contas, mas sim para refinar as permissões da sessão assumida.