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.

How 2SV Enforcement Groups Prevent Lockouts and Opt-Outs

Enforcing 2SV With Grace Periods and Session Limits

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.

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.

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.

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.

Explanations

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.

What this configuration does

This configuration attempts to enforce 2SV organization-wide at the root organizational unit (OU) while disabling login challenges and attempting to force SAML Single Sign-On (SSO) on super administrators.

Why it doesn't meet the requirement

Onboarding lockout: Omitting enrollment grace periods prevents new personnel from completing their initial sign-in to register credentials, creating immediate account lockouts.
Misunderstanding of Super Admin authentication: Super administrator accounts intentionally bypass third-party SAML SSO in Cloud Identity to preserve emergency access during IdP outages; attempting to manage their 2SV purely via external SSO profile assignments undermines emergency recovery.
Weakened perimeter: Disabling login challenges removes automated risk-based authentication checks for unusual or unmanaged devices without addressing workstation session lengths.

Key characteristics and limitations

Root-level OU enforcement without grace periods lacks granularity for phased rollouts.
Disabling login challenges lowers defensive posture against credential stuffing and brute-force attacks.
It does not configure the required 16-hour Google Cloud session reauthentication policy or group leave restrictions.

This answer would be correct if

The requirement was to completely disable Google-side contextual verification challenges in favor of a dedicated third-party IdP without managing native Google Cloud session expiration policies.

View source documentation

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.

View source documentation

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.

What this configuration does

This configuration attempts to use Google Cloud IAM Deny policies to enforce 2SV, uses instance metadata to authorize SSH keys, and leaves user web session lifetimes unrestricted.

Why it doesn't meet the requirement

Inapplicable mechanism: IAM Deny policies govern IAM permissions and resource actions; they cannot inspect or enforce Cloud Identity 2SV enrollment states.
Persistence vulnerabilities: Metadata-based SSH keys are evaluated only once at upload time and remain valid across VM lifecycles, failing to provide continuous IAM evaluation or session reauthentication controls.
Unbounded session risk: Setting web sessions to indefinite directly contradicts the requirement to limit persistent workstation tokens to 16 hours.

Key characteristics and limitations

2SV must be configured within Cloud Identity / Google Workspace administrative security controls, not via GCP IAM resource policies.
Metadata SSH keys bypass OS Login and do not revoke access when user account state changes.
Indefinite sessions leave exposed developer workstations vulnerable to long-term credential reuse.

This answer would be correct if

The objective was to block specific Google Cloud IAM API actions using Deny policies regardless of identity authentication state.

View source documentation

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.

What this configuration does

This configuration creates a standard Google Group allowing members to leave at will, enforces immediate 2SV without an enrollment grace period, and sets an extended 30-day session lifetime for Google Cloud services.

Why it doesn't meet the requirement

User lockout risk: Disabling the enrollment grace period causes newly created user accounts to be immediately locked out if 2SV is enforced, as they have not yet had the opportunity to register a second factor during initial provisioning.
Policy circumvention: Setting whoCanLeaveGroup to ALL_MEMBERS_CAN_LEAVE allows users to opt out of the group, thereby escaping any group-based 2SV enforcement policies.
Session token exposure: A 30-day session length leaves persistent OAuth tokens active on developer workstations for an extended duration, increasing exposure to session hijacking and token theft.

Key characteristics and limitations

Standard access groups are designed for resource sharing and collaboration rather than mandatory security control enforcement.
Lack of grace periods creates severe operational friction during employee onboarding.
Extended session lifetimes violate baseline security foundation recommendations for cloud infrastructure access.

This answer would be correct if

The scenario required self-service collaboration access without administrative enforcement, where users could freely join and leave groups and retain long-lived offline sessions.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Enforcing 2SV With Grace Periods and Session Limits

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?

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.

Explanations

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.

What this configuration does

Why it doesn't meet the requirement

