Uma organização usa o AWS Organizations com contas separadas para finanças e marketing. O aplicativo de processamento de dados da equipe de finanças (na conta de finanças) usa o Lambda e armazena dados confidenciais em uma tabela DynamoDB. A equipe de marketing (em uma conta diferente) deve ter acesso apenas a atributos específicos dessa tabela DynamoDB. Como um arquiteto de soluções deve fornecer à equipe de marketing o acesso limitado necessário?

A opção correta descreve um padrão de acesso entre contas seguro e eficaz. Criar uma função do IAM na conta de finanças com uma política que usa condições para acesso granular (Attribute-level access control) ao DynamoDB permite controlar exatamente quais atributos a função pode ver. Estabelecer uma relação de confiança com a conta de marketing permite que usuários ou funções dessa conta assumam a função na conta de finanças, herdando suas permissões restritas. A criação de uma SCP é incorreta porque SCPs não concedem permissões; elas definem limites máximos de permissões para entidades dentro de uma OU. Uma política baseada em recurso no DynamoDB não é a melhor abordagem para acesso entre contas, pois a política do IAM na conta de marketing ainda precisaria de permissões para acessar a tabela, e a política baseada em recurso não gerencia a assunção de função. O uso de um limite de permissões (permissions boundary) não é a solução primária para conceder acesso granular entre contas; ele define o limite máximo de permissões para uma entidade, mas não concede as permissões em si.