A financial enterprise is designing a centralized log routing architecture to stream security telemetry across hundreds of Google Cloud projects to an external Security Information and Event Management (SIEM) system. The security engineering team has defined the following requirements: Automatically aggregate Admin Activity audit logs, System Event logs, VPC Flow Logs, and Data Access audit logs across all existing and future folders and projects in the Google Cloud organization. Filter out high-volume, low-fidelity Data Access audit events (specifically Cloud Storage object get and list operations) and routine maintenance events before exporting them to reduce external SIEM ingestion costs. Maintain centralized administration without requiring per-project log router sink management. Which architecture should the team implement to meet these requirements?

Create an aggregated log sink at the organization level with the includeChildren parameter enabled, configure an inclusion filter for the required log IDs, and define exclusion filters for the routine Cloud Storage operations and maintenance events.: What Aggregated Log Sinks and Filter Rules Are An aggregated log sink configured at the Google Cloud organization level combines and routes log entries from the organization and all its child folders, billing accounts, and projects. By utilizing the includeChildren parameter alongside Logging query language inclusion and exclusion filters, security teams can centrally govern telemetry pipelines, ensuring comprehensive visibility while controlling downstream data volumes and costs. How It Meets the Requirements Organization-wide aggregation across all projects: Setting the log sink at the organization root with includeChildren = true (or --include-children via gcloud) ensures that log telemetry from all existing and dynamically provisioned child folders and projects is routed automatically without per-project configuration. Selectively routing high-fidelity security telemetry: The sink's inclusion filter explicitly targets desired log IDs, including cloudaudit.googleapis.com/activity, cloudaudit.googleapis.com/system_event, compute.googleapis.com/vpc_flows, and cloudaudit.googleapis.com/data_access. Filtering out high-volume and routine events: Configuring exclusion filters on the sink (such as matching protoPayload.methodName =~ "^storage\.(buckets|objects)\.(get|list)$" and LOG_ID("maintenance.googleapis.com/maintenance_events")) discards low-fidelity entries immediately after ingestion, preventing costly streaming to the destination SIEM. Centralized administration: Managing a single aggregated sink at the organization level eliminates configuration drift and administrative overhead across individual project log routers. Key Advantages and Capabilities Dynamic discovery: Automatically captures logs from new projects as soon as they are created under the resource hierarchy. Deterministic evaluation order: Cloud Logging first validates the inclusion filter; if a log matches the inclusion criteria and does not match any exclusion rule, it is forwarded to the designated export destination. Granular exclusion limits: Supports up to 50 exclusion filters per sink, with query lengths up to 20,000 characters, allowing fine-grained tuning of noisy APIs. Direct SIEM integration: Routes filtered streams directly to external endpoints, Pub/Sub topics, or Cloud Storage buckets for downstream ingestion. Why This Is Optimal This solution provides unified security governance and least-privilege administrative boundaries. It prevents operational silos, guarantees that developers cannot bypass or disable audit logging at the project level, and optimizes external SIEM ingestion costs by discarding non-actionable read/list telemetry before egress.

Organization Aggregated Log Sink with includeChildren Filters

Centralized SIEM Export with Organization Log Sinks

A financial enterprise is designing a centralized log routing architecture to stream security telemetry across hundreds of Google Cloud projects to an external Security Information and Event Management (SIEM) system.

The security engineering team has defined the following requirements:

Automatically aggregate Admin Activity audit logs, System Event logs, VPC Flow Logs, and Data Access audit logs across all existing and future folders and projects in the Google Cloud organization.
Filter out high-volume, low-fidelity Data Access audit events (specifically Cloud Storage object get and list operations) and routine maintenance events before exporting them to reduce external SIEM ingestion costs.
Maintain centralized administration without requiring per-project log router sink management.

Which architecture should the team implement to meet these requirements?

Create an aggregated log sink at the organization level with the includeChildren parameter disabled, and modify the organization-level _Required sink to forward child project logs to the destination SIEM.

Create an aggregated log sink at the organization level with an empty inclusion filter, and revoke Data Access IAM permissions from service accounts to prevent noisy logs from being generated.

Create an aggregated log sink at the organization level with the includeChildren parameter enabled, configure an inclusion filter for the required log IDs, and define exclusion filters for the routine Cloud Storage operations and maintenance events.