Onboarding lockout: Omitting enrollment grace periods prevents new personnel from completing their initial sign-in to register credentials, creating immediate account lockouts.
Misunderstanding of Super Admin authentication: Super administrator accounts intentionally bypass third-party SAML SSO in Cloud Identity to preserve emergency access during IdP outages; attempting to manage their 2SV purely via external SSO profile assignments undermines emergency recovery.
Weakened perimeter: Disabling login challenges removes automated risk-based authentication checks for unusual or unmanaged devices without addressing workstation session lengths.

Key characteristics and limitations

Root-level OU enforcement without grace periods lacks granularity for phased rollouts.
Disabling login challenges lowers defensive posture against credential stuffing and brute-force attacks.
It does not configure the required 16-hour Google Cloud session reauthentication policy or group leave restrictions.

This answer would be correct if

The requirement was to completely disable Google-side contextual verification challenges in favor of a dedicated third-party IdP without managing native Google Cloud session expiration policies.

View source documentation

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

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

View source documentation

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.

What this configuration does

This configuration attempts to use Google Cloud IAM Deny policies to enforce 2SV, uses instance metadata to authorize SSH keys, and leaves user web session lifetimes unrestricted.

Why it doesn't meet the requirement

Inapplicable mechanism: IAM Deny policies govern IAM permissions and resource actions; they cannot inspect or enforce Cloud Identity 2SV enrollment states.
Persistence vulnerabilities: Metadata-based SSH keys are evaluated only once at upload time and remain valid across VM lifecycles, failing to provide continuous IAM evaluation or session reauthentication controls.
Unbounded session risk: Setting web sessions to indefinite directly contradicts the requirement to limit persistent workstation tokens to 16 hours.

Key characteristics and limitations

2SV must be configured within Cloud Identity / Google Workspace administrative security controls, not via GCP IAM resource policies.
Metadata SSH keys bypass OS Login and do not revoke access when user account state changes.
Indefinite sessions leave exposed developer workstations vulnerable to long-term credential reuse.

This answer would be correct if

The objective was to block specific Google Cloud IAM API actions using Deny policies regardless of identity authentication state.

View source documentation

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.

What this configuration does

Why it doesn't meet the requirement

User lockout risk: Disabling the enrollment grace period causes newly created user accounts to be immediately locked out if 2SV is enforced, as they have not yet had the opportunity to register a second factor during initial provisioning.
Policy circumvention: Setting whoCanLeaveGroup to ALL_MEMBERS_CAN_LEAVE allows users to opt out of the group, thereby escaping any group-based 2SV enforcement policies.
Session token exposure: A 30-day session length leaves persistent OAuth tokens active on developer workstations for an extended duration, increasing exposure to session hijacking and token theft.

Key characteristics and limitations

Standard access groups are designed for resource sharing and collaboration rather than mandatory security control enforcement.
Lack of grace periods creates severe operational friction during employee onboarding.
Extended session lifetimes violate baseline security foundation recommendations for cloud infrastructure access.

This answer would be correct if

The scenario required self-service collaboration access without administrative enforcement, where users could freely join and leave groups and retain long-lived offline sessions.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Enforcing 2SV With Grace Periods and Session Limits

Explanations

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.

What this configuration does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

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

How it meets all requirements

Key advantages and capabilities

Why this is optimal

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.

What this configuration does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

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.

What this configuration does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Delegated Admin Roles vs Event Threat Detection

FIDO2 Security Key Enforcement

Secret Manager Automated Key Rotation

Workload Identity Federation vs Service Account Keys

Organization Policy Dry-Run Mode

BigQuery ML

Enforcing 2SV With Grace Periods and Session Limits

Explanations

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.

What this configuration does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

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

How it meets all requirements

Key advantages and capabilities

Why this is optimal

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.

What this configuration does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

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.

What this configuration does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Delegated Admin Roles vs Event Threat Detection

FIDO2 Security Key Enforcement

Secret Manager Automated Key Rotation

Workload Identity Federation vs Service Account Keys

Organization Policy Dry-Run Mode

BigQuery ML

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.

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.

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.

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.