Task 4.1: Managing IAM.

• AThe Owner role on the project, so the team can manage its own access

  Incorrect

  Owner is broader than Editor and adds IAM management on top, the opposite of least privilege.

• BThe Cloud SQL Admin role on the project, in place of Editor

  Correct

  This predefined role covers managing Cloud SQL instances and nothing outside Cloud SQL, which follows least privilege.

• CThe Viewer role on the project, plus Editor granted for one hour when a change is needed

  Incorrect

  Temporary Editor still opens every other team's resources during the window, and Viewer alone cannot manage instances.

• DThe Cloud SQL Client role on the project, in place of Editor

  Incorrect

  Cloud SQL Client lets principals connect to instances; it does not allow creating or configuring them.

Basic roles span almost every service in a project. Predefined roles are scoped to one service and job, so start there and fall back to a custom role only when no predefined role fits.

• AThe user's session token still carries the old role; force the user to sign out and sign in again

  Incorrect

  Access is evaluated against the effective policy on each request; a new sign-in would still find the folder's binding.

• BIAM changes take up to 24 hours; wait a day and test again before changing anything else

  Incorrect

  Waiting does not help: the access comes from a binding elsewhere, not from a delay.

• CThe folder's binding is inherited; remove the user's binding from the folder's allow policy

  Correct

  A resource's effective policy is the union of its own policy and its ancestors' policies, so the grant must be removed where it was made.

• DThe project's policy must explicitly list the user with no roles to override the folder

  Incorrect

  Allow policies only grant access; a project's allow policy cannot subtract access granted by a parent.

Allow policies are additive down the hierarchy. A binding on a folder applies to every project in it, and no allow policy lower down can take it away; remove it at the level where it was granted.

• ACreate the custom role in one of the production projects and grant it on the folder

  Incorrect

  A project-level custom role can only be granted within the project where it was created, not on a folder.

• BGrant the custom role to each member of the group individually in every production project

  Incorrect

  Per-user, per-project grants are hard to maintain and miss new projects and new members.

• CCreate a custom role at the organization level with the permissions to get, list, start and stop instances

  Correct

  A custom role holds exactly the permissions needed, and only an organization-level custom role can be granted on a folder.

• DGrant the Compute Instance Admin (v1) role to the group on the folder

  Incorrect

  This predefined role can also create, delete and reconfigure instances, which the group must not do.

• EGrant the custom role to the support group on the Production folder

  Correct

  A grant on the folder is inherited by every project in it, now and later.

Custom roles fill the gap when predefined roles are too broad. Define them at the organization when they must be used on folders or across projects, and grant them to groups.

• AWith a calendar reminder for the project owner to remove the binding at the end of the month

  Incorrect

  A reminder relies on someone acting on time, which is what the requirement rules out.

• BWith a deny policy that blocks the auditor's access starting next month

  Incorrect

  This leaves the grant in place plus a second policy to maintain, instead of one binding that ends on its own.

• CWith a custom role that lists only the BigQuery read permissions the auditor needs

  Incorrect

  A narrower role changes what the auditor can do, not for how long the access lasts.

• DWith an IAM condition on the binding that ends access at a timestamp at month's end

  Correct

  Conditional role bindings can compare request.time with a timestamp, so the grant stops working at that moment without anyone removing it.

IAM Conditions let one binding carry its own expiry. Temporary access granted this way does not depend on a cleanup step.

• Agcloud projects set-iam-policy PROJECT_ID policy.json with the --merge flag

  Incorrect

  set-iam-policy writes the whole policy from the file; there is no merge flag, so the same mistake would repeat.

• Bgcloud iam roles create viewer-ana --project=PROJECT_ID --permissions=resourcemanager.projects.get

  Incorrect

  This defines a new custom role but grants it to nobody, and it was not needed for a predefined role.

• Cgcloud projects add-iam-policy-binding PROJECT_ID --member=user:ana@example.com --role=roles/viewer

  Correct

  This adds one binding to the existing policy and leaves every other binding in place.

• Dgcloud projects get-iam-policy PROJECT_ID --flatten=bindings --filter=bindings.members:ana@example.com

  Incorrect

  get-iam-policy only reads the current policy; it does not grant anything.