Deploy individual project-level sinks across all existing projects routing to the external SIEM, and modify the _Required and _Default sinks in each project to add the exclusion filters.

Explanations

Create an aggregated log sink at the organization level with the includeChildren parameter disabled, and modify the organization-level _Required sink to forward child project logs to the destination SIEM.

What the Organization _Required Sink and Non-Aggregated Sinks Are

The _Required sink is a system-created log sink present in every Google Cloud resource level (organization, folder, and project) that routes a core subset of audit logs (such as Admin Activity and System Events) to the local _Required log bucket for compliance retention. Organization-level sinks without includeChildren only process events originating directly at the organization node.

Why It Doesn't Meet the Requirement

Inability to capture child resources: When includeChildren is disabled, the organization sink ignores logs originating within child folders and projects, failing the multi-project aggregation requirement.
Immutability of system sinks: The _Required sink is immutable and system-managed. Administrators cannot edit its inclusion filter, attach exclusion filters, alter its destination, or modify it to forward logs to external SIEM tools or destinations.
Scope limitation of system sinks: The _Required sink only processes logs that originate within the specific resource where it resides and does not aggregate logs across the resource hierarchy.

Key Characteristics and Limitations

System-created _Required sinks cannot be disabled, modified, or deleted by any IAM principal.
System-created sinks retain logs strictly within local Google-managed _Required log buckets for 400 days at no charge.
An aggregated sink must explicitly enable child inheritance (includeChildren) to collect telemetry across descending hierarchy nodes.

This Answer Would Be Correct If

The organization only required local Google Cloud storage of root-level administrative actions within the native _Required bucket and did not need to route multi-project logs to an external SIEM.

Additional Context

Attempting to route logs to an external SIEM by reconfiguring the _Required sink is a common architectural misconception; exporting logs to external endpoints always requires user-configured custom sinks.

View source documentation

Create an aggregated log sink at the organization level with an empty inclusion filter, and revoke Data Access IAM permissions from service accounts to prevent noisy logs from being generated.

What IAM Permission Revocation and Empty Inclusion Filters Do

An empty inclusion filter in a log sink matches and routes every log entry ingested by the Cloud Logging API. Restricting IAM permissions on service accounts limits their authorization to execute API operations against Google Cloud resources such as Cloud Storage and Cloud Spanner.

Why It Doesn't Meet the Requirement

Breaks operational application workloads: Revoking service account permissions to stop Data Access log generation disables normal application read and list operations, causing application outages rather than filtering log telemetry.
Excessive log routing volume: Leaving the inclusion filter completely empty without specific criteria causes all log types across the entire organization (including debug logs, build logs, and high-frequency system logs) to be routed, drastically inflating export volumes.
Fails log filtering best practices: Log noise reduction must be handled through sink exclusion filters or IAM audit log exemption configurations, not by removing legitimate application IAM roles.

Key Characteristics and Limitations

If a sink does not specify an inclusion filter, every single log entry received by Cloud Logging matches the sink.
Revoking IAM permissions modifies access authorization rather than log collection policies.
Routine Data Access logs generated by authorized application workflows should be filtered using Logging query expressions (e.g., regex pattern matching on protoPayload.methodName).

This Answer Would Be Correct If

The security team intended to capture absolutely all log types without exception and decommission service accounts that were identified as completely redundant or compromised.

Additional Context

To manage Data Access audit log volume without breaking application access, administrators should either use audit log configuration exemptions in IAM policies or define precise regex exclusion filters in the Log Router sink.

View source documentation

Create an aggregated log sink at the organization level with the includeChildren parameter enabled, configure an inclusion filter for the required log IDs, and define exclusion filters for the routine Cloud Storage operations and maintenance events.

What Aggregated Log Sinks and Filter Rules Are

An aggregated log sink configured at the Google Cloud organization level combines and routes log entries from the organization and all its child folders, billing accounts, and projects. By utilizing the includeChildren parameter alongside Logging query language inclusion and exclusion filters, security teams can centrally govern telemetry pipelines, ensuring comprehensive visibility while controlling downstream data volumes and costs.

How It Meets the Requirements

