A financial organization is implementing Access Context Manager to restrict access to sensitive production APIs. The security team defines the following security posture requirements: Access must be restricted to requests originating from designated corporate IP ranges. Users must authenticate specifically using phishing-resistant hardware security keys (such as Titan Security Keys or FIDO2 tokens). The authentication posture must be continuously enforced across sign-in sessions without falling back to password-only assertions. Which Access Context Manager configuration and identity management adjustment should the security engineer implement?

Create a Custom Access Level in Advanced Mode using Common Expression Language (CEL) evaluating request.auth.claims.crd_str.hwk == true and inIpRange(request.ip, ['...']), and disable the trusted device feature in 2-Step Verification settings.: What Custom Access Levels and Credential Strength Claims Are Access Context Manager (ACM) allows administrators to define fine-grained contextual access rules using either Basic Mode (attributes selected via GUI) or Advanced Mode (expressions written in Common Expression Language (CEL)). Custom Access Levels enable inspection of deep identity claims such as the specific credential strength (crd_str) used during user authentication, including passwords (pwd), SMS (sms), push notifications (push), software OTPs (otp), or hardware keys (hwk). How it meets the requirements Hardware key enforcement (request.auth.claims.crd_str.hwk == true): Advanced CEL expressions allow direct evaluation of whether the user completed 2-Step Verification using a physical hardware security key (hwk), fulfilling the phishing-resistant authentication mandate. IP boundary enforcement (inIpRange): CEL functions like inIpRange(request.ip, ['...']) enforce network perimeter checks alongside identity assertions within a single unified access level. Disabling trusted devices: Google 2-Step Verification includes a feature allowing users to mark devices as trusted to skip second-factor challenges on subsequent logins. If enabled, subsequent logins without a 2SV prompt cause Google to report credential strength as password-only (pwd) rather than hwk or mfa. Disabling trusted devices ensures hardware keys are presented on every sign-in, maintaining valid hwk assertions. Key advantages and capabilities Phishing resistance: Mandating hwk strictly prevents session hijacking through credential harvesting or SIM swapping. Granular logical combinations: Advanced Mode enables rich boolean logic (&&, ||, !) across identity, device, and network contexts. Consistent policy enforcement: Eliminating device-level factor caching guarantees that session assertions accurately reflect the real-time presentation of multi-factor hardware tokens. Why this is optimal Basic Access Levels only support coarse criteria such as IP subnets, geographic regions, and basic device state (such as OS version or encryption status). They cannot inspect authentication method claims or differentiate hardware keys from SMS or OTPs. Combining a CEL-based Custom Access Level with disabled trusted devices is the only way to enforce strict hardware-key compliance.

StudyCerts

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Acm Custom Access Level Hardware Key Trusted Devices

Section: Configuring Access Context Manager.

A financial organization is implementing Access Context Manager to restrict access to sensitive production APIs. The security team defines the following security posture requirements:

Access must be restricted to requests originating from designated corporate IP ranges.
Users must authenticate specifically using phishing-resistant hardware security keys (such as Titan Security Keys or FIDO2 tokens).
The authentication posture must be continuously enforced across sign-in sessions without falling back to password-only assertions.

Which Access Context Manager configuration and identity management adjustment should the security engineer implement?

Create a Basic Access Level specifying the corporate IP subnets and device policy requirements, and enable the trusted device feature in 2-Step Verification settings to cache hardware key assertions.

Create a Basic Access Level with IP conditions and configure an Organization Policy constraint to enforce hardware security keys across the resource hierarchy.

Create a Custom Access Level evaluating request.auth.claims.crd_str.mfa == true in Advanced Mode, while keeping the trusted device feature enabled to streamline user sign-ins.

Create a Custom Access Level in Advanced Mode using Common Expression Language (CEL) evaluating request.auth.claims.crd_str.hwk == true and inIpRange(request.ip, ['...']), and disable the trusted device feature in 2-Step Verification settings.

Professional Cloud Security Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Acm Custom Access Level Hardware Key Trusted Devices

Section: Configuring Access Context Manager.

A financial organization is implementing Access Context Manager to restrict access to sensitive production APIs. The security team defines the following security posture requirements:

Access must be restricted to requests originating from designated corporate IP ranges.
Users must authenticate specifically using phishing-resistant hardware security keys (such as Titan Security Keys or FIDO2 tokens).
The authentication posture must be continuously enforced across sign-in sessions without falling back to password-only assertions.

Which Access Context Manager configuration and identity management adjustment should the security engineer implement?

Create a Basic Access Level specifying the corporate IP subnets and device policy requirements, and enable the trusted device feature in 2-Step Verification settings to cache hardware key assertions.

Create a Basic Access Level with IP conditions and configure an Organization Policy constraint to enforce hardware security keys across the resource hierarchy.

Create a Custom Access Level evaluating request.auth.claims.crd_str.mfa == true in Advanced Mode, while keeping the trusted device feature enabled to streamline user sign-ins.

Explanations

What Custom Access Levels and Credential Strength Claims Are

Access Context Manager (ACM) allows administrators to define fine-grained contextual access rules using either Basic Mode (attributes selected via GUI) or Advanced Mode (expressions written in Common Expression Language (CEL)). Custom Access Levels enable inspection of deep identity claims such as the specific credential strength (crd_str) used during user authentication, including passwords (pwd), SMS (sms), push notifications (push), software OTPs (otp), or hardware keys (hwk).

How it meets the requirements

Hardware key enforcement (request.auth.claims.crd_str.hwk == true): Advanced CEL expressions allow direct evaluation of whether the user completed 2-Step Verification using a physical hardware security key (hwk), fulfilling the phishing-resistant authentication mandate.
IP boundary enforcement (inIpRange): CEL functions like inIpRange(request.ip, ['...']) enforce network perimeter checks alongside identity assertions within a single unified access level.
Disabling trusted devices: Google 2-Step Verification includes a feature allowing users to mark devices as trusted to skip second-factor challenges on subsequent logins. If enabled, subsequent logins without a 2SV prompt cause Google to report credential strength as password-only (pwd) rather than hwk or mfa. Disabling trusted devices ensures hardware keys are presented on every sign-in, maintaining valid hwk assertions.

Key advantages and capabilities

Phishing resistance: Mandating hwk strictly prevents session hijacking through credential harvesting or SIM swapping.
Granular logical combinations: Advanced Mode enables rich boolean logic (&&, ||, !) across identity, device, and network contexts.
Consistent policy enforcement: Eliminating device-level factor caching guarantees that session assertions accurately reflect the real-time presentation of multi-factor hardware tokens.

Why this is optimal

Basic Access Levels only support coarse criteria such as IP subnets, geographic regions, and basic device state (such as OS version or encryption status). They cannot inspect authentication method claims or differentiate hardware keys from SMS or OTPs. Combining a CEL-based Custom Access Level with disabled trusted devices is the only way to enforce strict hardware-key compliance.

View source documentation

Professional Cloud Security Engineer

Acm Custom Access Level Hardware Key Trusted Devices

Professional Cloud Security Engineer

Acm Custom Access Level Hardware Key Trusted Devices

What Custom Access Levels and Credential Strength Claims Are

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Related questions