Configuring Access
Free Google Cloud Certified - Professional Cloud Security Engineer practice — 6 questions on Configuring Access, with explanations. No sign-up. Full 12-question mixed test →
A security engineer at a media company must ensure that a group of external contractors (group: contractors@example.com) can never delete Compute Engine instances, even though this group inherits the Editor role from a legacy binding at the organization level that other teams still depend on. The engineer cannot modify the existing Editor binding because it is required for other principals. Which approach enforces this restriction with the least disruption?
IAM deny policies are evaluated before allow policies and take precedence regardless of any allow grant, including inherited Editor roles. Scoping the deny policy to the folder and targeting only the contractors principal set blocks the delete permission for that group without touching the shared org-level Editor binding.
A workforce is federated into Google Cloud using Workforce Identity Federation with Okta as the external IdP via SAML. The security team must ensure that only users whose Okta SAML assertion contains the attribute department with value finance can assume access through the workforce pool provider — all other authenticated Okta users should be denied federation entirely. What should they configure?
Workforce Identity Federation pool providers support attribute mappings (to map SAML/OIDC assertion attributes to Google attributes like google.subject and google.groups) and attribute conditions, which are CEL expressions evaluated at federation time. Setting a condition on the assertion attribute rejects federation entirely for any subject that doesn't match, before any Google Cloud IAM evaluation occurs.
An organization wants engineers to normally hold no standing IAM roles above Viewer on production projects, but occasionally need temporary elevated access (e.g., Editor) for incident response, with a mandatory approval step from a designated approver and automatic revocation after a fixed duration. Which Google Cloud capability should be used to satisfy this requirement?
Privileged Access Manager lets administrators define entitlements (which role, which resource scope, eligible requesters) that require approval and automatically expire after a configured duration, implementing just-in-time privileged access with an audit trail — exactly matching the requirement for temporary, approved elevation.
A DevOps team runs CI/CD pipelines in GitHub Actions that must deploy to Google Cloud. Security policy prohibits the use of any downloaded service account key files, and access must be restricted so that only workflows running from the repository org/repo-name on the main branch can obtain Google Cloud credentials. What should be configured?
Workload Identity Federation lets external workloads (like GitHub Actions, which issues OIDC tokens) exchange their token for short-lived Google Cloud credentials without any service account key. Attribute conditions on the provider can inspect claims like repository and ref (branch) to restrict which specific repo/branch is allowed to impersonate the target service account — satisfying both the no-keys requirement and the scoping requirement.
A company enforces VPC Service Controls around a perimeter containing BigQuery datasets with sensitive financial data. Analysts must be allowed to query these datasets only when connecting from company-managed, encrypted laptops on the corporate IP range; connections from personal devices or external IPs must be blocked even if the analyst has valid IAM permissions. What should be configured?
Access Context Manager access levels can combine multiple conditions — IP subnetworks and device policy attributes (such as requiring encryption and corporate ownership via endpoint verification/BeyondCorp) — into a single access level. This access level is then referenced in the VPC Service Controls perimeter's ingress policy, so access to the protected BigQuery API is denied unless both device and network context match, independent of IAM permissions.
An organization's audit found that several teams had created user-managed service account keys and stored them insecurely, leading to a credential leak. The CISO wants to prevent any new service account key creation across the entire organization going forward, but one legacy on-premises system in project legacy-sys-prod still requires a key temporarily until it can be migrated to Workload Identity Federation next quarter. What is the best way to enforce this?
Setting constraints/iam.disableServiceAccountKeyCreation at the organization enforces the restriction everywhere by default (inheritance), and organization policies support setting a more permissive override at a lower-level resource (the specific project) to carve out the temporary exception — exactly matching the requirement for org-wide enforcement with one scoped, time-limited exception.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →