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.

Acm Custom Access Level Hardware Key Trusted Devices | Professional Cloud Security Engineer

Acm Custom Access Level Hardware Key Trusted Devices

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 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

Acm Custom Access Level Hardware Key Trusted Devices

Related questions