Organization-wide aggregation across all projects: Setting the log sink at the organization root with includeChildren = true (or --include-children via gcloud) ensures that log telemetry from all existing and dynamically provisioned child folders and projects is routed automatically without per-project configuration.
Selectively routing high-fidelity security telemetry: The sink's inclusion filter explicitly targets desired log IDs, including cloudaudit.googleapis.com/activity, cloudaudit.googleapis.com/system_event, compute.googleapis.com/vpc_flows, and cloudaudit.googleapis.com/data_access.
Filtering out high-volume and routine events: Configuring exclusion filters on the sink (such as matching protoPayload.methodName =~ "^storage\.(buckets|objects)\.(get|list)$" and LOG_ID("maintenance.googleapis.com/maintenance_events")) discards low-fidelity entries immediately after ingestion, preventing costly streaming to the destination SIEM.
Centralized administration: Managing a single aggregated sink at the organization level eliminates configuration drift and administrative overhead across individual project log routers.

Key Advantages and Capabilities

Dynamic discovery: Automatically captures logs from new projects as soon as they are created under the resource hierarchy.
Deterministic evaluation order: Cloud Logging first validates the inclusion filter; if a log matches the inclusion criteria and does not match any exclusion rule, it is forwarded to the designated export destination.
Granular exclusion limits: Supports up to 50 exclusion filters per sink, with query lengths up to 20,000 characters, allowing fine-grained tuning of noisy APIs.
Direct SIEM integration: Routes filtered streams directly to external endpoints, Pub/Sub topics, or Cloud Storage buckets for downstream ingestion.

Why This Is Optimal

This solution provides unified security governance and least-privilege administrative boundaries. It prevents operational silos, guarantees that developers cannot bypass or disable audit logging at the project level, and optimizes external SIEM ingestion costs by discarding non-actionable read/list telemetry before egress.

View source documentation

Deploy individual project-level sinks across all existing projects routing to the external SIEM, and modify the _Required and _Default sinks in each project to add the exclusion filters.

What Project-Level Sinks and Local Sinks Do

Project-level sinks route logs originating within a single project's Log Router to specified local or cross-project destinations. Every project is automatically provisioned with local _Default and _Required sinks routing to corresponding local log buckets.

Why It Doesn't Meet the Requirement

No automatic inheritance: Project-level sinks must be manually or programmatically deployed in every project. New projects provisioned in the future will not automatically export logs until explicitly configured, violating the requirement for automated aggregation.
Modifying the _Required sink is impossible: The _Required sink cannot be modified to add exclusion rules or change its destination. Attempting to add exclusion filters to _Required sinks is rejected by the API.
High administrative overhead: Managing sinks and exclusion filters across hundreds of projects independently introduces massive configuration drift, maintenance overhead, and security auditing complexity.

Key Characteristics and Limitations

Managing individual project sinks does not scale for enterprise environments with dynamic project lifecycles.
Project administrators with sufficient IAM permissions could inadvertently alter or delete local project sinks, breaking centralized audit trails.
Exclusion filters applied only to the project _Default sink stop logs from entering the local _Default bucket, but do not automatically export or tune custom sink pipelines.

This Answer Would Be Correct If

The organization had a decentralized management model where individual project owners were required to maintain isolated SIEM export pipelines with localized budgeting and sink configurations.

Additional Context

Centralized security and compliance monitoring in Google Cloud strongly favors organization-level aggregated sinks over distributed project-level sinks to enforce immutable, tamper-resistant logging architecture.

View source documentation

Last updated September 11, 2026

Centralized SIEM Export with Organization Log Sinks

The security engineering team has defined the following requirements:

Automatically aggregate Admin Activity audit logs, System Event logs, VPC Flow Logs, and Data Access audit logs across all existing and future folders and projects in the Google Cloud organization.
Filter out high-volume, low-fidelity Data Access audit events (specifically Cloud Storage object get and list operations) and routine maintenance events before exporting them to reduce external SIEM ingestion costs.
Maintain centralized administration without requiring per-project log router sink management.

Which architecture should the team implement to meet these requirements?

Create an aggregated log sink at the organization level with an empty inclusion filter, and revoke Data Access IAM permissions from service accounts to prevent noisy logs from being generated.

