Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 21 discussion

https://www.examtopics.com/discussions/amazon/view/74174-exam-aws-certified-solutions-architect-professional-topic-1/ Both option C and option A are valid solutions that meet the requirements for the scenario. ABAC, or attribute-based access control, is a method of granting access to resources based on the attributes of the user, the resource, and the action. This allows for fine-grained access control, which can be useful for implementing a security policy that requires conditional access to the accounts based on user groups and roles. AWS IAM Identity Center (AWS SSO) allows you to connect to your on-premises Active Directory service using SAML 2.0. With this, you can enable automatic provisioning by using the System for Cross-domain Identity Management (SCIM) v2.0 protocol, which allows for the management of user identities in a single location.

A is has options for SAML and SCIM configuration with AD C is all about users and no roles are mentioned. AD User attributes cannot be mapped to IAM users direct D is openID based, MS AD would not support this so I go with A

SCIM v2.0 in the Context of AWS SSO and Active Directory When using AWS IAM Identity Center (AWS SSO) with Active Directory, SCIM v2.0 is utilized to automatically provision and de-provision users and groups. This eliminates the need for manual user or group management and ensures that changes in your on-premises AD are reflected in AWS SSO.

keywords: 'Use active directory to sign in Aws accounts' = AWS IAM Identity Center (AWS Single Sign-On) , SAML 2.0 'conditional access to the accounts based on user groups and roles' = AWS IAM (ABAC)

AWS IAM Identity Center + SAML

A is correct Reasons - Option A mentions about Active Directory as identity Source configuration which solves the purpose of establishing trust and sync from on prem AD using Directory Service. Solves the purpose of using on-prem AD as Single Sign On asked in the question. It is also mentioned that AWS org is in place, which works well with AWS Identity Centre. Gives another validation. It gives us hint of efficiently managing AWS Org accounts / OUs with Identity Centre (Permission Set behind the scene ) to manage RBAC within accounts. Finally this line - "The company's security policy requires conditional access to the accounts based on user groups and roles." is talking about conditional access which can only be solved by ABAC(Attribute Based Access Control). For example user with green attribute should only get access to resources with green attribute. This can be solved by Tag functionality within AWS Identity Centre.

Option A - This option works however it moves authentication and managing user identities from Active Directory to Identity Center but the question states the company wants to use the same authentication service to sign into AWS in reference to Active Directory Option B - This option works but it moves user identity management and authentication tie Identity Center which is not what the question states the company wants to do Option C - This option does not work because in AWS you provision cross-account IAM roles rather than users. Option D - This option might work but it is missing AD FS, a component that enables OIDC flows in AD. Otherwise it maintains user identity management in one place and allows the company to keep using Active Directory for authentication as the question states

Didn't spent time checking if C and D works, because when you have an AWS Organitazion and need to use AD to sign-in to the company’s AWS accounts AWS IdC is the way to go. Now, with AWS IdC we need ADFS and while ADFS does not support SCIM, it is possible to still have your users and groups automatically synchronize with the IAM IDC by using the SCIM API and PowerShell as per https://aws.amazon.com/blogs/modernizing-with-aws/synchronize-active-directory-users-to-aws-iam-identity-center-using-scim-and-powershell/#:~:text=While%20ADFS%20does%20not%20support,the%20SCIM%20API%20and%20PowerShell. Finally, ABAC is an authorization strategy and it is not alternative to IdC Permission Sets. Also the scenario requires conditional access to the accounts based on user groups and roles, this point me to RBAC strategy. I would pick ABAC if the request mentioned user attributes like Department, Cost Center or Project thus.

Answer A for AWS SSO would the right answer at first glance since IAM roles can be mapped to AD groups but it would require additional AD functions like ADFS for SCIM so the next best option is D.

A is a correct one, because need to use the SAML for single sign on from the on-premise directory and also C is not correct because the federated should not come in to the picture federated is for only facebook, twitter, gmail account sign on - but we should use the companies active directory, so A is a correct one.

AD and SCIM don't go together so forget A and B. I've never seen a document talking about integrating OpenID with AWS account login so D is also out. C is doable so I go with C.

I am with B on this one. A is incorrect because you can only use ABAC (Attribute-Based Access Control) with IAM Identity Center Identity Store NOT with Active Directory

As mentioned, SAML 2.0 doesn't directly integrate with AD and requires ADFS proxy as a go between, so the lack of ADFS being mentioned in A or B is throwing people off. However, AD on-premise with direct/VPN connectivity...IAM identify center is the way to go for SSO. I believe ADFS is implied when the question casually mentions "IAM Identify Center connect to AD using SAML 2.0".

federated IdP is required and access to multiple accounts

Answer A and B are wrong!!! Active Directory doesn't support SAML without the use of Active Directory Federation Server!! SCIM is also not supported. The articles that all are pasting here mention the need of an AD connect or the trust between the local AD and an AWS managed Microsoft AD which is not the case here. C is also wrong. Cross account IAM users option doesn't exist. The correct is D!! You can use an OpenID Connect (OIDC) identity provider (e.g OKTA or Azure AD) and sync AD groups in it. You can then use cross account roles to grant access to the federated users https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html https://help.okta.com/en-us/content/topics/directory/ad-agent-manage-users-groups.htm https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html

https://docs.aws.amazon.com/singlesignon/latest/userguide/onelogin-idp.html#onelogin-passing-abac

A: combination SSO + SAML2.0 + AD sounds correct. Automatic provisioning with SCIM means creating users and groups that synced with AD. ABAC seems not too fit for this as the requirements is "requires conditional access to the accounts based on user groups and roles" but that already satisfied with SCIM. B: "use Identity Center as an identity source" -> not using on premise AD -> wrong D: use OIDC -> wrong as on premise AD does not support OIDC. Cannot find an exact source for this but ChatGpt says so.. C: creating users mapped to federated users sounds red flags. Could have been correct if it was "creating roles", the same way with the classic "creating roles for EC2 to access S3 instead of user..." Conclusion: A