A security engineer is designing an enterprise-wide audit logging architecture across a Google Cloud Organization. The design must satisfy the following technical and operational requirements: Near real-time streaming of organizational audit logs to an external third-party SIEM. Centralized SQL analysis joining audit logs with enterprise data in BigQuery without destination write errors. Log volume and cost optimization within child projects without impacting mandatory Admin Activity audit logs. Which logging architecture should the engineer implement?

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard, write-enabled BigQuery dataset; and configure exclusion filters on the _Default sinks in projects to exclude high-volume Data Access logs.: What the solution is This solution implements an enterprise-grade log routing architecture using Google Cloud aggregated sinks, supported export destinations (Pub/Sub and BigQuery), and Log Router exclusions to capture critical audit telemetry while controlling storage and ingestion costs. How it meets all requirements Near real-time SIEM ingestion: By creating an aggregated sink at the organization level with a destination set to a Pub/Sub topic, log entries across all folders and projects are collated and published as JSON messages in real time for external SIEM integration (such as Splunk or Datadog). Centralized SQL analytics without write errors: The sink for SQL analysis targets a standard, write-enabled BigQuery dataset. Cloud Logging can stream structured LogEntry records directly into standard BigQuery datasets for complex joins with enterprise data. Cost and volume management: Configuring exclusion filters on the _Default sinks prevents high-volume Data Access logs from being ingested into local project _Default log buckets, eliminating unnecessary ingestion charges. Furthermore, mandatory Admin Activity logs are automatically routed and retained in the _Required bucket and cannot be dropped or excluded. Key advantages and capabilities Centralized governance: Organization-level aggregated sinks eliminate the operational burden of configuring individual sinks in every project. Decoupled consumption: Pub/Sub provides scalable, decoupled buffering for external log consumers and SIEM connectors. Guaranteed audit integrity: Core administrative actions remain permanently captured in the immutable _Required bucket regardless of custom exclusion rules. Cost predictability: Filtering voluminous Data Access logs at the _Default sink level prevents runaway storage and ingestion costs. Why this is optimal This architecture directly addresses the unique capabilities and constraints of Cloud Logging routing destinations. It uses Pub/Sub for real-time third-party streaming, avoids read-only BigQuery destination failures, and leverages built-in exclusion mechanisms to balance compliance visibility with cost governance.

Org Audit Logs to Pub/Sub and BigQuery Without Write Errors

Organization Aggregated Sinks for Audit Logging

A security engineer is designing an enterprise-wide audit logging architecture across a Google Cloud Organization. The design must satisfy the following technical and operational requirements:

Near real-time streaming of organizational audit logs to an external third-party SIEM.
Centralized SQL analysis joining audit logs with enterprise data in BigQuery without destination write errors.
Log volume and cost optimization within child projects without impacting mandatory Admin Activity audit logs.

Which logging architecture should the engineer implement?

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard BigQuery dataset; and disable the _Required log sink in child projects to reduce log ingestion costs.

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard, write-enabled BigQuery dataset; and configure exclusion filters on the _Default sinks in projects to exclude high-volume Data Access logs.

Create project-level sinks routing audit logs to Cloud Storage buckets for near real-time SIEM export; create an aggregated sink routing to a write-enabled BigQuery dataset; and modify the _Required sink to exclude Data Access audit logs.

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a linked BigQuery dataset; and add exclusion filters on the _Default sinks to drop high-volume Data Access logs.

Explanations

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard BigQuery dataset; and disable the _Required log sink in child projects to reduce log ingestion costs.

What the option does

This option sets up Pub/Sub and BigQuery sinks but attempts to reduce ingestion costs by disabling the _Required log sink in child projects.

Why it doesn't meet the requirement

Immutability of _Required sink: Google Cloud mandates that the _Required sink and _Required log bucket cannot be disabled, deleted, modified, or filtered.
Misalignment with cost controls: Ingestion and storage of logs in the _Required bucket (which holds Admin Activity and System Events) are provided at no additional charge by Google Cloud. Attempting to disable the _Required sink is neither possible nor effective for cost reduction.

