An enterprise organization manages microservices across hundreds of projects grouped under environment-specific folders in Google Cloud. The security team needs to configure IAM access according to the principle of least privilege for two distinct teams: Site Reliability Engineering (SRE) Team: Requires aggregated read-only monitoring and application health visibility across all applications hosted under an app-enabled folder. Application Development Teams: Require operational access to view telemetry and operational data strictly within their specific assigned projects, without broader visibility into folder-level application architecture. Which IAM role and resource hierarchy binding strategy should the security engineer implement?

Grant the SRE team Google Group the App Management Viewer role (`roles/apphub.appManagementViewer`) on the app-enabled folder, and grant each development team Google Group the Cloud Hub Operator role (`roles/cloudhub.operator`) on their respective projects.: ### What the Solution Is This solution assigns predefined IAM roles to managed **Google Groups** at appropriate levels of the Google Cloud **resource hierarchy**, pairing the **App Management Viewer** (`roles/apphub.appManagementViewer`) role at the folder level with the **Cloud Hub Operator** (`roles/cloudhub.operator`) role at individual project levels. ### How It Meets the Requirements - **Folder-level application visibility for SREs:** Granting `roles/apphub.appManagementViewer` on an **app-enabled folder** grants Site Reliability Engineers view permissions across all registered applications and components aggregated under that folder. - **Project-scoped visibility for developers:** Granting `roles/cloudhub.operator` on specific target projects ensures developer access is confined strictly to the operational boundaries of their designated project workloads without exposing surrounding folder-level application architectures. - **Scalability and Least Privilege:** Utilizing **Google Groups** for role bindings rather than individual user accounts simplifies group-based access lifecycle management and eliminates privilege sprawl. ### Key Advantages and Capabilities - **Hierarchical Scoping:** Respects resource hierarchy inheritance by applying aggregated operational roles at the folder node and fine-grained operator roles at the project leaf nodes. - **Enforces Least Privilege:** Limits developers from discovering or viewing broader application structures across peer projects. - **Separation of Duties:** Separates high-level multi-application operational oversight from localized project debugging. ### Why This Is Optimal Predefined Cloud Hub and App Hub roles are purpose-built for this exact architectural separation: `roles/apphub.appManagementViewer` provides application-level monitoring across folders, while `roles/cloudhub.operator` provides project-level metric and telemetry viewing.

Iam Role Binding Hierarchy App Hub Cloud Hub | Professional Cloud Security Engineer

Iam Role Binding Hierarchy App Hub Cloud Hub

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise organization manages microservices across hundreds of projects grouped under environment-specific folders in Google Cloud. The security team needs to configure IAM access according to the principle of least privilege for two distinct teams:

Site Reliability Engineering (SRE) Team: Requires aggregated read-only monitoring and application health visibility across all applications hosted under an app-enabled folder.
Application Development Teams: Require operational access to view telemetry and operational data strictly within their specific assigned projects, without broader visibility into folder-level application architecture.

Which IAM role and resource hierarchy binding strategy should the security engineer implement?

Grant the SRE team Google Group the Cloud Hub Operator role (roles/cloudhub.operator) on the app-enabled folder, and grant individual developer accounts the App Management Viewer role (roles/apphub.appManagementViewer) on their respective projects.

Grant the SRE team Google Group the App Management Viewer role (roles/apphub.appManagementViewer) at the organization level, and grant development team Google Groups the Cloud Hub Operator role (roles/cloudhub.operator) on the parent folder.

Grant the SRE team Google Group the Cloud Hub Operator role (roles/cloudhub.operator) at the organization level, and grant development team Google Groups the App Management Viewer role (roles/apphub.appManagementViewer) on the parent folder.

Grant the SRE team Google Group the App Management Viewer role (roles/apphub.appManagementViewer) on the app-enabled folder, and grant each development team Google Group the Cloud Hub Operator role (roles/cloudhub.operator) on their respective projects.

Professional Cloud Security Engineer

Iam Role Binding Hierarchy App Hub Cloud Hub

Related questions