A security engineer is designing a centralized logging and compliance architecture across a multi-project Google Cloud organization. The architecture must satisfy the following technical and operational requirements: Aggregate all Admin Activity, System Event, VPC Flow Logs, and Data Access audit logs from all current and future projects into a centralized log bucket with a 365-day retention policy. Ensure all service account impersonation and short-lived credential generation events are captured. Minimize log ingestion overhead and processing load by preventing high-volume DATA_READ and DATA_WRITE audit logs from specific automated batch service accounts from being generated at the source in Cloud Bigtable. Prevent duplicate ingestion and storage costs across child projects' _Default log buckets. Which combination of actions should the security engineer implement?

1. Create an organization-level aggregated Log Router sink configured with children inclusion routing to a centralized log bucket set to a 365-day retention period. 2. In the organization IAM audit policy, enable Data Access audit logs across all services, ensure the IAM API and Security Token Service API are enabled, and configure audit configuration exemptions for the specific Bigtable service accounts. 3. Disable or add exclusion filters to the `_Default` log sinks in the child projects.: What this logging architecture is This architecture establishes an enterprise-wide, centralized log aggregation pipeline using organization-level aggregated sinks, granular IAM Data Access audit policies, and Log Router exclusions to capture critical security telemetry while optimizing costs and operational overhead. How it meets the requirements Organization-level aggregation and retention: An aggregated log sink defined at the organization root with --include-children automatically collects log entries from all current and future child projects and folders. Routing these logs to a central log bucket with a custom retention period of 365 days satisfies regulatory and auditing requirements. Capturing impersonation events: Enabling Data Access audit logs for the Identity and Access Management (IAM) API and Security Token Service API ensures that token generation, role assumption, and service account impersonation events are recorded in the audit trail. Preventing log generation at the source: Setting audit configuration exemptions within the IAM audit policy stops high-volume DATA_READ and DATA_WRITE logs from being generated by the underlying storage service in the first place, eliminating processing load and API quotas at the source. Preventing duplicate ingestion: Disabling or placing exclusion filters on child project _Default sinks (or utilizing an intercepting aggregated sink) stops child projects from duplicating log storage in their local _Default buckets. Key advantages and capabilities Automatic inheritance: Future projects under the organization hierarchy are immediately covered by the aggregated sink without manual intervention. Source-level throttling: Exempting identities in the IAM audit config prevents excessive resource overhead compared to post-ingestion exclusion filters. Non-repudiation: Centralizes log management in a dedicated security project where access permissions can be strictly restricted. Why this is optimal This approach avoids unnecessary log generation overhead at the source, eliminates duplicate billing, and guarantees end-to-end security visibility across authentication delegation and data access.

Organization Aggregated Log Sinks for Centralized Audit Logs

Centralized Audit Logging With Organization Aggregated Sinks

A security engineer is designing a centralized logging and compliance architecture across a multi-project Google Cloud organization. The architecture must satisfy the following technical and operational requirements:

Aggregate all Admin Activity, System Event, VPC Flow Logs, and Data Access audit logs from all current and future projects into a centralized log bucket with a 365-day retention policy.
Ensure all service account impersonation and short-lived credential generation events are captured.
Minimize log ingestion overhead and processing load by preventing high-volume DATA_READ and DATA_WRITE audit logs from specific automated batch service accounts from being generated at the source in Cloud Bigtable.
Prevent duplicate ingestion and storage costs across child projects' _Default log buckets.

Which combination of actions should the security engineer implement?

Create individual Log Router sinks in every individual project routing to a central Cloud Storage bucket with object lifecycle management set to 365 days.
In the project-level IAM policies, enable default Data Access audit logs for Bigtable and Compute Engine.
Configure Log Router exclusion filters on each project sink to filter out DATA_READ and DATA_WRITE log entries matching the automated service accounts.
Modify the system-created _Required log sink in each project to drop duplicate Admin Activity logs.