Deploy individual project-level sinks across all existing projects routing to the external SIEM, and modify the _Required and _Default sinks in each project to add the exclusion filters.

Explanations

Create an aggregated log sink at the organization level with the includeChildren parameter disabled, and modify the organization-level _Required sink to forward child project logs to the destination SIEM.

What the Organization _Required Sink and Non-Aggregated Sinks Are

Why It Doesn't Meet the Requirement

Inability to capture child resources: When includeChildren is disabled, the organization sink ignores logs originating within child folders and projects, failing the multi-project aggregation requirement.
Immutability of system sinks: The _Required sink is immutable and system-managed. Administrators cannot edit its inclusion filter, attach exclusion filters, alter its destination, or modify it to forward logs to external SIEM tools or destinations.
Scope limitation of system sinks: The _Required sink only processes logs that originate within the specific resource where it resides and does not aggregate logs across the resource hierarchy.

Key Characteristics and Limitations

System-created _Required sinks cannot be disabled, modified, or deleted by any IAM principal.
System-created sinks retain logs strictly within local Google-managed _Required log buckets for 400 days at no charge.
An aggregated sink must explicitly enable child inheritance (includeChildren) to collect telemetry across descending hierarchy nodes.

This Answer Would Be Correct If

The organization only required local Google Cloud storage of root-level administrative actions within the native _Required bucket and did not need to route multi-project logs to an external SIEM.

Additional Context

View source documentation

Create an aggregated log sink at the organization level with an empty inclusion filter, and revoke Data Access IAM permissions from service accounts to prevent noisy logs from being generated.

What IAM Permission Revocation and Empty Inclusion Filters Do

Why It Doesn't Meet the Requirement

Breaks operational application workloads: Revoking service account permissions to stop Data Access log generation disables normal application read and list operations, causing application outages rather than filtering log telemetry.
Excessive log routing volume: Leaving the inclusion filter completely empty without specific criteria causes all log types across the entire organization (including debug logs, build logs, and high-frequency system logs) to be routed, drastically inflating export volumes.
Fails log filtering best practices: Log noise reduction must be handled through sink exclusion filters or IAM audit log exemption configurations, not by removing legitimate application IAM roles.

Key Characteristics and Limitations

If a sink does not specify an inclusion filter, every single log entry received by Cloud Logging matches the sink.
Revoking IAM permissions modifies access authorization rather than log collection policies.
Routine Data Access logs generated by authorized application workflows should be filtered using Logging query expressions (e.g., regex pattern matching on protoPayload.methodName).

This Answer Would Be Correct If

The security team intended to capture absolutely all log types without exception and decommission service accounts that were identified as completely redundant or compromised.

Additional Context

View source documentation

Create an aggregated log sink at the organization level with the includeChildren parameter enabled, configure an inclusion filter for the required log IDs, and define exclusion filters for the routine Cloud Storage operations and maintenance events.

What Aggregated Log Sinks and Filter Rules Are

How It Meets the Requirements

Organization-wide aggregation across all projects: Setting the log sink at the organization root with includeChildren = true (or --include-children via gcloud) ensures that log telemetry from all existing and dynamically provisioned child folders and projects is routed automatically without per-project configuration.
Selectively routing high-fidelity security telemetry: The sink's inclusion filter explicitly targets desired log IDs, including cloudaudit.googleapis.com/activity, cloudaudit.googleapis.com/system_event, compute.googleapis.com/vpc_flows, and cloudaudit.googleapis.com/data_access.
Filtering out high-volume and routine events: Configuring exclusion filters on the sink (such as matching protoPayload.methodName =~ "^storage\.(buckets|objects)\.(get|list)$" and LOG_ID("maintenance.googleapis.com/maintenance_events")) discards low-fidelity entries immediately after ingestion, preventing costly streaming to the destination SIEM.
Centralized administration: Managing a single aggregated sink at the organization level eliminates configuration drift and administrative overhead across individual project log routers.

Key Advantages and Capabilities

Dynamic discovery: Automatically captures logs from new projects as soon as they are created under the resource hierarchy.
Deterministic evaluation order: Cloud Logging first validates the inclusion filter; if a log matches the inclusion criteria and does not match any exclusion rule, it is forwarded to the designated export destination.
Granular exclusion limits: Supports up to 50 exclusion filters per sink, with query lengths up to 20,000 characters, allowing fine-grained tuning of noisy APIs.
Direct SIEM integration: Routes filtered streams directly to external endpoints, Pub/Sub topics, or Cloud Storage buckets for downstream ingestion.

