W środowisku AWS Organizations z wieloma kontami, architekt rozwiązań musi zezwolić użytkownikowi IAM w Koncie A na przyjęcie roli w Koncie B. Środowisko używa już SCP, polityk opartych na zasobach, polityk opartych na tożsamościach, polityk zaufania i polityk sesji. Jaka kombinacja kroków jest wymagana? (Wybierz trzy.)

Aby użytkownik IAM z Konta A mógł przyjąć rolę w Koncie B, wymagane są trzy kluczowe elementy. Po pierwsze, polityka oparta na tożsamości dołączona do użytkownika IAM w Koncie A musi jawnie zezwalać na akcję sts:AssumeRole dla ARN docelowej roli w Koncie B. Po drugie, polityka zaufania (trust policy) docelowej roli w Koncie B musi ufać podmiotowi (użytkownikowi IAM lub roli) z Konta A, zezwalając mu na przyjęcie tej roli. Po trzecie, Service Control Policies (SCP) w AWS Organizations, które mają zastosowanie do Konta A, nie mogą jawnie odmawiać akcji sts:AssumeRole. Jeśli SCP odmawia tej akcji, nadpisze wszystkie inne zezwolenia. Modyfikowanie polityk opartych na zasobach jest niepotrzebne, ponieważ polityka zaufania roli jest wystarczająca do zarządzania dostępem do roli. Dodawanie polityki opartej na tożsamości w Koncie B dla użytkownika IAM jest błędne, ponieważ użytkownik znajduje się w Koncie A. Konfigurowanie polityki sesji nie jest podstawowym krokiem do samego przyjęcia roli, ale raczej opcjonalnym mechanizmem do precyzyjnego kontrolowania uprawnień sesji po przyjęciu roli.