Deploy an organization-level aggregated Log Router sink routing to BigQuery.
Enforce the compute.disableNestedVirtualization organization policy to generate VPC Flow Logs.
Configure field-level access control on the central log bucket to redact Bigtable service account records.
Disable the _Required log bucket across all projects to prevent duplicate audit logging.

Create an aggregated Log Router sink at the organization level routing to a central log bucket.
Rely on default Google Cloud audit logging settings to capture Admin Activity and Data Access logs.
Configure Cloud Functions triggered by Pub/Sub to delete Bigtable logs from the log bucket after ingestion.
Apply an Organization Policy constraint to block _Default bucket creation across child projects.

Create an organization-level aggregated Log Router sink configured with children inclusion routing to a centralized log bucket set to a 365-day retention period.
In the organization IAM audit policy, enable Data Access audit logs across all services, ensure the IAM API and Security Token Service API are enabled, and configure audit configuration exemptions for the specific Bigtable service accounts.
Disable or add exclusion filters to the _Default log sinks in the child projects.

Explanations

Create individual Log Router sinks in every individual project routing to a central Cloud Storage bucket with object lifecycle management set to 365 days.
In the project-level IAM policies, enable default Data Access audit logs for Bigtable and Compute Engine.
Configure Log Router exclusion filters on each project sink to filter out DATA_READ and DATA_WRITE log entries matching the automated service accounts.
Modify the system-created _Required log sink in each project to drop duplicate Admin Activity logs.

What this option does

This option attempts to configure logging on a project-by-project basis, uses Log Router exclusion filters to drop Bigtable logs post-generation, and attempts to modify the _Required sink.

Why it doesn't meet the requirements

Cannot modify the _Required sink: In Google Cloud, the system-created _Required sink cannot be modified, edited, or deleted. It is permanently configured to route Admin Activity, System Event, and Access Transparency logs.
Post-generation filtering load: Log Router exclusion filters discard log entries only after they have been generated by the API service and received by the Logging API. This still imposes a processing load on Bigtable and consumes entries.write API quotas.
Misses token delegation: Enabling Data Access only on Bigtable and Compute Engine misses service account impersonation and STS token issuance events, which require enabling Data Access logs specifically for the IAM API and Security Token Service API.
Operational scalability: Individual project-level sinks require continuous manual configuration or custom automation whenever new projects are created.

This answer would be correct if

The organization had no central resource hierarchy (Organization node) and was only looking to archive non-critical application logs directly to Cloud Storage cold storage.

View source documentation

Deploy an organization-level aggregated Log Router sink routing to BigQuery.
Enforce the compute.disableNestedVirtualization organization policy to generate VPC Flow Logs.
Configure field-level access control on the central log bucket to redact Bigtable service account records.
Disable the _Required log bucket across all projects to prevent duplicate audit logging.

What this option does

This configuration routes logs to BigQuery, attempts to generate network logs via compute virtualization constraints, applies field-level redaction, and tries to disable the _Required log bucket.

Why it doesn't meet the requirements

_Required bucket cannot be disabled: System-managed _Required log buckets and sinks are immutable and cannot be disabled or deleted.
Misunderstands VPC Flow Logs: The compute.disableNestedVirtualization constraint controls hardware virtualization on Compute Engine instances; it has no role in enabling or configuring VPC Flow Logs, which must be enabled at the subnet level.
Misunderstands field-level access control: Field-level access controls hide or mask individual payload fields from specific users during querying; they do not prevent log generation, manage log volume, or reduce ingestion costs.

This answer would be correct if

The objective was to restrict internal human operators from viewing specific PII fields within existing log entries using granular IAM permissions.

View source documentation

Create an aggregated Log Router sink at the organization level routing to a central log bucket.
Rely on default Google Cloud audit logging settings to capture Admin Activity and Data Access logs.
Configure Cloud Functions triggered by Pub/Sub to delete Bigtable logs from the log bucket after ingestion.
Apply an Organization Policy constraint to block _Default bucket creation across child projects.

What this option does

