Task 1.1: Managing Cloud Identity.

• APassword Sync on the domain controllers, with users signing in at Google

  Incorrect

  Password Sync copies password changes from AD to the Google accounts and users then sign in with Google, which is exactly the password storage the company forbids.

• BGoogle Cloud Directory Sync on an internal server, plus SAML single sign-on with AD FS as the identity provider

  Correct

  GCDS runs inside the company's network, reads AD and performs a one-way sync of users and groups, so nothing reaches into AD from outside. With SAML SSO, AD FS checks the password, so Google never stores or checks it.

• CWorkforce Identity Federation with an AD FS provider and AD groups mapped to google.groups

  Incorrect

  Federated sign-in of this kind creates no Cloud Identity users or Google groups, so the AD-mirroring groups that the IAM grants rely on would not exist.

• DGoogle Cloud Directory Sync on a Compute Engine VM reading a public LDAPS endpoint of AD

  Incorrect

  Pointing the sync at an LDAPS endpoint published on the internet means the domain controllers accept connections from outside, which the company ruled out.

The usual Active Directory pattern for Cloud Identity separates the two jobs. Google Cloud Directory Sync provisions users and groups: it runs as a utility in the customer's own environment, performs a one-way sync and never changes AD. Authentication is federated with SAML to AD FS, so the password stays in AD.

• AEnable super admin self-recovery so that the leads can reset lost credentials without waiting for support

  Incorrect

  Google recommends keeping self-recovery for super admins disabled, and it is disabled by default for new customers, because it gives an attacker another way into the most powerful accounts.

• BKeep one shared super admin account and give its password to all three leads

  Incorrect

  A shared account removes individual accountability and still leaves the most powerful identity in daily use, the opposite of the guidance.

• CRequire IdP-initiated sign-on for these accounts so that the IdP's MFA covers them

  Incorrect

  Super admins are exempt from forced SSO, and allowing IdP-initiated SSO makes them open to name squatting in the IdP; Google suggests taking them out of SSO and protecting them with Google 2-Step Verification.

• DSeparate super admin accounts with security keys, and regular accounts for routine tasks

  Correct

  Google recommends dedicated super admin accounts used only when those privileges are needed, 2-Step Verification with a security key, and a group holding Organization Administrator for daily operations.

Super admin accounts should be rare, separate and heavily protected. Google's guidance is a dedicated account per administrator that is used only for the few tasks needing super admin rights, security-key 2-Step Verification, and an Organization Administrator group for daily work. Self-recovery stays off, and super admins are best kept out of single sign-on.

• ACreate a workforce identity pool with an Okta provider in the organization

  Correct

  A workforce identity pool and provider let users of an external OIDC or SAML IdP sign in to the console and gcloud with SSO, without Google accounts.

• BCreate a workload identity pool with an Okta OIDC provider

  Incorrect

  Workload Identity Federation is for workloads exchanging their credentials for service account access, not for people signing in to the console.

• CGrant the project roles to the principalSet built from the mapped google.groups value

  Correct

  Mapping the IdP's groups to google.groups lets an allow policy grant roles to a principalSet for that group, so only its members get access.

• DRun Google Cloud Directory Sync against the partner's Okta directory

  Incorrect

  GCDS creates Google accounts in Cloud Identity to match a directory, which is the copying of identities the company refuses.

• EInvite each contractor's personal Gmail account to the two projects

  Incorrect

  The company will not rely on Google accounts for the contractors, and consumer accounts sit outside its control.

Workforce Identity Federation authenticates users of an external IdP and is sync-less: no user accounts are stored in Google Cloud. Pools are created at the organization level, providers describe the trust with the IdP, and attribute mappings such as google.groups let allow policies grant roles to a whole group of federated users with a principalSet identifier.

• AAutomatic user provisioning from Entra ID to Cloud Identity, which creates, updates and suspends the accounts as they change in Entra ID

  Correct

  Entra ID's provisioning for Google Cloud creates, updates and suspends users and groups in Cloud Identity as they change in Entra ID, so leavers lose access without manual work.

