Task 1.3: Managing authentication.

• AAn IAM condition on their role bindings that expires four hours after each grant

  Incorrect

  An expiring binding removes access rather than asking the user to sign in again, and it would have to be recreated after every expiry.

• BAn Access Context Manager access level that requires a corporate device for these users

  Incorrect

  Access levels judge device and network attributes at request time; they do not force a periodic sign-in.

• CGoogle Cloud session control on their organizational unit, with reauthentication every 4 hours by security key

  Correct

  Google Cloud session control sets a reauthentication frequency between 1 and 24 hours for the console, gcloud and apps that use Google Cloud scopes, per organizational unit, with password or security key as the method.

• DThe organization policy that limits OAuth access token lifetime to four hours

  Incorrect

  Credential lifetime constraints concern service account tokens, not how often a person must reauthenticate to the console and gcloud.

Reauthentication for Google Cloud is set in the Admin console under Google Cloud session control. It applies to the Google Cloud console, the gcloud CLI and applications requesting Google Cloud scopes, can be set per organizational unit, ranges from 1 to 24 hours, and can require a password or a security key.

• AOnly security key enforcement on the Admins organizational unit, with a new user enrollment period of one week

  Correct

  Enforcement is set per organizational unit, the Only security key method accepts security keys and passkeys, which are phishing resistant, and the new user enrollment period gives new hires time to enroll.

• B2SV enforcement on the top-level organizational unit with any method allowed and a one-week enrollment period

  Incorrect

  Any method allows SMS and phone prompts, which are not phishing resistant, and the top-level unit forces the setting on everyone.

• CA password policy on Admins requiring strong passwords and a change at next sign-in

  Incorrect

  Password strength rules do not add a second factor at all.

• DBackup codes issued to every administrator and stored in the team's password vault

  Incorrect

  Backup codes are a recovery aid, not a phishing-resistant method, and a shared vault of codes weakens the control.

2-Step Verification is enforced per organizational unit or group in the Admin console. For phishing resistance, the Only security key method allows security keys and passkeys. The New user enrollment period gives new accounts time to enroll before enforcement applies to them.

• ASet the same requirement in Active Directory's own password policy

  Correct

  Passwords that arrive as hashes from Password Sync bypass the Admin console's strength checks, so the rule must be set where the password is chosen.

• BTurn on password expiration every 90 days in the Admin console so that users pick new passwords

  Incorrect

  New passwords would again come from AD through Password Sync, still without the length check.

• CSet Enforce password policy at next sign-in, so that synced users change their passwords at Google

  Incorrect

  A password changed at Google would be overwritten by the next sync from AD, and synced hashes skip the check anyway.

• DReset every user's password from the Admin console with a generated long password before the next Active Directory sync

  Incorrect

  Strength rules do not apply to manually reset passwords either, and the next change in AD would sync over them.

Google cannot check strength or length for passwords set as hashes, which is how the bulk upload tool, the Directory API, Password Sync and GCDS set them. When passwords originate in Active Directory, the length and complexity rules belong in AD's password policy.

• ATurn off SSO for the contractors' unit and let them use Google passwords with 2-Step Verification

  Incorrect

  Turning SSO off means Google authenticates them, not the agency's identity provider as required.

• BA second SSO profile with the agency IdP's settings, assigned to the contractors' organizational unit

  Correct

  SSO profiles hold an IdP's settings and can be assigned to organizational units or groups, so each set of users goes to its own IdP.

• CFederate the agency's IdP inside the corporate Okta tenant, then remove the contractors from Cloud Identity

  Incorrect

  Chaining the agency through Okta and deleting the Cloud Identity accounts changes both systems instead of using Google's per-unit SSO setting.

• DA workload identity pool that trusts the agency's IdP for the contractors' sign-ins

  Incorrect

  Workload identity pools are for workloads, not for people signing in to Google Cloud.

Cloud Identity supports several SSO profiles, SAML or OIDC, each holding the settings of one identity provider. Profiles are assigned to organizational units or groups, and SSO can be turned off for selected units, so different populations can authenticate at different IdPs.

• AA standard API key restricted to the Cloud Storage API and to the app's HTTP referrer

  Incorrect

  Restrictions limit where a key can be used, but a standard API key identifies no principal, so it cannot carry each employee's permissions.

• BA single service account with Storage Object Viewer on all buckets, used by the application backend

  Incorrect

  One service account sees every file, so employees could read each other's data through the app.

• CAn OAuth 2.0 client, so that each employee signs in and consents to the app acting on their behalf

  Correct

  OAuth 2.0 gives the app a token for the signed-in user, and Cloud Storage authorizes each request with that user's IAM permissions.

• DSigned URLs created by the app with its own key for every file that an employee requests

  Incorrect

  Signed URLs grant whoever holds them access with the signer's rights; they do not check the employee's own permissions.

To act for a user, an application uses OAuth 2.0: the user signs in and consents, and the app receives credentials that represent the user, so IAM applies the user's own permissions. A standard API key does not authenticate a principal, which is why Google limits API keys to APIs that accept them and recommends restricting them.

• AGoogle Cloud session control, with reauthentication every 8 hours

  Incorrect

  That setting reaches only Google Cloud access; Gmail and the other web apps would keep their 14-day sessions.

• BAn IAM condition that limits every role binding to office hours

  Incorrect

  Conditions on bindings decide when access is allowed; they do not end users' web sessions.

• CPassword expiration every 8 hours in the password policy

  Incorrect

  Password expiration forces a new password at sign-in; it is not a session limit, and this frequency would be unworkable.

• DGoogle session control in the Admin console, with the web session length set to 8 hours

  Correct

  Google session control sets the web session length for all Google web properties a user signs in to, replacing the 14-day default.

Google session control in the Admin console sets the web session length for all Google services, 14 days by default. A separate setting covers Google Cloud reauthentication only, and Google suggests using the two together.