An enterprise wants its workforce to sign in to the AWS Management Console using the company's existing SAML 2.0 identity provider, receiving only temporary credentials scoped to a defined set of permissions, without creating an IAM user for each employee. Which two configurations in IAM together enable this federated, least-privilege access? (Select TWO.)
- ACreate an IAM SAML identity provider entity in the account from the metadata document exported by the company identity provider. Correct
- BCreate an IAM user for each employee and distribute long-lived access keys generated from the identity provider's user directory.
- CCreate an IAM role whose trust policy allows sts:AssumeRoleWithSAML for the SAML provider and attaches only the scoped permissions policy. Correct
- DCreate an Amazon Cognito user pool and point the company identity provider at it so employees authenticate through the pool.
- EAttach a permissions boundary to the federated role that grants the console access permissions the employees require.
Why A is correct: The SAML identity provider entity registers the external IdP as a trusted federation source, which IAM requires before any role can be assumed through SAML.
Why B is wrong: Per-employee IAM users feel like a direct mapping, but they defeat the federation goal and reintroduce the long-lived credentials the requirement is trying to remove.
Why C is correct: The role's trust policy lets federated users assume it through the SAML provider while its permissions policy bounds them to least privilege, issuing temporary credentials on sign-in.
Why D is wrong: Cognito user pools are tempting because they also federate, but they target application and customer sign-in rather than IAM console access for the workforce.
Why E is wrong: A permissions boundary sounds like it grants access, but it only caps the maximum permissions a principal can have and never grants any access on its own.