Examkin

Question

Difficulty: Very hardManaging IAM Roles and Resource Access Permissions

Your organization manages dozens of Google Cloud projects grouped under a single Folder named 'Workloads'. An operations team requires automated capabilities to start, stop, and reset Compute Engine virtual machine instances across all current and future projects within this Folder. According to compliance policies, members of this team must not be permitted to create new instances, modify VM disk configurations, or read object data stored in Cloud Storage buckets in any of these projects. Which strategy should you implement to grant the necessary permissions while adhering to Google Cloud best practices for resource access management?

  1. Define a custom IAM role containing compute.instances.start, compute.instances.stop, and compute.instances.reset permissions at the Folder level, and bind this custom role to the operations team group on the 'Workloads' Folder.Answer
  2. B
    Grant the primitive Editor role (roles/editor) to the operations team group on the 'Workloads' Folder to ensure all compute management operations inherit properly to child projects.
  3. C
    Grant the predefined Compute Admin role (roles/compute.admin) to the operations team at the Organization level, and configure an explicit IAM Deny policy on the 'Workloads' Folder to override instance creation rights.
  4. D
    Grant the Billing Account Administrator role (roles/billing.admin) on the parent billing account linked to the projects, as billing administrators inherit full administrative lifecycle control over compute resources.

Answer

Define a custom IAM role with only compute.instances.start, compute.instances.stop, and compute.instances.reset permissions at the Folder level, and bind it to the operations team on the 'Workloads' Folder.
The solution that defines a custom IAM role containing only instance start, stop, and reset permissions at the Folder level correctly enforces the principle of least privilege. Because IAM permissions in Google Cloud inherit downward through the resource hierarchy (Organization → Folder → Project → Resource), binding this role at the Folder level ensures all current and future child projects within the 'Workloads' folder inherit the policy without granting permissions to projects outside that folder or allowing actions beyond instance lifecycle state management.

Step-by-Step Solution

1
Identify the minimum required permissions
The operations team only needs compute.instances.start, compute.instances.stop, and compute.instances.reset.
Predefined roles like Compute Admin grant excess permissions (creating instances, modifying disks, deleting instances) that violate compliance requirements.
2
Determine the optimal role type
Create a custom IAM role tailored specifically to the required instance lifecycle permissions.
Primitive roles (Viewer, Editor, Owner) and standard broad predefined roles exceed least privilege.
3
Determine the resource hierarchy binding level
Bind the custom IAM role at the Folder level ('Workloads').
Permissions bound at the Folder level automatically inherit down to all existing and future child projects in that folder without requiring per-project configuration or Organization-wide scope.

Key Concept

Principle of Least Privilege and IAM Resource Hierarchy Inheritance
Rate this question

Topics

Managing IAM Roles and Resource Access Permissions

More questions from this topic