一家全球性公司使用 AWS Control Tower，并拥有一个集中式 DevOps 账户，其中包含部署到应用程序账户的 CI/CD 管道。集中式 DevOps 账户中的 CodeBuild 项目使用服务角色，并尝试将应用程序部署到应用程序账户中的 EKS 集群。当 CodeBuild 尝试访问跨账户 EKS 集群时，部署失败并显示 Unauthorized。哪项更改将修复授权错误？

正确的做法是在应用程序账户中，更新部署 IAM 角色的信任策略，使其信任集中式 DevOps 账户（允许 sts:AssumeRole）。这是因为 CodeBuild 项目在集中式 DevOps 账户中运行，需要能够代入（assume）应用程序账户中的角色才能执行部署操作。此外，该角色还需要具备访问 EKS 集群的必要权限。最后，为了让 EKS 集群识别并授权该 IAM 角色，必须在集群的 aws-auth ConfigMap 中将该角色映射到相应的 Kubernetes 系统权限。 其他选项错误的原因是： 在集中式 DevOps 账户中更改信任策略是错误的，因为需要被信任的是应用程序账户中的角色，而不是反过来。 使用 sts:AssumeRoleWithSAML 不适用于 CodeBuild 服务角色，它通常用于联合身份验证。 信任 AWS Control Tower 管理账户是错误的，因为部署操作是发生在 DevOps 账户和应用程序账户之间，与 Control Tower 管理账户的直接信任关系无关。