Configure access
Configure access
This domain tests whether you can design and troubleshoot least-privilege access on Google Cloud. Expect questions on IAM policy inheritance, service accounts, federation, conditions, and why a principal still has access after a binding appears correct.
Core rules
- Resource hierarchy: IAM allow policies inherit from organization to folder to project to resource. A grant at a higher node applies to all descendants; you cannot subtract a permission with a lower-level allow policy. IAM deny policies are separate, evaluate before allows, and an explicit deny wins.
- Principals and roles: Prefer Google Groups over individual users, and predefined roles over basic roles (Owner, Editor, Viewer). Custom roles add granularity but are not automatically updated when Google adds permissions. Grant roles/iam.serviceAccountUser only when a principal must attach or impersonate a service account; it is effectively impersonation for every service account in scope.
- Service accounts: Treat them as identities, not secrets. Avoid exported JSON keys; attach service accounts to workloads, use short-lived impersonation, and use Workload Identity Federation for AWS/Azure/OIDC workloads. Org policy constraints/iam.disableServiceAccountKeyCreation blocks new keys.
- Conditions: IAM Conditions can check request time, resource name/type, and some resource attributes. They do not natively test source IP; use Access Context Manager access levels with VPC Service Controls or IAP for network-context controls.
Worked example
A CI job running in AWS must read one Cloud Storage bucket. The proposed design creates a service account key and stores it in AWS Secrets Manager. The better design is Workload Identity Federation: create a workload identity pool and AWS provider, map the AWS role to a Google principal, grant roles/storage.objectViewer on that bucket only, and let the job exchange AWS credentials for short-lived Google tokens. No key exists to leak, and the grant is scoped to the bucket.
Traps
Granting Owner at project level to simplify; forgetting that a folder-level grant reaches every project; assuming IAM Conditions can restrict by IP; giving serviceAccountUser at project scope; and diagnosing access without Policy Analyzer or the IAM troubleshooter.