Your enterprise operates dozens of microservices deployed across multiple Google Cloud projects segregated by environment and department. You need to establish a centralized observability strategy with the following requirements: Site Reliability Engineers (SREs) must view aggregated compute metrics and custom dashboards across all production projects from a single interface. Metric-threshold alerting policies must be created centrally and evaluate time-series data across all monitored projects. SREs should be able to configure alerts and dashboards centrally without requiring administrative permissions in the individual monitored projects. Which architecture should you implement to satisfy these requirements?

Designate a dedicated project as the scoping project, add all production projects to its metrics scope, grant SREs Monitoring Editor on the scoping project, and create the cross-project dashboards and alerting policies in that scoping project.: ### What a Scoping Project and Metrics Scope Is A **scoping project** hosts a **metrics scope**, which is a Cloud Monitoring construct that defines the set of monitored Google Cloud projects whose time-series data is visible to the scoping project. By linking multiple monitored projects to a single scoping project, Cloud Monitoring allows engineers to chart, query, and alert on multi-project metrics within a unified console interface. ### How It Meets the Requirements - **Unified Dashboards Across Projects**: Adding the production projects to the central scoping project's metrics scope allows custom dashboards created in the scoping project to query and display metrics from all member projects. - **Centralized Alerting Policies**: Alerting policies created in the scoping project automatically evaluate time-series data across all projects included within its metrics scope. - **Least-Privilege Access Control**: SREs only need the **Monitoring Editor** (`roles/monitoring.editor`) role on the scoping project to build dashboards and define alerting policies. They can view and alert on time-series telemetry across all scoped projects without needing elevated administrative permissions on individual workload projects. ### Key Advantages and Capabilities - **Centralized Management**: Dashboards, uptime checks, synthetic monitors, and alerting policies reside in a single dedicated project repository. - **Multi-Project Querying**: Metric Explorer and dashboard widgets can aggregate time-series data across projects using standard PromQL or Monitoring filters. - **Scalable Quota**: A single metrics scope supports up to 375 monitored projects by default with guaranteed query performance. - **Decoupled Governance**: Separates observability configuration permissions from application deployment permissions. ### Why This Is Optimal This solution uses Google Cloud's native multi-project monitoring model. It centralizes alert configurations and dashboard definitions while respecting IAM boundaries, avoiding the operational overhead of log routing sinks, custom metric pipelines, or duplicate dashboard creation in each project.

Configure Cross Project Metrics Scope Dashboards | Professional Cloud DevOps Engineer

Configure Cross Project Metrics Scope Dashboards

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.

Your enterprise operates dozens of microservices deployed across multiple Google Cloud projects segregated by environment and department. You need to establish a centralized observability strategy with the following requirements:

Site Reliability Engineers (SREs) must view aggregated compute metrics and custom dashboards across all production projects from a single interface.
Metric-threshold alerting policies must be created centrally and evaluate time-series data across all monitored projects.
SREs should be able to configure alerts and dashboards centrally without requiring administrative permissions in the individual monitored projects.

Which architecture should you implement to satisfy these requirements?

Designate a dedicated project as the scoping project, add all production projects to its metrics scope, grant SREs Monitoring Editor on the scoping project, and create the cross-project dashboards and alerting policies in that scoping project.

Use Pub/Sub to export metric descriptors from each project to a central monitoring project, and grant SREs the Monitoring Admin role on the organization resource.

Create identical custom dashboards and metric-threshold alerting policies in each individual production project, and grant SREs Monitoring Editor permissions across every production project.

Configure an aggregated Cloud Logging sink at the organization node routed to a central BigQuery dataset, and build BigQuery SQL-based alerting policies and Looker Studio dashboards for real-time compute metric monitoring.

Professional Cloud DevOps Engineer

Configure Cross Project Metrics Scope Dashboards

Related questions