This option relies on default audit logging configurations, attempts post-ingestion deletion via Cloud Functions, and suggests an Organization Policy constraint to block default bucket provisioning.

Why it doesn't meet the requirements

Default audit logs do not include Data Access: Admin Activity and System Event logs are enabled by default, but Data Access audit logs (with the exception of BigQuery) are disabled by default due to high volume and cost. They must be explicitly enabled via IAM audit configurations.
Inefficient post-ingestion deletion: Ingesting logs into a bucket and subsequently deleting them with Cloud Functions still incurs full ingestion and API write costs.
Non-existent organization policy: There is no Organization Policy constraint that prevents the creation of the system-managed _Default log bucket; control over ingestion into _Default must be done by modifying the _Default sink or adding exclusion filters.

This answer would be correct if

The organization only required Admin Activity logs and wanted event-driven remediation workflows triggered from Pub/Sub.

View source documentation

Create an organization-level aggregated Log Router sink configured with children inclusion routing to a centralized log bucket set to a 365-day retention period.
In the organization IAM audit policy, enable Data Access audit logs across all services, ensure the IAM API and Security Token Service API are enabled, and configure audit configuration exemptions for the specific Bigtable service accounts.
Disable or add exclusion filters to the _Default log sinks in the child projects.

What this logging architecture is

This architecture establishes an enterprise-wide, centralized log aggregation pipeline using organization-level aggregated sinks, granular IAM Data Access audit policies, and Log Router exclusions to capture critical security telemetry while optimizing costs and operational overhead.

How it meets the requirements

Organization-level aggregation and retention: An aggregated log sink defined at the organization root with --include-children automatically collects log entries from all current and future child projects and folders. Routing these logs to a central log bucket with a custom retention period of 365 days satisfies regulatory and auditing requirements.
Capturing impersonation events: Enabling Data Access audit logs for the Identity and Access Management (IAM) API and Security Token Service API ensures that token generation, role assumption, and service account impersonation events are recorded in the audit trail.
Preventing log generation at the source: Setting audit configuration exemptions within the IAM audit policy stops high-volume DATA_READ and DATA_WRITE logs from being generated by the underlying storage service in the first place, eliminating processing load and API quotas at the source.
Preventing duplicate ingestion: Disabling or placing exclusion filters on child project _Default sinks (or utilizing an intercepting aggregated sink) stops child projects from duplicating log storage in their local _Default buckets.

Key advantages and capabilities

Automatic inheritance: Future projects under the organization hierarchy are immediately covered by the aggregated sink without manual intervention.
Source-level throttling: Exempting identities in the IAM audit config prevents excessive resource overhead compared to post-ingestion exclusion filters.
Non-repudiation: Centralizes log management in a dedicated security project where access permissions can be strictly restricted.

Why this is optimal

This approach avoids unnecessary log generation overhead at the source, eliminates duplicate billing, and guarantees end-to-end security visibility across authentication delegation and data access.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Centralized Audit Logging With Organization Aggregated Sinks

Aggregate all Admin Activity, System Event, VPC Flow Logs, and Data Access audit logs from all current and future projects into a centralized log bucket with a 365-day retention policy.
Ensure all service account impersonation and short-lived credential generation events are captured.
Minimize log ingestion overhead and processing load by preventing high-volume DATA_READ and DATA_WRITE audit logs from specific automated batch service accounts from being generated at the source in Cloud Bigtable.
Prevent duplicate ingestion and storage costs across child projects' _Default log buckets.

Which combination of actions should the security engineer implement?

Create individual Log Router sinks in every individual project routing to a central Cloud Storage bucket with object lifecycle management set to 365 days.
In the project-level IAM policies, enable default Data Access audit logs for Bigtable and Compute Engine.
Configure Log Router exclusion filters on each project sink to filter out DATA_READ and DATA_WRITE log entries matching the automated service accounts.
Modify the system-created _Required log sink in each project to drop duplicate Admin Activity logs.

