Replacing Organization-Level Editor with Time-Bound, Reviewable Access
Northwind Health has 300 data engineers across 40 GCP projects under one organization. Identity comes from Cloud Identity federated to on-prem AD. Engineering leads grant access by adding people to a Google Group named data-admins that holds roles/editor at the organization level. Two access reviews failed because 62% of members could not justify org-level Editor. A recent audit found a contractor using a shared service account key stored in a team wiki. The CISO wants least privilege, time-bound elevation for production data, and verifiable quarterly reviews, without blocking engineers who debug pipelines at 2 a.m. The company already uses Terraform and a change-management ticket system. New tooling budget is limited to native Google Cloud capabilities. The team also has an existing Cloud Identity group structure aligned to on-call rotations, but it is not used for IAM.
1. Design an access model to replace organization-level Editor and the shared service account key. Address least privilege, emergency access, and reviewability, and explain the reasoning behind each component.
Read the worked answer
Start by removing the org-level Editor grant from the data-admins group. Org-level Editor is a broad basic role that cannot be constrained by project or resource, so it makes least privilege and meaningful review impossible. Replace it with project-level or resource-level predefined roles. For data engineers, split duties: pipeline developers get BigQuery Data Editor and Storage Object Admin only in non-production projects; production reads go through a separate group with BigQuery Data Viewer and no write roles.
For 2 a.m. emergencies, use Privileged Access Manager or IAM Conditions with short-lived grants tied to a ticket ID and expiry. The engineer requests elevation through the ticketing workflow; approval can be automated for on-call members, but the grant should expire in 1 to 4 hours and be logged. This preserves response speed while shrinking the standing privilege set. Do not give permanent production write access just to avoid paging delays.
For the shared service account key, eliminate the key. Attach a service account to the workload and use Workload Identity Federation or instance metadata. If a human must impersonate the service account, grant roles/iam.serviceAccountTokenCreator to a group and require short-lived impersonation. Key deletion alone is insufficient if the key was copied; rotate or delete the account and review audit logs for its use.
Make reviews possible by mapping every grant to a group, an owner, a purpose, and a Terraform source. Quarterly reviews should list group memberships and role bindings with the ticket or owner that justifies them. The main failure mode is leaving break-glass access permanent; instead, put break-glass identities in a monitored group with alerting on use.
2. How would you detect and remediate drift from this model, including group membership and role grants, using native tooling? What signal would you prioritize first?
Read the worked answer
Use Cloud Asset Inventory feeds and organization policy constraints to detect drift. Export IAM policy changes and group membership changes to a Pub/Sub topic through Cloud Asset Inventory or Admin SDK Reports. A Cloud Function or Cloud Run service can compare each new binding against an allowlist generated from Terraform state. Native IAM deny policies can block known-bad grants, such as org-level Editor, even if someone tries to re-add them.
Prioritize the signal that matters most: any new principal granted a basic role (Owner, Editor, Viewer) at organization, folder, or project scope. That single signal catches the highest-impact drift and is low-volume compared with all permission changes. Second, alert on additions to groups that hold production data roles, especially external domains. Third, alert on service account key creation, because it indicates a return to the shared-key pattern.
Remediation should be tiered. For a basic role grant, automatically remove the binding and open a ticket; the blast radius is low because the grant was not supposed to exist. For a group membership addition, do not auto-remove without verification if the group is used for on-call; instead, notify the owner with a 24-hour deadline. For a service account key, disable the key and require re-authentication through impersonation. Log every automated action to a separate audit project so that reviewers can reconstruct what happened. Test the automation in a non-production folder first, and include a kill switch. The key reasoning is that automation is safe only when the detected condition is unambiguously outside policy and the rollback path is known.
3. A contractor needs four hours of read access to production BigQuery data. Walk through the grant, approval, revocation, and audit flow, and identify the main failure mode.
Read the worked answer
Create a dedicated group such as contractor-prod-read with no standing members. The contractor authenticates through the company's identity provider, not a personal Gmail account. The approval ticket records the dataset, tables, business justification, and expiry. On approval, automation adds the contractor to the group and grants BigQuery Data Viewer on the specific authorized view or dataset, not the project. If column-level restrictions apply, bind the grant to a policy tag rather than the whole table.
Set an IAM Condition with an expiration timestamp four hours out, or use Privileged Access Manager with a four-hour grant. Both approaches reduce reliance on a human remembering to revoke. At expiry, the condition stops the binding from applying; a scheduled job then removes the group membership and the binding. The contractor should use their own federated identity so BigQuery audit logs show a unique principal, not a shared account.
Audit flow: BigQuery Data Access audit logs record the principal, tables, and query jobs. Route those logs to a restricted logging bucket and to the SIEM. Alert if the contractor queries tables outside the approved dataset or runs export jobs. After the session, the owner reviews the query history and closes the ticket with evidence attached.
The main failure mode is granting dataset-level access when an authorized view would suffice, because a dataset grant exposes every table in it. A secondary failure is time-bound membership without time-bound IAM: if the group membership expires but the direct binding remains, access persists. Test expiry in a staging project before relying on it.