Key characteristics and limitations

The _Required bucket holds mandatory audit logs that guarantee regulatory traceability for cloud resource administration.
Cost optimization must be achieved through exclusion filters on the _Default sink or custom user-defined sinks where billable logs (such as high-volume Data Access logs) are processed.

This answer would be correct if

The _Required sink were a user-manageable billable resource that supported administrative deactivation.

View source documentation

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard, write-enabled BigQuery dataset; and configure exclusion filters on the _Default sinks in projects to exclude high-volume Data Access logs.

What the solution is

This solution implements an enterprise-grade log routing architecture using Google Cloud aggregated sinks, supported export destinations (Pub/Sub and BigQuery), and Log Router exclusions to capture critical audit telemetry while controlling storage and ingestion costs.

How it meets all requirements

Near real-time SIEM ingestion: By creating an aggregated sink at the organization level with a destination set to a Pub/Sub topic, log entries across all folders and projects are collated and published as JSON messages in real time for external SIEM integration (such as Splunk or Datadog).
Centralized SQL analytics without write errors: The sink for SQL analysis targets a standard, write-enabled BigQuery dataset. Cloud Logging can stream structured LogEntry records directly into standard BigQuery datasets for complex joins with enterprise data.
Cost and volume management: Configuring exclusion filters on the _Default sinks prevents high-volume Data Access logs from being ingested into local project _Default log buckets, eliminating unnecessary ingestion charges. Furthermore, mandatory Admin Activity logs are automatically routed and retained in the _Required bucket and cannot be dropped or excluded.

Key advantages and capabilities

Centralized governance: Organization-level aggregated sinks eliminate the operational burden of configuring individual sinks in every project.
Decoupled consumption: Pub/Sub provides scalable, decoupled buffering for external log consumers and SIEM connectors.
Guaranteed audit integrity: Core administrative actions remain permanently captured in the immutable _Required bucket regardless of custom exclusion rules.
Cost predictability: Filtering voluminous Data Access logs at the _Default sink level prevents runaway storage and ingestion costs.

Why this is optimal

This architecture directly addresses the unique capabilities and constraints of Cloud Logging routing destinations. It uses Pub/Sub for real-time third-party streaming, avoids read-only BigQuery destination failures, and leverages built-in exclusion mechanisms to balance compliance visibility with cost governance.

View source documentation

Create project-level sinks routing audit logs to Cloud Storage buckets for near real-time SIEM export; create an aggregated sink routing to a write-enabled BigQuery dataset; and modify the _Required sink to exclude Data Access audit logs.

What the option does

This option uses project-level Cloud Storage exports to feed an external SIEM and attempts to modify the _Required sink to reduce log volume.

Why it doesn't meet the requirement

No real-time delivery: Cloud Storage export sinks process log entries in hourly batches, which introduces delays of 2 to 3 hours before log files appear. This fails the requirement for near real-time streaming to the SIEM.
Invalid sink modification: The _Required sink is a built-in, immutable Cloud Logging system sink. It cannot be disabled, deleted, or modified with exclusion filters.
Data Access logs in _Required: _Required buckets hold Admin Activity, System Event, and Access Transparency logs, not Data Access logs.

Key characteristics and limitations

Cloud Storage sinks write logs as JSON batch files hourly, making them suitable for long-term archiving rather than low-latency SIEM ingestion.
The _Required sink and its bucket are protected against modifications and custom exclusions to ensure an unbroken administrative audit trail.

This answer would be correct if

The requirement was to configure a low-cost, batch-oriented disaster recovery archive in Cloud Storage without near real-time streaming constraints.

View source documentation

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a linked BigQuery dataset; and add exclusion filters on the _Default sinks to drop high-volume Data Access logs.

What the option does

This option attempts to route organizational log entries directly into a linked BigQuery dataset while streaming logs to Pub/Sub and excluding Data Access logs from the _Default sink.

Why it doesn't meet the requirement

