Examkin

Question

Difficulty: Very hardMonitoring, Logging, and Observability Integration

An enterprise organization operates a hybrid microservices platform deployed across Google Kubernetes Engine (GKE) clusters and Cloud Run services in multiple Google Cloud projects. The Reliability and Governance team needs to implement a unified observability and compliance framework. The solution must achieve the following objectives:
1. Aggregate all audit logs and application error logs across all projects into a centralized dataset in BigQuery for long-term compliance retention and analytical querying, while preventing high-volume trace/debug logs from driving up storage costs.
2. Implement proactive, low-latency incident management that alerts on service reliability degradation based on error budget consumption, rather than firing false positives during short-term metric spikes.

Which TWO architectural actions should the team implement to satisfy these requirements? (Select TWO)

  1. Configure an organization-level aggregated Log Router sink destination targeting a central BigQuery dataset, using a log filter that includes Cloud Audit Logs and application logs with severity levels of WARNING and above.Answer
  2. Configure Cloud Monitoring alerting policies using multi-window burn-rate thresholds evaluated against defined Service Level Objectives (SLOs) rather than static CPU or memory threshold metrics.Answer
  3. C
    Configure an aggregate exclusion filter on the organization logging sink matching resource.type="k8s_container" OR resource.type="cloud_run_revision" to drop all container-generated log entries prior to ingestion.
  4. D
    Grant the primitive Owner role (roles/owner) to the Log Router service account on the destination BigQuery project to grant full dataset write permissions.
  5. E
    Rely strictly on IAM permissions (roles/logging.viewer and roles/bigquery.dataViewer) to ensure that log data in BigQuery cannot be exfiltrated to external Cloud Storage buckets.

Answer

The team should implement an organization-level aggregated Log Router sink targeting a central BigQuery dataset filtered for audit logs and severity levels of WARNING and above, and configure Cloud Monitoring alerting policies using multi-window burn-rate thresholds based on defined SLO error budgets.
Combining an organization-level aggregated sink with explicit log filtering for audit and high-severity logs achieves long-term compliance in BigQuery without unneeded cost overhead. Pairing this with multi-window burn-rate alerting in Cloud Monitoring ensures that incident responses are triggered accurately by real SLO error budget consumption rather than transient metrics.

Step-by-Step Solution

1
Evaluate central audit log and long-term compliance retention requirements
Identify that an organization-level aggregated sink in Cloud Logging can collect logs across all current and future child projects and stream them directly into a centralized BigQuery dataset.
Aggregated sinks provide centralized management and guarantee that all project logs are captured without individual project configuration.
2
Define log filtration criteria for cost and compliance optimization
Filter logs at the sink level to include Cloud Audit Logs and application entries with severity >= WARNING while excluding verbose debug/trace logs.
This prevents overbroad log exclusion while controlling BigQuery ingestion and storage costs.
3
Establish reliability incident alerting strategy
Configure Cloud Monitoring alerting policies using multi-window, multi-burn-rate logic on defined SLOs.
Burn-rate alerting measures consumption of error budgets across fast and slow windows, alerting operators to significant reliability impacts while eliminating false positives from transient spikes.

Key Concept

Centralized Observability Integration & Error Budget Alerting
Rate this question

Topics

Monitoring, Logging, and Observability Integration

More questions from this topic