A multi-national enterprise manages its workloads across multiple AWS accounts organized under AWS Organizations. The company has established SAML 2.0 federation with Okta to allow database administrators to log in and manage resources in a dedicated database account. The administrators must assume an IAM role named `DBAdminRole` in the database account.
To enforce compliance, the security team attached a Service Control Policy (SCP) to the database account's Organizational Unit (OU) that explicitly allows only Amazon RDS and Amazon DynamoDB actions, while denying all other services. To minimize administrative overhead within the database account, the team created the `DBAdminRole` without any inline or managed IAM identity-based policies, assuming the OU-level SCP would grant the necessary database permissions to the federated role.
During testing, database administrators are unable to access any resources after authenticating through Okta. Additionally, logs show that some administrators cannot assume the role at all because the role's trust policy is configured with `sts:AssumeRole` instead of `sts:AssumeRoleWithSAML`.
Which combination of actions will resolve these issues and allow the database administrators to perform their duties?
- AUpdate the trust policy of `DBAdminRole` in the database account to use the `sts:AssumeRole` action with the Okta SAML provider as the principal, and attach an IAM identity-based policy to `DBAdminRole` that explicitly grants the required RDS and DynamoDB permissions.
- BUpdate the trust policy of `DBAdminRole` in the database account to use the `sts:AssumeRoleWithSAML` action with the Okta SAML provider as the federated principal, and modify the SCP at the OU level to include an Allow statement that explicitly grants database access to the federated role principal without attaching local IAM policies.
- Update the trust policy of `DBAdminRole` in the database account to use the `sts:AssumeRoleWithSAML` action with the Okta SAML provider as the federated principal, and attach an IAM identity-based policy to `DBAdminRole` that explicitly grants the required RDS and DynamoDB permissions.Cevap
- DUpdate the trust policy of `DBAdminRole` in the database account to use the `sts:AssumeRoleWithWebIdentity` action with the Okta SAML provider as the principal, and modify the database account's default IAM settings to allow SCP permissions to inherit directly to all roles that have a trust relationship with external providers.