A global company uses AWS Control Tower and has one centralized DevOps account with CI/CD pipelines that deploy into application accounts. A CodeBuild project in the centralized DevOps account uses a service role and tries to deploy an application to an EKS cluster in an application account. The deployment fails with Unauthorized when CodeBuild attempts to access the cross-account EKS cluster. What change will fix the authorization error?

The CodeBuild project in the centralized DevOps account needs to assume a role in the target application account to deploy to the EKS cluster. Therefore, the application account must define an IAM role with a trust policy allowing the centralized DevOps account's CodeBuild service role to assume it (sts:AssumeRole). This assumed role then needs the necessary EKS permissions. Finally, for Kubernetes to authorize actions, this assumed IAM role must be mapped to appropriate Kubernetes RBAC permissions within the EKS cluster's aws-auth ConfigMap. Incorrect options: Changing the centralized DevOps account's role trust policy to trust the application account is backward; the target account needs to trust the source. sts:AssumeRoleWithSAML is for federated identities, not cross-account service role assumption. Trusting the AWS Control Tower management account is irrelevant for direct cross-account access between the DevOps and application accounts for EKS deployment.