By default, Cloud Monitoring shows you metrics for a single project at a time. In most real organizations, you have multiple projects - separate ones for different teams, environments, or products - and you want a unified view of what is happening across all of them. Cloud Monitoring handles this through a feature called Metrics Scope.
Metrics Scope is the mechanism that lets a single Cloud Monitoring workspace display metrics from multiple GCP projects. One project acts as the scoping project - this is the project where you do your monitoring work, create dashboards, and configure alerts. The other projects are linked to this scoping project and their metrics become visible within it.
This used to be called a Stackdriver Workspace, and you may see that terminology on older documentation or exam questions. The underlying concept is the same: one project aggregates the monitoring view for several others.
Setting up a Metrics Scope involves a few steps. First, choose the project that will serve as your scoping project. This is typically a dedicated monitoring project, but it can also be an existing project. Open Cloud Monitoring in that project and navigate to the Metrics Scope settings.
From there, you add the other projects you want to include. Each added project contributes its metrics to the scoping project's dashboards and alerting. You can add projects from the same organization or, with the right permissions, from other organizations.
The key permission requirement is that the person doing the configuration needs monitoring access to the projects being linked. Specifically, they need the Monitoring Viewer role or higher on each project being added to the scope.
Once projects are linked into a Metrics Scope, you can build dashboards that combine metrics from all of them. A single chart can show CPU utilization across VMs in three different projects side by side. An alerting policy can fire based on metrics from any project in the scope.
This is useful for platform teams that manage infrastructure across multiple product teams. Instead of logging into each project separately to check on VM health, a single Cloud Monitoring dashboard in the scoping project gives a unified view.
Logs are handled differently. Cloud Monitoring Metrics Scope covers metrics, not logs. If you want a unified log view across projects, that is handled through Log Buckets and log aggregation in Cloud Logging, not through Metrics Scope.
One distinction worth understanding for the Associate Cloud Engineer exam is what the scoping project can and cannot do with the linked projects. Metrics from linked projects are visible in the scoping project's dashboards and alert policies. However, the scoping project does not give you any additional permissions to manage the resources in the linked projects. If you need to SSH into a VM in a linked project, you still need the appropriate IAM roles in that project directly.
This separation is intentional. An operations team can have monitoring visibility across all projects without having deployment or admin rights in every project they monitor.
The slides for the Associate Cloud Engineer exam describe a scenario that comes up in exam questions: multiple departments within a company use different GCP projects but need a unified operational view. A central platform team sets up a monitoring project, links all the department projects, and builds dashboards that show the health of the whole system.
Another common use case is environment visibility. A company might have separate projects for dev, staging, and prod. Linking all three into a Metrics Scope lets the ops team watch the staging and prod environments from a single console and compare metrics across them.
The Associate Cloud Engineer exam presents this concept as a scenario problem. A company has multiple projects and wants their operations team to monitor all of them from one place without logging in separately to each project. The correct answer involves setting up a Metrics Scope in a designated monitoring project and linking the other projects to it.
A common wrong answer in these scenarios is to create a single project and move all resources into it. That is not how multi-project monitoring works and it would break the separation the different teams rely on. The Metrics Scope approach is specifically designed so that you get unified monitoring visibility without having to reorganize the project structure.
Another angle the exam tests is the IAM side: to add a project to a Metrics Scope, you need the Monitoring Editor or Monitoring Admin role on the scoping project, and read access to the projects being added. The exam may present a scenario where someone cannot add a project to a scope and ask you to identify the missing permission.
My Associate Cloud Engineer course covers Metrics Scope alongside the broader Cloud Monitoring section, including how it relates to log aggregation and cross-project IAM configurations.