Why This Is Optimal

View source documentation

Deploy individual project-level sinks across all existing projects routing to the external SIEM, and modify the _Required and _Default sinks in each project to add the exclusion filters.

What Project-Level Sinks and Local Sinks Do

Why It Doesn't Meet the Requirement

No automatic inheritance: Project-level sinks must be manually or programmatically deployed in every project. New projects provisioned in the future will not automatically export logs until explicitly configured, violating the requirement for automated aggregation.
Modifying the _Required sink is impossible: The _Required sink cannot be modified to add exclusion rules or change its destination. Attempting to add exclusion filters to _Required sinks is rejected by the API.
High administrative overhead: Managing sinks and exclusion filters across hundreds of projects independently introduces massive configuration drift, maintenance overhead, and security auditing complexity.

Key Characteristics and Limitations

Managing individual project sinks does not scale for enterprise environments with dynamic project lifecycles.
Project administrators with sufficient IAM permissions could inadvertently alter or delete local project sinks, breaking centralized audit trails.
Exclusion filters applied only to the project _Default sink stop logs from entering the local _Default bucket, but do not automatically export or tune custom sink pipelines.

This Answer Would Be Correct If

The organization had a decentralized management model where individual project owners were required to maintain isolated SIEM export pipelines with localized budgeting and sink configurations.

Additional Context

View source documentation

Last updated September 11, 2026

Centralized SIEM Export with Organization Log Sinks

Explanations

Create an aggregated log sink at the organization level with the includeChildren parameter disabled, and modify the organization-level _Required sink to forward child project logs to the destination SIEM.

What the Organization _Required Sink and Non-Aggregated Sinks Are

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Create an aggregated log sink at the organization level with an empty inclusion filter, and revoke Data Access IAM permissions from service accounts to prevent noisy logs from being generated.

What IAM Permission Revocation and Empty Inclusion Filters Do

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Create an aggregated log sink at the organization level with the includeChildren parameter enabled, configure an inclusion filter for the required log IDs, and define exclusion filters for the routine Cloud Storage operations and maintenance events.

What Aggregated Log Sinks and Filter Rules Are

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Deploy individual project-level sinks across all existing projects routing to the external SIEM, and modify the _Required and _Default sinks in each project to add the exclusion filters.

What Project-Level Sinks and Local Sinks Do

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Try 10 interactive questions like this one, free

Related questions

Log Sink CMEK and VPC Service Controls

Cloud Logging Sink to Pub/Sub Push Feed

Delegated Admin Role and Enforcement Groups

Cloud NGFW URL Filtering

Log Analytics Linked BigQuery Dataset

Datastore Query Cursors and Projection Queries

Centralized SIEM Export with Organization Log Sinks

Explanations

Create an aggregated log sink at the organization level with the includeChildren parameter disabled, and modify the organization-level _Required sink to forward child project logs to the destination SIEM.

What the Organization _Required Sink and Non-Aggregated Sinks Are

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Create an aggregated log sink at the organization level with an empty inclusion filter, and revoke Data Access IAM permissions from service accounts to prevent noisy logs from being generated.

What IAM Permission Revocation and Empty Inclusion Filters Do

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Create an aggregated log sink at the organization level with the includeChildren parameter enabled, configure an inclusion filter for the required log IDs, and define exclusion filters for the routine Cloud Storage operations and maintenance events.

What Aggregated Log Sinks and Filter Rules Are

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Deploy individual project-level sinks across all existing projects routing to the external SIEM, and modify the _Required and _Default sinks in each project to add the exclusion filters.

What Project-Level Sinks and Local Sinks Do

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Additional Context

Try 10 interactive questions like this one, free

Related questions

Log Sink CMEK and VPC Service Controls

Cloud Logging Sink to Pub/Sub Push Feed

Delegated Admin Role and Enforcement Groups

Cloud NGFW URL Filtering

Log Analytics Linked BigQuery Dataset

Datastore Query Cursors and Projection Queries