Destination write failure: A linked BigQuery dataset is a read-only view backed by a Cloud Logging log bucket enabled with Log Analytics. Setting the destination of a log sink to a linked BigQuery dataset is invalid and fails because the target dataset is read-only and cannot accept direct write streams from the Log Router.
Direct BigQuery log export sinks require a standard, write-enabled BigQuery dataset to receive and persist streaming log data.

Key characteristics and limitations

Linked datasets allow BigQuery to read from Log Analytics buckets, but they do not serve as standalone write targets for sinks.
Sinks require full write permissions to dataset endpoints.

This answer would be correct if

The scenario called for querying logs stored inside a Log Analytics-enabled bucket directly via BigQuery SQL queries without setting up a direct Log Router sink to BigQuery.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Organization Aggregated Sinks for Audit Logging

A security engineer is designing an enterprise-wide audit logging architecture across a Google Cloud Organization. The design must satisfy the following technical and operational requirements:

Near real-time streaming of organizational audit logs to an external third-party SIEM.
Centralized SQL analysis joining audit logs with enterprise data in BigQuery without destination write errors.
Log volume and cost optimization within child projects without impacting mandatory Admin Activity audit logs.

Which logging architecture should the engineer implement?

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard, write-enabled BigQuery dataset; and configure exclusion filters on the _Default sinks in projects to exclude high-volume Data Access logs.

Explanations

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard BigQuery dataset; and disable the _Required log sink in child projects to reduce log ingestion costs.

What the option does

This option sets up Pub/Sub and BigQuery sinks but attempts to reduce ingestion costs by disabling the _Required log sink in child projects.

Why it doesn't meet the requirement

Immutability of _Required sink: Google Cloud mandates that the _Required sink and _Required log bucket cannot be disabled, deleted, modified, or filtered.
Misalignment with cost controls: Ingestion and storage of logs in the _Required bucket (which holds Admin Activity and System Events) are provided at no additional charge by Google Cloud. Attempting to disable the _Required sink is neither possible nor effective for cost reduction.

Key characteristics and limitations

The _Required bucket holds mandatory audit logs that guarantee regulatory traceability for cloud resource administration.
Cost optimization must be achieved through exclusion filters on the _Default sink or custom user-defined sinks where billable logs (such as high-volume Data Access logs) are processed.

This answer would be correct if

The _Required sink were a user-manageable billable resource that supported administrative deactivation.

View source documentation

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard, write-enabled BigQuery dataset; and configure exclusion filters on the _Default sinks in projects to exclude high-volume Data Access logs.

What the solution is

How it meets all requirements

Near real-time SIEM ingestion: By creating an aggregated sink at the organization level with a destination set to a Pub/Sub topic, log entries across all folders and projects are collated and published as JSON messages in real time for external SIEM integration (such as Splunk or Datadog).
Centralized SQL analytics without write errors: The sink for SQL analysis targets a standard, write-enabled BigQuery dataset. Cloud Logging can stream structured LogEntry records directly into standard BigQuery datasets for complex joins with enterprise data.
Cost and volume management: Configuring exclusion filters on the _Default sinks prevents high-volume Data Access logs from being ingested into local project _Default log buckets, eliminating unnecessary ingestion charges. Furthermore, mandatory Admin Activity logs are automatically routed and retained in the _Required bucket and cannot be dropped or excluded.

Key advantages and capabilities

Centralized governance: Organization-level aggregated sinks eliminate the operational burden of configuring individual sinks in every project.
Decoupled consumption: Pub/Sub provides scalable, decoupled buffering for external log consumers and SIEM connectors.
Guaranteed audit integrity: Core administrative actions remain permanently captured in the immutable _Required bucket regardless of custom exclusion rules.
Cost predictability: Filtering voluminous Data Access logs at the _Default sink level prevents runaway storage and ingestion costs.

Why this is optimal

View source documentation

Create project-level sinks routing audit logs to Cloud Storage buckets for near real-time SIEM export; create an aggregated sink routing to a write-enabled BigQuery dataset; and modify the _Required sink to exclude Data Access audit logs.

What the option does

