The correct answer is B. GCDS tool only copies the usernames, not the passwords. And more over strict security requirements for the passwords. Not allowed to copy them onto Google, I think. Federation technique help resolve this issue. Please correct me if I am wrong.

"A" will syncronise passwords between on pre-mise and the GCP, this duplicates the existing strategy plus Google's "built-in" encryption of all the data. "B" does not support the moving to GCP. "C" The directory sync tool copies the filesystem settings between servers, UNIX filesystems have permission settings built in and passwords to log into the permission groups, syncing these would set GCP up the same way their on-premises is, plus Google's "built-in" encryption. "D" disrupts the users, so this is not correct. The debate should be between "A" and "C", "C" includes "A" according to (https://cloud.google.com/solutions/migrating-consumer-accounts-to-cloud-identity-or-g-suite-best-practices-federation) so choose "C"

B. Federate authentication via SAML 2.0 to the existing Identity Provider. Here's why: Security: SAML 2.0 allows for secure single sign-on (SSO) without storing passwords on Google's side. It ensures that authentication happens against the corporate Identity Provider (IdP), which maintains control over the user credentials. Minimal Disruption: Users can continue to use their existing corporate credentials to access the application on GCP without having to remember a new set of credentials or go through a password change process. Compliance: It satisfies the security team's requirements for password storage by ensuring that passwords remain within the corporate boundary. Integration: SAML is widely supported and can be integrated with many IdPs, allowing for a seamless transition to cloud-based resources while leveraging existing identity management infrastructure.

The correct answer is C. Google Cloud Directory Sync will provide federated authentications. B is wrong because SAML is used for Single sign-on. It also doesn't mention how the cloud can be authenticated to the existing Identity Provider. SAML by itself is not enough to do the job.

Federating authentication aligns with strict security team requirements for password storage, as it avoids the need to store or sync passwords outside the corporate environment.

Minimal User Disruption: Users continue using their existing corporate credentials for both on-premises and GCP applications, avoiding password resets or new account creations. Security Team Requirements: GCP doesn't store or manage corporate passwords; authentication relies on the existing Identity Provider (IdP), meeting strict password storage requirements.

B is a preferred solution nowadays, that's why: https://cloud.google.com/architecture/framework/security/identity-access#use_a_single_identity_provider

GCDS is better as it is a corporate application. The requirements for storing password can be met by GCP. As GCP has many security features For SAML, the corporate needs to have Identity provider service such as the one provided by Google, Facebook

main reason for B are strict storage requirements.

B is the correct answer

I think it's B because they want minimal user disruption, and only this option focuses on using the same password. Plus, they want to move ONE existing corporate application, not all their infrastructure. A. I don't think this meets a strict security requirement, and if they eventually need to change the password, I think this would not be synced or may have issues syncing both passwords. C. We don't want to provision new users; we want to keep users with minimal disruption and doing what they do already taking the least steps possible. D. Probably a terrible security practice; if anything, we would like them to use one password and sign in from there. B seems to me the most fitting.

The question is ambiguous, though C is the righter answer :-) https://cloud.google.com/architecture/identity/reference-architectures GCP uses GCDS to sync On-prem Azure Directory/LDAP user/groups. It assumes that all on-prem IdP are active directory, which might not be the case.

B. Federate authentication via SAML 2.0 to the existing Identity Provider - Federated authentication allows users to sign in to the Google Cloud Platform using the same credentials they use for their corporate accounts. It delegates the authentication process to an existing Identity Provider (IdP) that the company uses on-premises. This approach minimizes user disruption, as users don't have to remember a separate set of credentials for Google Cloud, and it allows the company to maintain its existing security policies and password storage requirements.

It is C. You move to gcp so copy and use from gcp now.

I don`know what GCDS has to do with passwords, it has to be B

Federation would connect to existing Identity Provider that runs who knows where. Using GCDS corporate accounts will create application user identities in GCP and will let you use those identities in the Cloud (as the question objective implies)

C is the preferred solution in 2023