A company is implementing a zero-trust authentication policy across its Google Cloud organization using Cloud Identity. The security architect must configure 2-Step Verification (2SV) enforcement for developers and administrators while satisfying the following requirements: New hires must be granted a ramp-up period to enroll physical security keys upon account provisioning to avoid initial login lockouts. Users must not have the ability to opt out or remove themselves from security enforcement groups. Persistent token risk on developer workstations must be mitigated by enforcing reauthentication for Google Cloud services at least every 16 hours. Which set of configuration actions should the security architect take?

Configure an enforcement group with the Groups Settings API setting `whoCanLeaveGroup` set to `NONE_CAN_LEAVE`, define a 2SV new user enrollment grace period, and configure the Google Cloud session length reauthentication policy to 16 hours.: ### What the recommended Cloud Identity configuration is This configuration establishes a secure, automated 2-Step Verification (2SV) rollout lifecycle using **Cloud Identity enforcement groups**, administrative **enrollment grace periods**, and session lifetime controls for Google Cloud services. ### How it meets all requirements - **Preventing user onboarding lockouts:** Enabling a **new user enrollment grace period** in Cloud Identity allows newly provisioned identities a configurable time window (e.g., from 1 day to several weeks) to log in and register their phishing-resistant security keys before strict 2SV enforcement blocks their account access. - **Preventing self-removal from enforcement groups:** Setting the `whoCanLeaveGroup` attribute to `NONE_CAN_LEAVE` via the **Groups Settings API** enforces mandatory access control, preventing users from opting out of the security enforcement group. - **Mitigating persistent session token risk:** Applying a **16-hour session reauthentication policy** specifically for Google Cloud services revokes long-lived developer workstation OAuth tokens and mandates security key re-verification at regular intervals. ### Key advantages and capabilities - **Phishing resistance:** Mandates FIDO-compliant hardware tokens (such as Titan Security Keys) across administrative personnel. - **Mandatory access governance:** Ensures security policies applied through enforcement groups cannot be altered or bypassed by end users. - **Seamless onboarding:** Eliminates administrative overhead and help desk tickets caused by immediate day-one account lockouts. - **Credential hygiene:** Restricts the attack window of stolen developer credentials or compromised workstation tokens by enforcing continuous session refresh limits. ### Why this is optimal This approach directly leverages Cloud Identity's built-in authentication lifecycle settings and Google Cloud session management best practices without relying on brittle custom scripts or insecure administrative exceptions.

Cloud Identity 2sv Enforcement Session Policy | Professional Cloud Security Engineer

Cloud Identity 2sv Enforcement Session Policy

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A company is implementing a zero-trust authentication policy across its Google Cloud organization using Cloud Identity. The security architect must configure 2-Step Verification (2SV) enforcement for developers and administrators while satisfying the following requirements:

New hires must be granted a ramp-up period to enroll physical security keys upon account provisioning to avoid initial login lockouts.
Users must not have the ability to opt out or remove themselves from security enforcement groups.
Persistent token risk on developer workstations must be mitigated by enforcing reauthentication for Google Cloud services at least every 16 hours.

Which set of configuration actions should the security architect take?

Apply 2SV enforcement strictly at the root organizational unit without grace periods, configure SAML SSO profile assignments to override super admin logins, and disable login challenges across the organization.

Create a standard access group with whoCanLeaveGroup set to ALL_MEMBERS_CAN_LEAVE, turn off the enrollment grace period to force day-one compliance, and set the Google Cloud session length to 30 days.

Deploy an IAM Deny policy targeting non-2SV users in Google Cloud IAM, manage developer sessions via metadata-based SSH keys, and set Google Workspace web session duration to indefinite.

Configure an enforcement group with the Groups Settings API setting whoCanLeaveGroup set to NONE_CAN_LEAVE, define a 2SV new user enrollment grace period, and configure the Google Cloud session length reauthentication policy to 16 hours.

Professional Cloud Security Engineer

Cloud Identity 2sv Enforcement Session Policy

Related questions