Examkin

Question

Difficulty: Very hardManaging IAM Roles and Resource Access Permissions

Your organization needs to grant an external audit team read-only access to inspect IAM policy bindings across all Google Cloud projects contained within a specific Folder named 'Finance-Workloads'. To strictly enforce the principle of least privilege, you must avoid primitive roles or overly permissive predefined roles by defining a custom IAM role with only the `resourcemanager.projects.getIamPolicy` permission at the folder level and assigning it to the auditors' Google Group via the `gcloud` CLI. In what exact order should you execute the configuration and command-line steps to implement this security control?

  1. 1Create a local YAML configuration file (`iam-auditor-role.yaml`) specifying the role metadata, title, stage, and the explicit permission `resourcemanager.projects.getIamPolicy`.
  2. 2Run `gcloud iam roles create customIamPolicyAuditor --folder=FOLDER_ID --config-file=iam-auditor-role.yaml` to instantiate the role in the resource hierarchy.
  3. 3Run `gcloud resource-manager folders add-iam-policy-binding FOLDER_ID --member='group:[email protected]' --role='folders/FOLDER_ID/roles/customIamPolicyAuditor'` to grant access.
  4. 4Execute `gcloud asset analyze-iam-policy --folder=FOLDER_ID --permissions='resourcemanager.projects.getIamPolicy'` to verify inherited permissions across child projects.

Answer

The correct order of operations is: first, author the custom IAM role YAML configuration file locally; second, execute the gcloud role creation command targeting the folder scope; third, attach the newly created folder-scoped role to the auditors' Google Group at the folder level; fourth, validate the effective policy inheritance down to all child projects.
The sequence follows Google Cloud IAM best practices: first defining the custom role manifest locally, instantiating the role at the folder scope via gcloud, binding the instantiated role to the group principal at the folder scope to leverage resource hierarchy inheritance, and finally analyzing effective policy inheritance.

Step-by-Step Solution

1
Define the custom role specification file locally
A valid YAML configuration file containing the `resourcemanager.projects.getIamPolicy` permission is generated.
The gcloud CLI requires a structured definition file when creating custom IAM roles containing discrete permission arrays.
2
Create the custom IAM role at the folder hierarchy node
The custom IAM role resource `folders/FOLDER_ID/roles/customIamPolicyAuditor` is created.
Roles must exist at a specific parent scope (Organization or Folder) before they can be referenced in policy bindings.
3
Add an IAM policy binding on the target folder
The auditor group is granted the folder-scoped custom IAM role.
Binding the role at the folder node allows permissions to automatically inherit down to all contained Cloud projects.
4
Analyze and verify inherited policy permissions
Confirmed effective permissions for auditors across all child project resources without over-granting access.
Verification ensures that least-privilege compliance is achieved and that policy inheritance functions as intended.

Key Concept

Custom IAM Role Creation and Folder-Level Resource Hierarchy Inheritance
Estimated Time:2m 30s
Rate this question

Topics

Managing IAM Roles and Resource Access Permissions

More questions from this topic