Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
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:
Which architecture should you implement to satisfy these requirements?
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.
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.
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.
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.
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.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.
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.