Deploy an organization-level aggregated Log Router sink routing to BigQuery.
Enforce the compute.disableNestedVirtualization organization policy to generate VPC Flow Logs.
Configure field-level access control on the central log bucket to redact Bigtable service account records.
Disable the _Required log bucket across all projects to prevent duplicate audit logging.

Create an aggregated Log Router sink at the organization level routing to a central log bucket.
Rely on default Google Cloud audit logging settings to capture Admin Activity and Data Access logs.
Configure Cloud Functions triggered by Pub/Sub to delete Bigtable logs from the log bucket after ingestion.
Apply an Organization Policy constraint to block _Default bucket creation across child projects.

Create an organization-level aggregated Log Router sink configured with children inclusion routing to a centralized log bucket set to a 365-day retention period.
In the organization IAM audit policy, enable Data Access audit logs across all services, ensure the IAM API and Security Token Service API are enabled, and configure audit configuration exemptions for the specific Bigtable service accounts.
Disable or add exclusion filters to the _Default log sinks in the child projects.

Explanations

Create individual Log Router sinks in every individual project routing to a central Cloud Storage bucket with object lifecycle management set to 365 days.
In the project-level IAM policies, enable default Data Access audit logs for Bigtable and Compute Engine.
Configure Log Router exclusion filters on each project sink to filter out DATA_READ and DATA_WRITE log entries matching the automated service accounts.
Modify the system-created _Required log sink in each project to drop duplicate Admin Activity logs.

What this option does

This option attempts to configure logging on a project-by-project basis, uses Log Router exclusion filters to drop Bigtable logs post-generation, and attempts to modify the _Required sink.

Why it doesn't meet the requirements

Cannot modify the _Required sink: In Google Cloud, the system-created _Required sink cannot be modified, edited, or deleted. It is permanently configured to route Admin Activity, System Event, and Access Transparency logs.
Post-generation filtering load: Log Router exclusion filters discard log entries only after they have been generated by the API service and received by the Logging API. This still imposes a processing load on Bigtable and consumes entries.write API quotas.
Misses token delegation: Enabling Data Access only on Bigtable and Compute Engine misses service account impersonation and STS token issuance events, which require enabling Data Access logs specifically for the IAM API and Security Token Service API.
Operational scalability: Individual project-level sinks require continuous manual configuration or custom automation whenever new projects are created.

This answer would be correct if

The organization had no central resource hierarchy (Organization node) and was only looking to archive non-critical application logs directly to Cloud Storage cold storage.

View source documentation

Deploy an organization-level aggregated Log Router sink routing to BigQuery.
Enforce the compute.disableNestedVirtualization organization policy to generate VPC Flow Logs.
Configure field-level access control on the central log bucket to redact Bigtable service account records.
Disable the _Required log bucket across all projects to prevent duplicate audit logging.

What this option does

This configuration routes logs to BigQuery, attempts to generate network logs via compute virtualization constraints, applies field-level redaction, and tries to disable the _Required log bucket.

Why it doesn't meet the requirements

_Required bucket cannot be disabled: System-managed _Required log buckets and sinks are immutable and cannot be disabled or deleted.
Misunderstands VPC Flow Logs: The compute.disableNestedVirtualization constraint controls hardware virtualization on Compute Engine instances; it has no role in enabling or configuring VPC Flow Logs, which must be enabled at the subnet level.
Misunderstands field-level access control: Field-level access controls hide or mask individual payload fields from specific users during querying; they do not prevent log generation, manage log volume, or reduce ingestion costs.

This answer would be correct if

The objective was to restrict internal human operators from viewing specific PII fields within existing log entries using granular IAM permissions.

View source documentation

Create an aggregated Log Router sink at the organization level routing to a central log bucket.
Rely on default Google Cloud audit logging settings to capture Admin Activity and Data Access logs.
Configure Cloud Functions triggered by Pub/Sub to delete Bigtable logs from the log bucket after ingestion.
Apply an Organization Policy constraint to block _Default bucket creation across child projects.

