Practice Free Professional Cloud Security Engineer Exam Online Questions
Question #1
Your organization is moving virtual machines (VMs) to Google Cloud. You must ensure that operating system images that are used across your projects are trusted and meet your security requirements.
What should you do?
- A . Implement an organization policy to enforce that boot disks can only be created from images that come from the trusted image project.
- B . Create a Cloud Function that is automatically triggered when a new virtual machine is created from the trusted image repository Verify that the image is not deprecated.
- C . Implement an organization policy constraint that enables the Shielded VM service on all projects to enforce the trusted image repository usage.
- D . Automate a security scanner that verifies that no common vulnerabilities and exposures (CVEs) are present in your trusted image repository.
Correct Answer: A
A
Explanation:
Define Trusted Image Projects:
Identify the project or projects where your trusted operating system images are stored.
Ensure these images meet your organization’s security requirements and are regularly updated to mitigate vulnerabilities.
Create an Organization Policy:
Navigate to the Organization Policies page in the Google Cloud Console.
Create a policy constraint that restricts the creation of boot disks to only those images stored in your trusted image project(s).
The policy constraint to use is constraints/compute.trustedImageProjects.
Apply the Policy:
Apply this organization policy at the appropriate level (organization, folder, or project) to enforce that all new VM instances use images from the trusted repository.
This ensures consistency in the security posture across all projects within the organization.
Monitor Compliance:
Regularly monitor the compliance with this policy using audit logs and other monitoring tools.
Update the trusted images as necessary to ensure they remain secure and compliant with your security standards.
Reference: Organization Policy Service
Trusted Image Projects Constraint
A
Explanation:
Define Trusted Image Projects:
Identify the project or projects where your trusted operating system images are stored.
Ensure these images meet your organization’s security requirements and are regularly updated to mitigate vulnerabilities.
Create an Organization Policy:
Navigate to the Organization Policies page in the Google Cloud Console.
Create a policy constraint that restricts the creation of boot disks to only those images stored in your trusted image project(s).
The policy constraint to use is constraints/compute.trustedImageProjects.
Apply the Policy:
Apply this organization policy at the appropriate level (organization, folder, or project) to enforce that all new VM instances use images from the trusted repository.
This ensures consistency in the security posture across all projects within the organization.
Monitor Compliance:
Regularly monitor the compliance with this policy using audit logs and other monitoring tools.
Update the trusted images as necessary to ensure they remain secure and compliant with your security standards.
Reference: Organization Policy Service
Trusted Image Projects Constraint
Question #2
Your team needs to prevent users from creating projects in the organization. Only the DevOps team should be allowed to create projects on behalf of the requester.
Which two tasks should your team perform to handle this request? (Choose two.)
- A . Remove all users from the Project Creator role at the organizational level.
- B . Create an Organization Policy constraint, and apply it at the organizational level.
- C . Grant the Project Editor role at the organizational level to a designated group of users.
- D . Add a designated group of users to the Project Creator role at the organizational level.
- E . Grant the billing account creator role to the designated DevOps team.
Correct Answer: A,D
A,D
Explanation:
Objective: Prevent users from creating projects while allowing only the DevOps team to create projects.
Solution: Modify IAM roles and permissions.
Steps:
Step 1: Open the Google Cloud Console.
Step 2: Navigate to the IAM & Admin page.
Step 3: At the organizational level, find and remove all users from the Project Creator role.
Step 4: Create or identify a group for the DevOps team.
Step 5: Assign the Project Creator role to the DevOps team group at the organizational level.
By removing all users from the Project Creator role and granting it only to the DevOps team, you ensure that only the designated team can create projects.
Reference: GCP IAM Documentation
Project Creator Role
A,D
Explanation:
Objective: Prevent users from creating projects while allowing only the DevOps team to create projects.
Solution: Modify IAM roles and permissions.
Steps:
Step 1: Open the Google Cloud Console.
Step 2: Navigate to the IAM & Admin page.
Step 3: At the organizational level, find and remove all users from the Project Creator role.
Step 4: Create or identify a group for the DevOps team.
Step 5: Assign the Project Creator role to the DevOps team group at the organizational level.
By removing all users from the Project Creator role and granting it only to the DevOps team, you ensure that only the designated team can create projects.
Reference: GCP IAM Documentation
Project Creator Role
Question #3
You work for a large organization where each business unit has thousands of users. You need to delegate management of access control permissions to each business unit.
You have the following requirements:
Each business unit manages access controls for their own projects.
Each business unit manages access control permissions at scale.
Business units cannot access other business units’ projects.
Users lose their access if they move to a different business unit or leave the company.
Users and access control permissions are managed by the on-premises directory service.
What should you do? (Choose two.)
- A . Use VPC Service Controls to create perimeters around each business unit’s project.
- B . Organize projects in folders, and assign permissions to Google groups at the folder level.
- C . Group business units based on Organization Units (OUs) and manage permissions based on OUs.
- D . Create a project naming convention, and use Google’s IAM Conditions to manage access based on the prefix of project names.
- E . Use Google Cloud Directory Sync to synchronize users and group memberships in Cloud Identity.
Correct Answer: B,E
B,E
Explanation:
To delegate management of access control permissions to each business unit effectively, organizing projects into folders and assigning permissions to Google groups at the folder level allows for scalable and manageable access control. Using Google Cloud Directory Sync (GCDS) to synchronize users and groups from the on-premises directory service ensures that access controls are maintained and updated automatically as users change roles or leave the company.
Steps:
Organize Projects in Folders: Create a folder structure in the Google Cloud Resource Manager to organize projects by business unit.
Assign Permissions to Google Groups: Use IAM to assign necessary permissions to Google Groups at the folder level, ensuring each business unit can manage access controls for their own projects.
Synchronize Users and Groups: Use GCDS to sync users and group memberships from your on-premises directory service to Google Cloud Identity, ensuring that changes in the on-premises directory are reflected in Google Cloud.
Reference: Google Cloud Resource Manager
Google Cloud Directory Sync
B,E
Explanation:
To delegate management of access control permissions to each business unit effectively, organizing projects into folders and assigning permissions to Google groups at the folder level allows for scalable and manageable access control. Using Google Cloud Directory Sync (GCDS) to synchronize users and groups from the on-premises directory service ensures that access controls are maintained and updated automatically as users change roles or leave the company.
Steps:
Organize Projects in Folders: Create a folder structure in the Google Cloud Resource Manager to organize projects by business unit.
Assign Permissions to Google Groups: Use IAM to assign necessary permissions to Google Groups at the folder level, ensuring each business unit can manage access controls for their own projects.
Synchronize Users and Groups: Use GCDS to sync users and group memberships from your on-premises directory service to Google Cloud Identity, ensuring that changes in the on-premises directory are reflected in Google Cloud.
Reference: Google Cloud Resource Manager
Google Cloud Directory Sync
Question #4
You are developing a new application that uses exclusively Compute Engine VMs Once a day. this application will execute five different batch jobs Each of the batch jobs requires a dedicated set of permissions on Google Cloud resources outside of your application. You need to design a secure access concept for the batch jobs that adheres to the least-privilege principle
What should you do?
- A . 1. Create a general service account **g-sa" to execute the batch jobs.
• 2 Grant the permissions required to execute the batch jobs to g-sa.
• 3. Execute the batch jobs with the permissions granted to g-sa - B . 1. Create a general service account "g-sa" to orchestrate the batch jobs.
• 2. Create one service account per batch job Mb-sa-[1-5]," and grant only the permissions required to run the individual batch jobs to the service accounts.
• 3. Grant the Service Account Token Creator role to g-sa Use g-sa to obtain short-lived access tokens for b-sa-[1-5] and to execute the batch jobs with the permissions of b-sa-[1-5]. - C . 1. Create a workload identity pool and configure workload identity pool providers for each batch job
• 2 Assign the workload identity user role to each of the identities configured in the providers.
• 3. Create one service account per batch job Mb-sa-[1-5]". and grant only the permissions required to run the individual batch jobs to the service accounts
• 4 Generate credential configuration files for each of the providers Use these files to execute the batch jobs with the permissions of b-sa-[1-5]. - D . • 1. Create a general service account "g-sa" to orchestrate the batch jobs.
• 2 Create one service account per batch job ‘b-sa-[1-5) Grant only the permissions required to run the individual batch jobs to the service accounts and generate service account keys for each of these service accounts
• 3. Store the service account keys in Secret Manager. Grant g-sa access to Secret Manager and run the batch jobs with the permissions of b-sa-[1-5].
Correct Answer: B
Question #5
You are setting up a CI/CD pipeline to deploy containerized applications to your production clusters on Google Kubernetes Engine (GKE). You need to prevent containers with known vulnerabilities from being deployed.
You have the following requirements for your solution:
Must be cloud-native
Must be cost-efficient
Minimize operational overhead
How should you accomplish this? (Choose two.)
- A . Create a Cloud Build pipeline that will monitor changes to your container templates in a Cloud Source Repositories repository. Add a step to analyze Container Analysis results before allowing the build to continue.
- B . Use a Cloud Function triggered by log events in Google Cloud’s operations suite to automatically scan your container images in Container Registry.
- C . Use a cron job on a Compute Engine instance to scan your existing repositories for known vulnerabilities and raise an alert if a non-compliant container image is found.
- D . Deploy Jenkins on GKE and configure a CI/CD pipeline to deploy your containers to Container Registry. Add a step to validate your container images before deploying your container to the cluster.
- E . In your CI/CD pipeline, add an attestation on your container image when no vulnerabilities have been found. Use a Binary Authorization policy to block deployments of containers with no attestation in your cluster.
Correct Answer: A,E
A,E
Explanation:
A,E
Explanation:
Question #6
Your organization is deploying a serverless web application on Cloud Run that must be publicly accessible over HTTPS. To meet security requirements, you need to terminate TLS at the edge, apply threat mitigation, and prepare for geo-based access restrictions.
What should you do?
- A . Make the Cloud Run service public by enabling all Users access. Configure Identity-Aware Proxy (IAP) for authentication and IP-based access control. Use custom SSL certificates for HTTPS.
- B . Assign a custom domain to the Cloud Run service. Enable HTTPS. Configure IAM to allow all Users to invoke the service. Use firewall rules and VPC Service Controls for geo-based restriction and traffic filtering.
- C . Deploy an external HTTP(S) load balancer with a serverless NEG that points to the Cloud Run service. Use a Google-managed certificate for TLS termination. Configure a Cloud Armor policy with geo-based access control.
- D . Create a Cloud DNS public zone for the Cloud Run URL. Bind a static IP to the service. Use VPC firewall rules to restrict incoming traffic based on IP ranges and threat signatures.
Correct Answer: C
C
Explanation:
The problem requires a publicly accessible Cloud Run service with HTTPS, TLS termination at the edge, threat mitigation, and geo-based access restrictions.
External HTTP(S) Load Balancer: This is the standard Google Cloud component for exposing public-facing web applications, providing a single global IP address, global load balancing, and crucially, TLS termination at the edge of Google’s network.
Serverless Network Endpoint Group (NEG): A serverless NEG connects an HTTP(S) Load Balancer to a Cloud Run service (or other serverless backends like Cloud Functions or App Engine), allowing the load balancer to route traffic to the serverless application.Extract
Reference: "You can use an external HTTP(S) Load Balancer with a serverless network endpoint group (NEG) to integrate Cloud Run services with advanced load balancing features, such as Cloud CDN, Google Cloud Armor, and Cloud Identity-Aware Proxy." (Google Cloud Documentation: "Connect a Cloud Run service to an HTTP(S) Load Balancer | Cloud Run Documentation" – https://cloud.google.com/run/docs/integrating/load-balancers)
Google-Managed Certificate for TLS Termination: Using Google-managed SSL certificates simplifies the management of HTTPS, as Google handles the provisioning, renewal, and deployment of certificates. The external HTTP(S) Load Balancer terminates TLS using these certificates.Extract
Reference: "Google-managed SSL certificates let you use Google Cloud’s globally distributed infrastructure to automatically provision and renew your certificates." (Google Cloud Documentation: "Google-managed SSL certificates overview | Load Balancing" – https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs)
Cloud Armor for Threat Mitigation and Geo-Based Access Control: Cloud Armor is a Web Application Firewall (WAF) service that integrates with HTTP(S) Load Balancers. It provides DDoS protection, allows custom rules for threat mitigation (e.g., SQL injection, XSS), and supports geo-based access control rules to allow or deny traffic based on the source’s geographic region.Extract
Reference: "Google Cloud Armor helps protect your Google Cloud deployments from various threats, including Distributed Denial of Service (DDoS) attacks and application attacks such as cross-site scripting (XSS) and SQL injection (SQLi)." and "Google Cloud Armor supports geo-based access control, allowing you to filter requests based on geographic region." (Google Cloud Documentation: "Google Cloud Armor overview" – https://cloud.google.com/armor/docs/overview)
Let’s evaluate the other options:
C
Explanation:
The problem requires a publicly accessible Cloud Run service with HTTPS, TLS termination at the edge, threat mitigation, and geo-based access restrictions.
External HTTP(S) Load Balancer: This is the standard Google Cloud component for exposing public-facing web applications, providing a single global IP address, global load balancing, and crucially, TLS termination at the edge of Google’s network.
Serverless Network Endpoint Group (NEG): A serverless NEG connects an HTTP(S) Load Balancer to a Cloud Run service (or other serverless backends like Cloud Functions or App Engine), allowing the load balancer to route traffic to the serverless application.Extract
Reference: "You can use an external HTTP(S) Load Balancer with a serverless network endpoint group (NEG) to integrate Cloud Run services with advanced load balancing features, such as Cloud CDN, Google Cloud Armor, and Cloud Identity-Aware Proxy." (Google Cloud Documentation: "Connect a Cloud Run service to an HTTP(S) Load Balancer | Cloud Run Documentation" – https://cloud.google.com/run/docs/integrating/load-balancers)
Google-Managed Certificate for TLS Termination: Using Google-managed SSL certificates simplifies the management of HTTPS, as Google handles the provisioning, renewal, and deployment of certificates. The external HTTP(S) Load Balancer terminates TLS using these certificates.Extract
Reference: "Google-managed SSL certificates let you use Google Cloud’s globally distributed infrastructure to automatically provision and renew your certificates." (Google Cloud Documentation: "Google-managed SSL certificates overview | Load Balancing" – https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs)
Cloud Armor for Threat Mitigation and Geo-Based Access Control: Cloud Armor is a Web Application Firewall (WAF) service that integrates with HTTP(S) Load Balancers. It provides DDoS protection, allows custom rules for threat mitigation (e.g., SQL injection, XSS), and supports geo-based access control rules to allow or deny traffic based on the source’s geographic region.Extract
Reference: "Google Cloud Armor helps protect your Google Cloud deployments from various threats, including Distributed Denial of Service (DDoS) attacks and application attacks such as cross-site scripting (XSS) and SQL injection (SQLi)." and "Google Cloud Armor supports geo-based access control, allowing you to filter requests based on geographic region." (Google Cloud Documentation: "Google Cloud Armor overview" – https://cloud.google.com/armor/docs/overview)
Let’s evaluate the other options:
Question #7
A company has been running their application on Compute Engine. A bug in the application allowed a malicious user to repeatedly execute a script that results in the Compute Engine instance crashing. Although the bug has been fixed, you want to get notified in case this hack re-occurs.
What should you do?
- A . Create an Alerting Policy in Stackdriver using a Process Health condition, checking that the number of executions of the script remains below the desired threshold. Enable notifications.
- B . Create an Alerting Policy in Stackdriver using the CPU usage metric. Set the threshold to 80% to be notified when the CPU usage goes above this 80%.
- C . Log every execution of the script to Stackdriver Logging. Create a User-defined metric in Stackdriver Logging on the logs, and create a Stackdriver Dashboard displaying the metric.
- D . Log every execution of the script to Stackdriver Logging. Configure BigQuery as a log sink, and create a BigQuery scheduled query to count the number of executions in a specific timeframe.
Correct Answer: A
A
Explanation:
To monitor and get notified in case the script causing the Compute Engine instance to crash is executed again, you should create an Alerting Policy in Stackdriver (now known as Google Cloud Monitoring). The Process Health condition can be set to monitor the number of executions of the script and ensure it remains below the desired threshold. By enabling notifications, you will be alerted if this threshold is exceeded.
Step-by-Step:
Log Script Executions: Ensure that the script execution is logged.
Create a User-Defined Metric: Go to Google Cloud Console > Logging > Logs-based Metrics, and create a new user-defined metric that counts the number of times the script executes.
Set Up Alerting Policy:
Navigate to Google Cloud Console > Monitoring > Alerting.
Click on “Create Policy”.
Add a condition and select “Logs-based Metric”.
Configure the condition to trigger when the number of script executions exceeds the threshold.
Configure Notifications: Add notification channels (email, SMS, etc.) to the alerting policy.
Save and Test: Save the policy and test to ensure notifications are received when the script is executed beyond the threshold.
Google Cloud Logging User-defined Metrics
Google Cloud Monitoring Alerting Policies
A
Explanation:
To monitor and get notified in case the script causing the Compute Engine instance to crash is executed again, you should create an Alerting Policy in Stackdriver (now known as Google Cloud Monitoring). The Process Health condition can be set to monitor the number of executions of the script and ensure it remains below the desired threshold. By enabling notifications, you will be alerted if this threshold is exceeded.
Step-by-Step:
Log Script Executions: Ensure that the script execution is logged.
Create a User-Defined Metric: Go to Google Cloud Console > Logging > Logs-based Metrics, and create a new user-defined metric that counts the number of times the script executes.
Set Up Alerting Policy:
Navigate to Google Cloud Console > Monitoring > Alerting.
Click on “Create Policy”.
Add a condition and select “Logs-based Metric”.
Configure the condition to trigger when the number of script executions exceeds the threshold.
Configure Notifications: Add notification channels (email, SMS, etc.) to the alerting policy.
Save and Test: Save the policy and test to ensure notifications are received when the script is executed beyond the threshold.
Google Cloud Logging User-defined Metrics
Google Cloud Monitoring Alerting Policies
Question #8
A retail customer allows users to upload comments and product reviews. The customer needs to make sure the text does not include sensitive data before the comments or reviews are published.
Which Google Cloud Service should be used to achieve this?
- A . Cloud Key Management Service
- B . Cloud Data Loss Prevention API
- C . BigQuery
- D . Cloud Security Scanner
Correct Answer: B
B
Explanation:
To ensure user-uploaded comments and product reviews do not include sensitive data before publication, use the Cloud Data Loss Prevention (DLP) API.
Enable DLP API:
Go to the Cloud Console and navigate to APIs & Services > Library. Search for "Data Loss Prevention API" and enable it. Configure DLP API:
Create an inspection template specifying the types of sensitive data to detect.
Set up de-identification templates if you want to redact or mask sensitive data.
Implement DLP in Application:
Use the Google Cloud DLP Client Library for the desired programming language.
Send the text data to the DLP API for inspection before saving or publishing.
from google.cloud import dlp_v2 dlp_client = dlp_v2.DlpServiceClient() parent =
f"projects/{project_id}" item = {"value": "User comment text here"} inspect_config = {"info_types":
[{"name": "PERSON_NAME"}, {"name": "CREDIT_CARD_NUMBER"}]} response =
dlp_client.inspect_content(parent=parent, inspect_config=inspect_config, item=item)
Cloud Data Loss Prevention API Documentation
DLP API Client Libraries
B
Explanation:
To ensure user-uploaded comments and product reviews do not include sensitive data before publication, use the Cloud Data Loss Prevention (DLP) API.
Enable DLP API:
Go to the Cloud Console and navigate to APIs & Services > Library. Search for "Data Loss Prevention API" and enable it. Configure DLP API:
Create an inspection template specifying the types of sensitive data to detect.
Set up de-identification templates if you want to redact or mask sensitive data.
Implement DLP in Application:
Use the Google Cloud DLP Client Library for the desired programming language.
Send the text data to the DLP API for inspection before saving or publishing.
from google.cloud import dlp_v2 dlp_client = dlp_v2.DlpServiceClient() parent =
f"projects/{project_id}" item = {"value": "User comment text here"} inspect_config = {"info_types":
[{"name": "PERSON_NAME"}, {"name": "CREDIT_CARD_NUMBER"}]} response =
dlp_client.inspect_content(parent=parent, inspect_config=inspect_config, item=item)
Cloud Data Loss Prevention API Documentation
DLP API Client Libraries
Question #9
Your organization is using Google Workspace, Google Cloud, and a third-party SIEM. You need to export events such as user logins, successful logins, and failed logins to the SIEM. Logs need to be ingested in real time or near real-time.
What should you do?
- A . Create a Cloud Storage bucket as a sink for all logs. Configure the SIEM to periodically scan the bucket for new log files.
- B . Create a Cloud Logging sink to export relevant authentication logs to a Pub/Sub topic for SIEM subscription.
- C . Poll Cloud Logging for authentication events using the gcloud logging read tool.3 Forward the events to the SIEM.
- D . Configure Google Workspace to directly send logs to the API endpoint of the third-party SIEM.4
Correct Answer: B
B
Explanation:
The standard and most efficient way to stream logs from Google Cloud (including Workspace logs that are shared with Google Cloud) to an external SIEM is via Cloud Logging Sinks pointing to Pub/Sub.5
According to Google Cloud Documentation (Architecture for exporting Cloud Logging logs):
"To stream logs to a third-party SIEM in real-time, you should create a log sink in Cloud Logging. The sink filters for specific logs (e.g., resource.type="audited_resource" and methodName:"login") and exports them to a Pub/Sub topic. The SIEM can then subscribe to this topic to pull events immediately as they are generated."
Why other options are incorrect:
A is incorrect: Exporting to Cloud Storage is for long-term archiving/compliance and is not real-time (it usually involves batched files every few hours).
C is incorrect: Polling via CLI is not scalable, introduces latency, and is prone to failure in production environments.
D is incorrect: Google Workspace does not have a native "direct push" feature for SIEM endpoints; it typically requires an intermediate step like Pub/Sub or BigQuery.
Reference: Google Cloud Documentation: "Log sinks overview" (https://cloud.google.com/logging/docs/export).
Google Cloud Documentation: "Streaming logs to Pub/Sub" (https://cloud.google.com/architecture/exporting-stackdriver-logs-to-splunk).
B
Explanation:
The standard and most efficient way to stream logs from Google Cloud (including Workspace logs that are shared with Google Cloud) to an external SIEM is via Cloud Logging Sinks pointing to Pub/Sub.5
According to Google Cloud Documentation (Architecture for exporting Cloud Logging logs):
"To stream logs to a third-party SIEM in real-time, you should create a log sink in Cloud Logging. The sink filters for specific logs (e.g., resource.type="audited_resource" and methodName:"login") and exports them to a Pub/Sub topic. The SIEM can then subscribe to this topic to pull events immediately as they are generated."
Why other options are incorrect:
A is incorrect: Exporting to Cloud Storage is for long-term archiving/compliance and is not real-time (it usually involves batched files every few hours).
C is incorrect: Polling via CLI is not scalable, introduces latency, and is prone to failure in production environments.
D is incorrect: Google Workspace does not have a native "direct push" feature for SIEM endpoints; it typically requires an intermediate step like Pub/Sub or BigQuery.
Reference: Google Cloud Documentation: "Log sinks overview" (https://cloud.google.com/logging/docs/export).
Google Cloud Documentation: "Streaming logs to Pub/Sub" (https://cloud.google.com/architecture/exporting-stackdriver-logs-to-splunk).
Question #9
Your organization is using Google Workspace, Google Cloud, and a third-party SIEM. You need to export events such as user logins, successful logins, and failed logins to the SIEM. Logs need to be ingested in real time or near real-time.
What should you do?
- A . Create a Cloud Storage bucket as a sink for all logs. Configure the SIEM to periodically scan the bucket for new log files.
- B . Create a Cloud Logging sink to export relevant authentication logs to a Pub/Sub topic for SIEM subscription.
- C . Poll Cloud Logging for authentication events using the gcloud logging read tool.3 Forward the events to the SIEM.
- D . Configure Google Workspace to directly send logs to the API endpoint of the third-party SIEM.4
Correct Answer: B
B
Explanation:
The standard and most efficient way to stream logs from Google Cloud (including Workspace logs that are shared with Google Cloud) to an external SIEM is via Cloud Logging Sinks pointing to Pub/Sub.5
According to Google Cloud Documentation (Architecture for exporting Cloud Logging logs):
"To stream logs to a third-party SIEM in real-time, you should create a log sink in Cloud Logging. The sink filters for specific logs (e.g., resource.type="audited_resource" and methodName:"login") and exports them to a Pub/Sub topic. The SIEM can then subscribe to this topic to pull events immediately as they are generated."
Why other options are incorrect:
A is incorrect: Exporting to Cloud Storage is for long-term archiving/compliance and is not real-time (it usually involves batched files every few hours).
C is incorrect: Polling via CLI is not scalable, introduces latency, and is prone to failure in production environments.
D is incorrect: Google Workspace does not have a native "direct push" feature for SIEM endpoints; it typically requires an intermediate step like Pub/Sub or BigQuery.
Reference: Google Cloud Documentation: "Log sinks overview" (https://cloud.google.com/logging/docs/export).
Google Cloud Documentation: "Streaming logs to Pub/Sub" (https://cloud.google.com/architecture/exporting-stackdriver-logs-to-splunk).
B
Explanation:
The standard and most efficient way to stream logs from Google Cloud (including Workspace logs that are shared with Google Cloud) to an external SIEM is via Cloud Logging Sinks pointing to Pub/Sub.5
According to Google Cloud Documentation (Architecture for exporting Cloud Logging logs):
"To stream logs to a third-party SIEM in real-time, you should create a log sink in Cloud Logging. The sink filters for specific logs (e.g., resource.type="audited_resource" and methodName:"login") and exports them to a Pub/Sub topic. The SIEM can then subscribe to this topic to pull events immediately as they are generated."
Why other options are incorrect:
A is incorrect: Exporting to Cloud Storage is for long-term archiving/compliance and is not real-time (it usually involves batched files every few hours).
C is incorrect: Polling via CLI is not scalable, introduces latency, and is prone to failure in production environments.
D is incorrect: Google Workspace does not have a native "direct push" feature for SIEM endpoints; it typically requires an intermediate step like Pub/Sub or BigQuery.
Reference: Google Cloud Documentation: "Log sinks overview" (https://cloud.google.com/logging/docs/export).
Google Cloud Documentation: "Streaming logs to Pub/Sub" (https://cloud.google.com/architecture/exporting-stackdriver-logs-to-splunk).