This option uses project-level Cloud Storage exports to feed an external SIEM and attempts to modify the _Required sink to reduce log volume.

Why it doesn't meet the requirement

No real-time delivery: Cloud Storage export sinks process log entries in hourly batches, which introduces delays of 2 to 3 hours before log files appear. This fails the requirement for near real-time streaming to the SIEM.
Invalid sink modification: The _Required sink is a built-in, immutable Cloud Logging system sink. It cannot be disabled, deleted, or modified with exclusion filters.
Data Access logs in _Required: _Required buckets hold Admin Activity, System Event, and Access Transparency logs, not Data Access logs.

Key characteristics and limitations

Cloud Storage sinks write logs as JSON batch files hourly, making them suitable for long-term archiving rather than low-latency SIEM ingestion.
The _Required sink and its bucket are protected against modifications and custom exclusions to ensure an unbroken administrative audit trail.

This answer would be correct if

The requirement was to configure a low-cost, batch-oriented disaster recovery archive in Cloud Storage without near real-time streaming constraints.

View source documentation

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a linked BigQuery dataset; and add exclusion filters on the _Default sinks to drop high-volume Data Access logs.

What the option does

This option attempts to route organizational log entries directly into a linked BigQuery dataset while streaming logs to Pub/Sub and excluding Data Access logs from the _Default sink.

Why it doesn't meet the requirement

Destination write failure: A linked BigQuery dataset is a read-only view backed by a Cloud Logging log bucket enabled with Log Analytics. Setting the destination of a log sink to a linked BigQuery dataset is invalid and fails because the target dataset is read-only and cannot accept direct write streams from the Log Router.
Direct BigQuery log export sinks require a standard, write-enabled BigQuery dataset to receive and persist streaming log data.

Key characteristics and limitations

Linked datasets allow BigQuery to read from Log Analytics buckets, but they do not serve as standalone write targets for sinks.
Sinks require full write permissions to dataset endpoints.

This answer would be correct if

The scenario called for querying logs stored inside a Log Analytics-enabled bucket directly via BigQuery SQL queries without setting up a direct Log Router sink to BigQuery.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Organization Aggregated Sinks for Audit Logging

Explanations

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard BigQuery dataset; and disable the _Required log sink in child projects to reduce log ingestion costs.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

What the solution is

How it meets all requirements

Key advantages and capabilities

Why this is optimal

Create project-level sinks routing audit logs to Cloud Storage buckets for near real-time SIEM export; create an aggregated sink routing to a write-enabled BigQuery dataset; and modify the _Required sink to exclude Data Access audit logs.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a linked BigQuery dataset; and add exclusion filters on the _Default sinks to drop high-volume Data Access logs.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Log-Based Metrics with Multi-Project Metrics Scopes

serviceAccountDelegationInfo Chain Ordering

GKE Egress Gateway with Cloud Service Mesh

Cloud Logging Field-Level Access Control

Privileged Access Manager JIT Entitlements

BigQuery Multi-Project Architecture

Organization Aggregated Sinks for Audit Logging

Explanations

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a standard BigQuery dataset; and disable the _Required log sink in child projects to reduce log ingestion costs.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

What the solution is

How it meets all requirements

Key advantages and capabilities

Why this is optimal

Create project-level sinks routing audit logs to Cloud Storage buckets for near real-time SIEM export; create an aggregated sink routing to a write-enabled BigQuery dataset; and modify the _Required sink to exclude Data Access audit logs.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Create an organization-level aggregated sink routing audit logs to a Pub/Sub topic for SIEM ingestion; create an organization-level aggregated sink routing audit logs to a linked BigQuery dataset; and add exclusion filters on the _Default sinks to drop high-volume Data Access logs.

What the option does

Why it doesn't meet the requirement

Key characteristics and limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Log-Based Metrics with Multi-Project Metrics Scopes

serviceAccountDelegationInfo Chain Ordering

GKE Egress Gateway with Cloud Service Mesh

Cloud Logging Field-Level Access Control

Privileged Access Manager JIT Entitlements

BigQuery Multi-Project Architecture