В среде AWS Organizations с несколькими аккаунтами архитектор решений должен разрешить пользователю IAM в Аккаунте A принять роль в Аккаунте B. В среде уже используются SCP, политики на основе ресурсов, политики на основе идентификаторов, политики доверия и политики сессий. Какая комбинация шагов требуется? (Выберите три.)

Для того чтобы пользователь IAM из Аккаунта A мог принять роль в Аккаунте B, необходимо выполнить три ключевых шага. Во-первых, политика доверия (trust policy) целевой роли в Аккаунте B должна быть обновлена, чтобы явно доверять пользователю IAM (или принципалу) из Аккаунта A. Это фундаментальное требование для кросс-аккаунтного принятия роли. Во-вторых, пользователь IAM в Аккаунте A должен иметь политику на основе идентификаторов (identity-based policy), которая разрешает действие sts:AssumeRole для ARN целевой роли в Аккаунте B. Без этого разрешения пользователь не сможет инициировать принятие роли. В-третьих, необходимо убедиться, что SCP (Service Control Policy), прикрепленный к Аккаунту A (или к OU, в которой находится Аккаунт A), не запрещает действие sts:AssumeRole. SCPs могут переопределять разрешения, предоставленные политиками IAM, поэтому их проверка критически важна. Изменение политик на основе ресурсов не требуется, так как принятие роли регулируется политиками IAM и доверия, а не политиками ресурсов. Добавление политики на основе идентификаторов в Аккаунте B для пользователя IAM не имеет смысла, поскольку пользователь находится в Аккаунте A. Настройка политики сессии не является обязательным шагом для базового принятия роли, она используется для более детального контроля разрешений после принятия роли.