Question

Difficulty: Very hardIdentity and Access Management (IAM) Roles and Resource Hierarchy

A enterprise media streaming platform utilizes a Google Cloud resource hierarchy structured with an Organization node and dedicated subfolders under a main 'Media-Services' folder for separate business units: 'Content-Delivery', 'User-Analytics', and 'Rights-Management'. A centralized security policy mandates two operational requirements:
1. External compliance auditors must be able to view Cloud Asset Inventory metadata and resource configurations across all current and future projects nested within the 'User-Analytics' folder, without granting access to actual workload data or project resource configurations in other folders.
2. Application developers working inside projects within the 'User-Analytics' folder must be able to deploy Compute Engine instances that run under specific workload service accounts, but must not be granted administrative privileges over service account lifecycles or keys.

Which TWO IAM and resource hierarchy configurations should you implement to satisfy these requirements while adhering to Google-recommended best practices for least privilege and operational simplicity? (Select TWO.)

  1. Grant the roles/cloudasset.viewer and roles/browser roles to the external compliance auditors group on the 'User-Analytics' folder level.Answer
  2. Grant the roles/iam.serviceAccountUser role to the developer user group on the specific workload service accounts or target project scope.Answer
  3. C
    Assign the primitive Viewer role (roles/viewer) to the external compliance auditors group at the Organization node level.
  4. D
    Assign the roles/iam.serviceAccountAdmin role to the developer user group at the 'User-Analytics' folder level.

Answer

The correct architecture requires binding roles/cloudasset.viewer and roles/browser at the 'User-Analytics' folder level for auditor visibility, and granting roles/iam.serviceAccountUser to developers at the specific service account or project level.
To satisfy both requirements securely, you must leverage Google Cloud resource hierarchy inheritance and fine-grained roles. Granting asset viewing and browser roles at the folder node allows auditors to inspect resources and inventory metadata across all current and future projects in that folder subtree while maintaining strict isolation from other folders. Granting the Service Account User role to developers provides precisely the permission needed to attach service accounts to Compute Engine workloads without providing administrative control over service account management.

Step-by-Step Solution

1
Evaluate the inheritance requirements for auditing permissions across dynamic sub-projects.
Applying predefined asset viewer and browser roles at the folder node allows permissions to inherit automatically to all child projects within that folder without granting organization-wide access.
IAM roles applied at a folder node propagate down the resource hierarchy to child projects and resources.
2
Determine the least-privileged IAM role required for developers to attach service accounts to Compute Engine instances.
Developers require roles/iam.serviceAccountUser to impersonate or bind a service account to a compute instance.
The Service Account User role provides execution and attachment rights without exposing administrative lifecycle permissions.
3
Eliminate flawed choices involving primitive roles or excessive administrative access.
Primitive Viewer at the organization level provides excessive visibility across unrelated folders, and Service Account Admin provides unnecessary security key and policy control.
Google Cloud security best practices mandate fine-grained predefined roles over primitive roles and minimal scoped rights over administrative roles.

Key Concept

Resource Hierarchy IAM Role Inheritance and Least-Privilege Service Account Delegation
Rate this question