set-iam-policy replaces the resource's allow policy with the file's contents. For one change, add or remove a single binding instead of writing the whole policy.

• AGrant her Storage Admin on the bucket and check whether the error goes away

  Incorrect

  Granting a broad role to test access hides the cause and leaves her with more access than she needs.

• BPolicy Troubleshooter for her email, the bucket and storage.objects.get

  Correct

  Policy Troubleshooter evaluates the allow and deny policies that apply to a principal, resource and permission, and explains the result.

• CThe IAM role recommendations for the project, filtered to her account

  Incorrect

  These do not evaluate why one specific request was denied.

• DThe Admin Activity audit logs for the bucket over the past week

  Incorrect

  These logs show configuration changes; they do not evaluate whether her identity holds a permission.

When access does not behave as expected, troubleshoot before changing grants. Policy Troubleshooter shows the bindings and policies that decide the outcome for one principal and permission.

• AViewer

  Incorrect

  The basic Viewer role can read most resources in the projects.

• BOrganization Administrator

  Incorrect

  This role manages IAM across the organization.

• CBrowser

  Correct

  Browser gives read access to browse the hierarchy without permission to view resources in the projects.

• DFolder Admin

  Incorrect

  Folder Admin can change folders, which goes well beyond viewing them.

Choose the narrowest role for the need: Browser covers navigation of the hierarchy, not the contents of projects.

• Agcloud iam roles copy --source=auditor --source-organization=ORG_A --destination=auditor --dest-organization=ORG_B

  Correct

  roles copy creates a role from an existing one; the source and destination flags name the role and organization on each side.

• Bgcloud iam roles create auditor --organization=ORG_B --title=Auditor --stage=GA

  Incorrect

  This creates a role in ORG_B that holds only the permissions you pass to it, and none are passed here.

• Cgcloud iam roles undelete auditor --organization=ORG_B --format=yaml

  Incorrect

  undelete restores a custom role that was deleted from ORG_B; auditor was never created there.

• Dgcloud iam roles describe auditor --organization=ORG_A --format=yaml > auditor.yaml

  Incorrect

  describe shows the role's metadata, written here to a file; nothing is created in ORG_B by this command.

gcloud iam roles copy creates a new custom role from an existing role, predefined or custom, so a reviewed set of permissions is reused exactly instead of being retyped.

• AThe role cannot be saved until the permission is removed

  Incorrect

  Including a TESTING permission does not stop the role from being saved.

• BIt may behave unexpectedly; avoid relying on it in production

  Correct

  TESTING permissions can be included, but Google is still checking their compatibility, so they are not recommended for production.

• CNo risk; TESTING means the permission is fully supported

  Incorrect

  Fully supported permissions have the SUPPORTED level.

• DThe permission is applied only on weekends while it is being tested

  Incorrect

  Support levels do not schedule when permissions apply.

Check each permission's custom role support level before building production roles.

• Agcloud projects get-iam-policy PROJECT_ID

  Incorrect

  This shows who has which roles, not what a role contains.

• Bgcloud pubsub topics list

  Incorrect

  This lists topics, not role permissions.

• Cgcloud iam service-accounts list

  Incorrect

  This lists service accounts, not role permissions.

• Dgcloud iam roles describe roles/pubsub.editor

  Correct

  describe shows a role's metadata and its included permissions.

Know what a role grants before granting it; describe it first.

• Agcloud iam roles list --project=billing-prod

  Incorrect

  This lists custom roles defined in the project, not who holds roles.

• Bgcloud projects get-iam-policy billing-prod --format=json

  Correct

  get-iam-policy returns the project's allow policy with its bindings, and the format flag writes JSON.

• Cgcloud organizations get-iam-policy ORGANIZATION_ID --format=json

  Incorrect

  This shows the organization's own bindings, not the ones set directly on the project.

• Dgcloud projects describe billing-prod

  Incorrect

  describe shows project metadata such as ID, number and parent, not role bindings.

Each resource has its own allow policy, and get-iam-policy on that resource returns the bindings set directly on it.