What this option does

This option relies on default audit logging configurations, attempts post-ingestion deletion via Cloud Functions, and suggests an Organization Policy constraint to block default bucket provisioning.

Why it doesn't meet the requirements

Default audit logs do not include Data Access: Admin Activity and System Event logs are enabled by default, but Data Access audit logs (with the exception of BigQuery) are disabled by default due to high volume and cost. They must be explicitly enabled via IAM audit configurations.
Inefficient post-ingestion deletion: Ingesting logs into a bucket and subsequently deleting them with Cloud Functions still incurs full ingestion and API write costs.
Non-existent organization policy: There is no Organization Policy constraint that prevents the creation of the system-managed _Default log bucket; control over ingestion into _Default must be done by modifying the _Default sink or adding exclusion filters.

This answer would be correct if

The organization only required Admin Activity logs and wanted event-driven remediation workflows triggered from Pub/Sub.

View source documentation

Create an organization-level aggregated Log Router sink configured with children inclusion routing to a centralized log bucket set to a 365-day retention period.
In the organization IAM audit policy, enable Data Access audit logs across all services, ensure the IAM API and Security Token Service API are enabled, and configure audit configuration exemptions for the specific Bigtable service accounts.
Disable or add exclusion filters to the _Default log sinks in the child projects.

What this logging architecture is

How it meets the requirements

Organization-level aggregation and retention: An aggregated log sink defined at the organization root with --include-children automatically collects log entries from all current and future child projects and folders. Routing these logs to a central log bucket with a custom retention period of 365 days satisfies regulatory and auditing requirements.
Capturing impersonation events: Enabling Data Access audit logs for the Identity and Access Management (IAM) API and Security Token Service API ensures that token generation, role assumption, and service account impersonation events are recorded in the audit trail.
Preventing log generation at the source: Setting audit configuration exemptions within the IAM audit policy stops high-volume DATA_READ and DATA_WRITE logs from being generated by the underlying storage service in the first place, eliminating processing load and API quotas at the source.
Preventing duplicate ingestion: Disabling or placing exclusion filters on child project _Default sinks (or utilizing an intercepting aggregated sink) stops child projects from duplicating log storage in their local _Default buckets.

Key advantages and capabilities

Automatic inheritance: Future projects under the organization hierarchy are immediately covered by the aggregated sink without manual intervention.
Source-level throttling: Exempting identities in the IAM audit config prevents excessive resource overhead compared to post-ingestion exclusion filters.
Non-repudiation: Centralizes log management in a dedicated security project where access permissions can be strictly restricted.

Why this is optimal

This approach avoids unnecessary log generation overhead at the source, eliminates duplicate billing, and guarantees end-to-end security visibility across authentication delegation and data access.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Centralized Audit Logging With Organization Aggregated Sinks

Explanations

What this option does

Why it doesn't meet the requirements

This answer would be correct if

What this option does

Why it doesn't meet the requirements

This answer would be correct if

What this option does

Why it doesn't meet the requirements

This answer would be correct if

What this logging architecture is

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

Google SecOps UDM and YARA-L

Cloud Storage Bucket Lock WORM Retention

Aggregated Sinks with Log Router Exclusions

Organization Aggregated Log Sink with Bucket Lock

Folder-Level Custom IAM Roles

Ephemeral Dataproc with Cloud Storage and Dataproc Metastore

Centralized Audit Logging With Organization Aggregated Sinks

Explanations

What this option does

Why it doesn't meet the requirements

This answer would be correct if

What this option does

Why it doesn't meet the requirements

This answer would be correct if

What this option does

Why it doesn't meet the requirements

This answer would be correct if

What this logging architecture is

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

Google SecOps UDM and YARA-L

Cloud Storage Bucket Lock WORM Retention

Aggregated Sinks with Log Router Exclusions

Organization Aggregated Log Sink with Bucket Lock

Folder-Level Custom IAM Roles

Ephemeral Dataproc with Cloud Storage and Dataproc Metastore