An enterprise security operations team needs to centrally monitor and alert on potential credential-stuffing and unauthorized access attempts across 20 Google Cloud projects. The team has established the following operational requirements: Track the rate of failed access attempts recorded in Google Cloud Audit Logs in real time. Extract metadata such as caller identity and service name into distinct dimensions for granular trend analysis. Visualize trends across all 20 projects from a single centralized custom dashboard in Cloud Monitoring. Trigger automated notification incidents across all monitored projects using a single alerting policy rather than configuring separate policies per project. Which monitoring and alerting architecture should the security engineer implement?

Configure user-defined counter log-based metrics extracting caller metadata from audit logs in each project, establish a multi-project metrics scope in a centralized scoping project, and create a metric-based alerting policy and custom dashboard in the scoping project.: ### What this solution is This architecture combines **user-defined counter log-based metrics** with Cloud Monitoring **metrics scopes** to enable centralized, multi-project security observability and automated threshold alerting over Cloud Audit Logs. ### How it meets all requirements - **Rate of failed access attempts**: User-defined counter log-based metrics count log entries matching specific audit log filter criteria (such as `severity>=ERROR` or specific gRPC/HTTP status codes) as they are ingested by Cloud Logging. - **Granular trend analysis via metadata**: Counter metrics support user-defined labels extracted directly from fields in matching log entries (such as `protoPayload.authenticationInfo.principalEmail` and `protoPayload.serviceName`), allowing Cloud Monitoring to record separate time series for each combination of label values. - **Centralized dashboard and cross-project alerting**: By establishing a **multi-project metrics scope** hosted by a dedicated **scoping project**, all metrics from the 20 monitored projects become visible to the scoping project. Metric-based alerting policies and custom dashboards created in the scoping project operate across all projects within its metrics scope, eliminating the need to duplicate alerting rules across projects. ### Key advantages and capabilities - **Cross-project scalability**: Alerting policies evaluated over metrics scopes dynamically aggregate time series across all attached projects. - **Custom dimensional charting**: Extracted labels allow dashboard widgets to group, break down, and filter by principal, service, or project. - **Standardized incident workflow**: Incidents generated from metric-based alerts integrate directly with notification channels (such as PagerDuty, Slack, Webhooks, or SIEM ingestion pipelines). ### Why this is optimal Metric-based alerting policies built on log-based metrics leverage the full aggregation, grouping, and cross-project scoping capabilities of Cloud Monitoring. In contrast, log-based alerting policies operate only within individual project boundaries and cannot leverage multi-project metrics scopes.

Design Cross Project Log Based Monitoring Alerting | Professional Cloud Security Engineer

Design Cross Project Log Based Monitoring Alerting

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 security operations team needs to centrally monitor and alert on potential credential-stuffing and unauthorized access attempts across 20 Google Cloud projects. The team has established the following operational requirements:

Track the rate of failed access attempts recorded in Google Cloud Audit Logs in real time.
Extract metadata such as caller identity and service name into distinct dimensions for granular trend analysis.
Visualize trends across all 20 projects from a single centralized custom dashboard in Cloud Monitoring.
Trigger automated notification incidents across all monitored projects using a single alerting policy rather than configuring separate policies per project.

Which monitoring and alerting architecture should the security engineer implement?

Configure user-defined counter log-based metrics extracting caller metadata from audit logs in each project, establish a multi-project metrics scope in a centralized scoping project, and create a metric-based alerting policy and custom dashboard in the scoping project.

Deploy the Ops Agent across all project workloads to collect audit logs, enable Cloud Logging exclusion filters to forward security entries, and create a single SQL-based alerting policy in Cloud Monitoring.

Create distribution log-based metrics for audit logs in each project, export metrics to Cloud Monitoring synthetic monitors using Pub/Sub sinks, and deploy predefined integrations dashboards.

Configure direct log-based alerting policies in a central project using an aggregated log sink, and build a Cloud Monitoring custom dashboard configured to track open incidents from those policies.

Professional Cloud Security Engineer

Design Cross Project Log Based Monitoring Alerting

Related questions