Question

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

A financial analytics company organizes its Google Cloud resources using a dedicated folder named 'Production Payments' containing dozens of project workloads. The security team needs to deploy an automated audit worker on a Compute Engine instance in a separate 'Security Operations' project. This audit worker must inspect Cloud Storage bucket IAM policies and list bucket metadata across all projects in the 'Production Payments' folder, without being allowed to read object contents or modify bucket settings. Additionally, application developers must be able to attach this audit service account to virtual machines in the Security Operations project without being granted administrative access over the service account itself or broad access across the folder. Which configuration strategy satisfies least privilege and operational security requirements?

  1. Create a custom IAM role with storage.buckets.getIamPolicy and storage.buckets.list permissions and bind it to the audit service account at the Production Payments folder level; then grant the roles/iam.serviceAccountUser role on the audit service account resource to the developer group.Answer
  2. B
    Assign the primitive roles/viewer role to the audit service account at the Production Payments folder level, and grant the primitive roles/editor role on the Security Operations project to the developer group.
  3. C
    Create a custom IAM role with storage.buckets.getIamPolicy and storage.buckets.list permissions and bind it to the audit service account at the Production Payments folder level, but grant the roles/iam.serviceAccountAdmin role on the Security Operations project to the developer group.
  4. D
    Assign the predefined roles/storage.objectViewer role to the audit service account at the Organization root node, relying on IAM permissions alone to prevent data exfiltration to external storage buckets.

Answer

Create a custom IAM role containing only the storage.buckets.getIamPolicy and storage.buckets.list permissions bound to the audit service account at the Production Payments folder level, and grant the roles/iam.serviceAccountUser role on the specific service account resource to the developer group.
The correct solution defines a fine-grained custom role containing only the required bucket metadata permissions (storage.buckets.getIamPolicy and storage.buckets.list) and binds it at the folder node level so that child projects inherit access automatically. Furthermore, assigning roles/iam.serviceAccountUser directly on the service account resource allows developers to attach the account to instances while adhering strictly to the principle of least privilege.

Step-by-Step Solution

1
Determine the required permission scope for the audit worker.
The worker requires storage.buckets.getIamPolicy and storage.buckets.list permissions across all projects under the Production Payments folder without object payload access.
Creating a fine-grained custom IAM role with only these permissions ensures least privilege compared to predefined object viewer or primitive roles.
2
Select the appropriate resource hierarchy node for policy binding.
Binding the custom role at the Production Payments folder level allows all current and future child projects to inherit the audit read permissions automatically.
Inheritance down the resource hierarchy reduces operational overhead compared to per-project policy assignments.
3
Configure developer delegation permissions safely.
Granting roles/iam.serviceAccountUser on the audit service account resource to the developer group allows developers to attach the service account to compute workloads without allowing them to modify service account IAM policies or keys.
Resource-level binding of serviceAccountUser follows recommended delegation practices.

Key Concept

Resource Hierarchy Role Inheritance and Service Account Delegation
Rate this question