Professional Cloud Security Engineer
Prepare and test your skills
Prepare and test your skills
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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
A security engineer is configuring and troubleshooting context-aware access controls for administrative access to resources protected inside a VPC Service Controls perimeter.
The engineer has created Access Context Manager access levels that enforce device posture verification and IP origin restrictions. Different access bindings were applied to multiple Google Groups in Cloud Identity to govern various developer tiers. During security validation, the engineer discovers that a user assigned to both the Security-Core group (which enforces a strict managed device posture) and the General-Auditors group (which only requires a corporate network IP) can successfully invoke Google Cloud APIs on perimeter-protected resources from an unapproved personal device.
Why is this access permitted, and how should the security engineer remediate the issue?
Access bindings apply exclusively to service accounts and ignore human users; remediate by binding the access level directly to user IAM roles through IAM Conditions.
VPC Service Controls ingress rules evaluate access levels using AND logic across group memberships; remediate by configuring an egress rule with an empty identity selector to drop unmanaged devices.
Standard Cloud Identity access groups allow users to opt out dynamically; remediate by migrating user groups to enforcement groups and replacing access levels with Event Threat Detection rules.
Multiple access bindings applicable to a user are evaluated using OR logic; remediate by making group memberships mutually exclusive or consolidating bindings into a single access binding with scoped access settings.
Access bindings apply exclusively to service accounts and ignore human users; remediate by binding the access level directly to user IAM roles through IAM Conditions.
VPC Service Controls ingress rules evaluate access levels using AND logic across group memberships; remediate by configuring an egress rule with an empty identity selector to drop unmanaged devices.
Standard Cloud Identity access groups allow users to opt out dynamically; remediate by migrating user groups to enforcement groups and replacing access levels with Event Threat Detection rules.
Multiple access bindings applicable to a user are evaluated using OR logic; remediate by making group memberships mutually exclusive or consolidating bindings into a single access binding with scoped access settings.
Access bindings in Google Cloud link Access Context Manager (ACM) access levels directly to user groups or organizational units to enforce context-aware requirements (such as device security posture, geographical location, or corporate IP network) across administrative interfaces like the Google Cloud console and gcloud CLI.
When a user is simultaneously a member of multiple groups that have distinct access bindings applied:
StudyCerts
StudyCertsOR semantics.General-Auditors), the overall request is authorized, effectively bypassing the stricter device posture required by the Security-Core binding.To remediate this context-aware policy loophole, security engineers should implement the following architectural best practices: