GCP Associate Cloud Engineer Practice Question 1: Resource Hierarchy Role Inheritance
Google Cloud Associate Cloud Engineer · Test 1 · question 1 of 10
Your organization has a folder named retail that contains 12 projects, and new projects are added to that folder every month. A group of support engineers, gcp-support@example.com, needs read-only visibility of Compute Engine resources in all of those projects, including projects created in the future, but must not gain visibility into projects in any other folder.
Which action grants exactly that access with the least ongoing administration?
Show answer and explanation
Answer:
IAM policies are inherited down the resource hierarchy: organization → folder → project → resource. A role granted on a folder applies to every project inside that folder, and the inheritance is evaluated at access time, so projects created in the folder later automatically pick up the grant. Granting roles/compute.viewer on the retail folder therefore covers the 12 existing projects and every future one with a single binding, and stops at the folder boundary.
Option A produces the same effective access today, but it requires a new binding every time a project is created; the stem explicitly asks for the least ongoing administration.
Option B grants the role too broadly. A binding at the organization node is inherited by every folder and project in the organization, which violates the requirement that other folders stay invisible to this group.
Option D scopes the grant to the right node but uses the wrong role. The basic roles/viewer role confers read access to nearly every service in the projects (BigQuery datasets, Cloud Storage metadata, Pub/Sub, and more) not just Compute Engine, so it is far wider than requested.