Configuring access and security practice questions

Cloud IAM offers basic roles (Owner, Editor, Viewer), predefined roles maintained by Google per service, and custom roles you assemble yourself. Predefined roles are the recommended default because they scope permissions to one service and one job function.

roles/compute.instanceAdmin.v1 contains the permissions to create, modify, start, and stop VM instances and their disks, but includes no Cloud Storage, BigQuery, or IAM-administration permissions. It exactly matches 'manage VMs, nothing else'. Editor and Owner are project-wide basic roles that sweep in every other service (Owner even adds IAM control), and compute.viewer cannot change instance state at all.

1. List the actions the principal actually needs: start, stop, and reconfigure VM instances.
2. Search the predefined roles for the Compute Engine role whose permission set matches that job — roles/compute.instanceAdmin.v1.
3. Confirm the role does not include permissions on the services that must stay off-limits.
4. Grant it at the project level with add-iam-policy-binding, and revisit if the scope of the job changes.

Exam tip: Prefer service-specific predefined roles over basic Owner/Editor — they are how least privilege is done on GCP.

IAM policy inheritance flows down the resource hierarchy (organization → folder → project → resource). The effective policy on a resource is the union of the policy set on it and the policies of all its ancestors, and allow policies are strictly additive.

Because effective access is a union, no setting at the project level can subtract a permission granted at the folder level. The only real remedies are to narrow the folder-level grant (for example, grant the contractor per-project roles instead) or to move analytics-prod out of that folder. The distractors all describe subtractive mechanisms that the additive allow-only model does not provide at a lower level.

1. Locate where the grant actually lives — run get-iam-policy on the folder, not just the project.
2. Recognize that inherited grants cannot be revoked further down the hierarchy.
3. Remove or narrow the binding at the folder level, replacing it with project-level grants on only the intended projects.
4. Alternatively, restructure: move the sensitive project to a folder where the contractor has no inherited role.

Exam tip: Effective IAM policy is the union of the resource's and ancestors' policies — you cannot revoke inherited access at a child.

In Cloud IAM, a principal's effective permissions on a resource are the union of every role binding that applies — bindings on the resource itself and bindings inherited from every ancestor in the hierarchy.

The org-level roles/viewer is inherited by every project in the organization, including vm-lab, granting broad read access. The project-level roles/compute.instanceAdmin.v1 adds instance-management permissions. Neither grant caps or overrides the other; the user can both read everything and administer VMs. Options claiming precedence, override, or conflict all misstate the additive model.

1. Enumerate all bindings that mention the principal: on the resource, its project, folder(s), and organization.
2. Take the union of the permissions in every role from those bindings.
3. Apply that combined permission set as the user's effective access on the resource.
4. When auditing, always check ancestor policies too — project-level get-iam-policy alone understates real access.

Exam tip: IAM grants merge — a principal's effective access is the union of every role bound at every level above and at the resource.

Custom roles let you assemble an exact permission list when no predefined role fits. Their defining scope matters: an org-level custom role can be granted anywhere in the organization, while a project-level custom role exists only within that project.

Google Cloud supports custom roles at exactly two scopes — organization and project. Since the requirement is one definition reusable company-wide, it should be created at the organization level. The common trap is assuming folders, which participate fully in policy inheritance, can also hold custom role definitions; they cannot.

1. Decide the reuse scope: company-wide reuse means the role must be created at the organization level.
2. Create it with gcloud iam roles create --organization=ORG_ID with a permissions list or YAML file.
3. Grant the custom role like any other role in bindings on projects or resources under the org.
4. Remember custom roles are not maintained by Google — review their permission lists when services evolve.

Exam tip: Custom roles can be created at the organization or project level only — never on a folder.

Custom roles carry a launch stage (ALPHA, BETA, GA, DEPRECATED, DISABLED) that documents where the role is in its lifecycle. The stage is informational metadata for administrators, except DISABLED, which actually stops the role from granting permissions.

A role in active trial by a pilot team maps to BETA: broader than initial ALPHA experimentation, but not yet stable enough to declare GA. GA would overstate stability, DEPRECATED signals end-of-life, and DISABLED would break the pilot by nullifying the role's permissions in existing bindings.

1. Create the custom role with --stage=ALPHA (or BETA) while the definition is still in flux.
2. Move it to BETA while a pilot group validates it, updating the permission list as feedback arrives.
3. Promote to GA with gcloud iam roles update --stage=GA once the definition is stable for production.
4. Use DEPRECATED when phasing it out, and DISABLED to switch off its permissions entirely.

Exam tip: Launch stages document a custom role's maturity — ALPHA/BETA while testing, GA when stable, and DISABLED actually turns it off.

IAM Conditions add a boolean CEL expression to a role binding; the binding grants access only while the expression evaluates true. Time-based expiry (request.time) and resource-attribute restrictions are the classic uses.

A conditional binding such as expression: request.time < timestamp("2026-12-31T00:00:00Z") causes the dataViewer grant to stop working the moment the deadline passes, with no human action required. The alternatives either depend on manual follow-through, misplace expiry into a role definition where it does not exist, or broaden the grant while still needing manual revocation.

1. Grant the role with add-iam-policy-binding, adding a --condition with title, description, and a CEL expression on request.time.
2. Set the expression to compare request.time against the contract end timestamp.
3. Verify the conditional binding appears in get-iam-policy output with its condition block.
4. After the timestamp passes, the binding no longer grants access; remove the stale binding during routine policy hygiene.

Exam tip: Use IAM Conditions with a request.time expression to make role grants expire automatically.