• BA weekly CSV export from Entra ID that an administrator uploads to the Admin console with the bulk user tool

  Incorrect

  A weekly manual upload still depends on a person and leaves leavers active for up to a week.

• CA shorter Google Cloud session length, so that former employees must sign in again every hour

  Incorrect

  Sign-in goes through Entra ID, but the Cloud Identity account still exists; the account lifecycle is the problem, not the session length.

• DA workforce identity pool alongside the existing Cloud Identity accounts, with both kept for each employee

  Incorrect

  Adding a second federation path doubles the identities to manage and does nothing to remove the stale Cloud Identity accounts.

When Microsoft Entra ID is the source of identities, Google's reference architecture configures Entra ID both for user provisioning, which creates, updates and suspends users and groups in Cloud Identity, and for single sign-on. Automating deprovisioning matters because an account without a counterpart in the IdP can still be a risk.

• AGive the Cloud Run service account domain-wide delegation and let it impersonate a super administrator

  Incorrect

  Domain-wide delegation lets the account act as users, which the team forbids, and the logs would show the impersonated administrator.

• BGive the Cloud Run service account an admin role in the Admin console, without domain-wide delegation

  Correct

  The Groups API accepts a service account that holds an admin role for groups; its actions are logged as the service account and it cannot impersonate users.

• CStore a group administrator's password in Secret Manager and sign in as that user from the script

  Incorrect

  Using a person's password ties the script to that user and records every change under the person's name.

• DGrant the Cloud Run service account Organization Administrator in IAM on the organization resource

  Incorrect

  IAM roles on the organization govern Google Cloud resources; they do not grant administration of groups in Cloud Identity.

The Cloud Identity Groups API can be called by a user, by a service account with domain-wide delegation, or by a service account that has been assigned an admin role for groups. The last option keeps the service account's actions recorded under its own identity and avoids the user impersonation that domain-wide delegation allows.

• ACreate new managed accounts with the same addresses, which replace the private accounts automatically

  Incorrect

  Creating a managed account with a conflicting address leaves the private account in place with a changed address, so its data and access do not move.

• BDelete the private accounts through the Admin console, because they use the verified domain

  Incorrect

  Administrators cannot manage or delete private accounts, even ones that use the company's domain.

• CSend each user a request to transfer the unmanaged account, which turns it into a managed account once the user consents

  Correct

  After the domain is verified, such accounts show up as unmanaged; when a user consents to the transfer, the account becomes managed and keeps its identity and data.

• DAdd the engineers' private accounts to a Google group and grant that group Organization Viewer

  Incorrect

  Granting roles to private accounts gives them more access while leaving them outside the company's control.

A private Google account that uses a corporate address becomes an unmanaged account once the domain is added to Cloud Identity. The administrator can ask the user to transfer it; with consent, it turns into a managed account with the same identity, data and access. Creating a conflicting managed account instead leaves the old account separate.

• ACreate a separate Cloud Identity account and organization for the subsidiary and copy every policy into it

  Incorrect

  A second account creates a second organization whose policies and logs must be duplicated and kept in step.

• BInvite the subsidiary's staff with their private Gmail accounts into the parent's projects

  Incorrect

  Private accounts sit outside the company's control and are blocked by domain-restricted sharing in most organizations.

• CFederate the subsidiary's IdP for its domain through a workforce identity pool in a new organization of its own

  Incorrect

  A separate organization brings the duplicated policy and logging work the company wants to avoid.

• DAdd the subsidiary's domain as a secondary domain of the existing Cloud Identity account

  Correct

  Secondary domains let users with another domain live in the same account, so they fall under the one organization and its controls.

Google's planning guidance favours the smallest number of Cloud Identity or Google Workspace accounts and organizations, because one account means one set of policies, one audit trail and central administration. Additional domains can be added to the account as secondary domains.