Task 1.4: Managing and implementing authorization controls.

• AGrant sec-admins the Project Deleter role on the organization

  Incorrect

  Granting a role adds access for sec-admins; it does not take the delete permission away from the teams, whose Owner role still includes it.

• BAdd an IAM condition to each Owner binding that excludes the delete operation

  Incorrect

  Conditions cannot be used when granting the legacy basic roles, Owner included.

• CReplace Owner with a custom role that lacks the delete permission, granted to every team in the organization

  Incorrect

  It would work only after re-granting every team and every future project, and nothing stops someone from granting Owner again.

• DAttach a deny policy for the project delete permission to the organization, with exception principals

  Correct

  Deny policies are checked before allow policies and are inherited by every project below the organization, and exceptionPrincipals leaves the permission to sec-admins.

IAM deny policies attach to the organization, folders or projects and are inherited like allow policies, but they are evaluated first, so a denied permission cannot be regained through any allow grant. Exception principals let named groups keep the permission, which fits a rule such as only one team may delete projects.

• APolicy Troubleshooter

  Incorrect

  Policy Troubleshooter explains whether one principal has one permission on one resource; it does not list everyone with access.

• BPolicy Analyzer for allow policies

  Correct

  Policy Analyzer answers who has what access to which resource, expanding groups and inherited allow policies.

• CPolicy Simulator for allow policies

  Incorrect

  That tool does not report current access or unused permissions.

• DAccess Transparency logs

  Incorrect

  Access Transparency records actions by Google personnel on customer data, not which customer principals can read a bucket.

• ERole recommendations from the IAM recommender

  Correct

  Role recommendations compare granted permissions with the permissions used over the last 90 days and suggest removing or replacing roles.

Policy Intelligence groups several tools. Policy Analyzer finds which principals have access to a resource, following group membership and the resource hierarchy. Role recommendations from the IAM recommender look at 90 days of permission usage to show excess permissions. Troubleshooter and Simulator answer narrower questions about one access check or a planned change.

• AA role binding with an IAM condition that ends two hours after an administrator adds it

  Incorrect

  An expiring binding ends on time, but there is no request, justification or approval step; an administrator must create each one by hand.

• BA Privileged Access Manager entitlement that grants Compute Admin on the production project

  Correct

  Privileged Access Manager grants roles just in time from an entitlement that sets the maximum duration, whether justification and approval are required, and who approves; roles are revoked at the end and the grant is logged.

• CAn Access Context Manager access level that allows the role only from the incident network

  Incorrect

  Access levels restrict where requests come from, not when a role is held or who approved it.

• DA permanent grant of the role to the engineers with Data Access audit logs turned on

  Incorrect

  Logging a standing grant records what happened but leaves the role in place all the time, which the requirement rules out.

Privileged Access Manager is Google Cloud's just-in-time access service. An entitlement defines the roles, the eligible principals, the maximum grant duration and optional justification and approval. Grants expire and are revoked automatically, and requests, approvals and grants are recorded in audit logs.

• AOnce on the folder, with an IAM condition using resource.matchTag on env set to dev

  Correct

  A conditional binding can test the tags a resource has or inherits, so one grant covers every current and future dev project and no prod project.

• BOn each development project separately, added by whoever creates the project

  Incorrect

  Per-project grants depend on every creator remembering them and do not follow the tag.

• COnce on the folder without a condition, plus a label check in the CI pipeline before each deployment

  Incorrect

  The unconditional grant gives developers the role on production too; a pipeline check does not limit IAM.

• DOnce on the folder, with an IAM condition on the project's resource label env equal to dev

  Incorrect

  IAM conditions evaluate secure tags, not resource labels, so a label cannot scope the grant.

Secure tags can be used in IAM conditions: functions such as resource.matchTag and resource.matchTagId check whether a resource has a tag value, directly or inherited. Granting a role once at a folder with such a condition gives access exactly where the tag is applied, including resources created later.

• ARemove allUsers from each bucket's IAM policy and audit the policies every month

  Incorrect

  The public access came from object ACLs, which IAM policies do not show or control.

• BUse signed URLs for all downloads so that object ACLs are no longer needed

  Incorrect

  Signed URLs add another way to share objects; they do not disable ACLs.

• CTurn on uniform bucket-level access and enforce it with the matching constraint

  Correct

  Uniform bucket-level access disables ACLs so only IAM grants access, and the storage.uniformBucketLevelAccess constraint requires it for new buckets.

• DGrant Storage Legacy Bucket Owner to the security team so that it can review ACLs

  Incorrect

  Legacy roles manage ACLs; reviewing them keeps ACLs in use instead of removing them.

Cloud Storage has two parallel access systems, IAM and ACLs, and access is granted if either allows it. Uniform bucket-level access turns ACLs off for a bucket so that IAM is the only system, and an organization policy can require it for buckets created in the organization.

• APolicy Analyzer for allow policies, filtered to the dataset

  Incorrect

  It answers broader access questions but does not explain a denial caused by a deny or boundary policy.

• BPolicy Troubleshooter for that principal, permission and resource

  Correct

  Policy Troubleshooter evaluates the allow, deny and principal access boundary policies that affect one principal's permission on one resource and shows which ones decide it.

• CRole recommendations from the IAM recommender for the group

  Incorrect

  Recommendations suggest removing unused permissions; they do not explain why a permission is missing.

• DCloud Asset Inventory search across all IAM policies in the organization

  Incorrect

  A search lists bindings but does not evaluate deny or boundary policies for a specific access check.

Policy Troubleshooter answers the question of whether a principal has a permission on a resource, and why. It examines allow policies, deny policies and principal access boundary policies together, which makes it the tool for unexpected access denials.

• ADomain restricted sharing on the company's organization, limited to its own customer ID

  Incorrect

  Domain restricted sharing controls who can be granted roles inside the company's organization, not what its users can do elsewhere.

• BAn IAM deny policy on the company's organization for all permissions held by external principals

  Incorrect

  A deny policy on the company's organization protects its own resources; it cannot reach resources in another organization.

• CA VPC Service Controls perimeter that includes only the company's production projects

  Incorrect

  A perimeter guards the projects inside it; access to unprotected and outside projects through other paths is not covered.

• DA principal access boundary policy, bound to the company's principals, that allows only the company's own organization

  Correct

  Principal access boundary policies define which resources principals are eligible to access, so grants in other organizations have no effect for them.

By default, a principal is eligible to access any Google Cloud resource where it is granted a role. A principal access boundary policy, bound to a set of principals, limits the resources they are eligible to access, for example to their own organization, which helps prevent phishing and exfiltration through outside grants.