Examkin

Soru

Zorluk: OrtaMonitoring, Logging, and Observability Integration

A healthcare company hosts microservices across multiple Google Cloud projects under an organization resource. The operations team requires a centralized observability solution that achieves two main goals:
1. Operational metrics from all workload projects must be visible in a single dashboard without granting engineers administrative or broad resource access to workload projects.
2. Audit logs and critical error logs across all projects must be forwarded automatically to a central security project in real time for ingestion, while keeping lower-severity debug logs localized to their source project.

Which TWO architectural steps should you take to satisfy these requirements according to Google Cloud best practices?

  1. Configure an aggregated Log Router sink at the Google Cloud Organization level with an inclusion filter for audit logs and error severities, targeting a Pub/Sub topic in the central security project.Cevap
  2. Create a Cloud Monitoring Metrics Scope in a central scoping project and add the workload projects as monitored projects.Cevap
  3. C
    Apply a global Cloud Logging exclusion filter matching `severity < ERROR` on the `_Default` sink across all workload projects to reduce ingestion costs.
  4. D
    Assign the primitive Owner role (`roles/owner`) on all workload projects to the central logging service account to grant multi-project observability access.
  5. E
    Rely exclusively on Cloud IAM policy bindings on log storage buckets without configuring VPC Service Controls perimeters for cross-project log transfers.

Cevap

The correct architecture requires creating an aggregated Log Router sink at the organization level to forward selected audit and high-severity logs, and configuring a Cloud Monitoring Metrics Scope in a central project to aggregate metric monitoring across projects.
Establishing an aggregated Log Router sink at the organization level automatically routes specified security audit and high-severity log streams into a central Pub/Sub topic across all projects under the organization resource. Combining this with a Cloud Monitoring Metrics Scope allows operators to view telemetry from multiple projects within a single monitoring workspace without granting elevated IAM roles on workload projects.

Adım Adım Çözüm

1
Configure centralized logging aggregation
An organization-level aggregated Log Router sink uses an inclusion filter to capture relevant security audit logs and high-severity error logs across all child projects and send them to a Pub/Sub topic or BigQuery dataset in the security project.
Aggregated sinks eliminate manual per-project configuration and guarantee compliant centralized logging.
2
Set up multi-project metric visibility
A central Monitoring scoping project is created, and all application workload projects are registered as monitored projects within its Metrics Scope.
This grants operators single-pane visibility over performance metrics across multiple projects without granting wide project-level IAM roles.

Anahtar Kavram

Multi-Project Observability with Aggregated Sinks and Cloud Monitoring Metrics Scopes
Bu soruyu puanla

Konular

Monitoring, Logging, and Observability Integration

Bu konudan daha fazla soru