Google Practice Questions, Discussions & Exam Topics by our Authors

Your company conducts clinical trials and needs to analyze the results of a recent study that are stored in BigQuery. The interval when the medicine was taken contains start and stop dates. The interval data is critical to the analysis, but specific dates may identify a particular batch and in...

Option A: "Use date shifting with the context set to the unique ID of the test subject." - Pros: Date shifting can help obfuscate the actual start and stop dates by shifting the intervals while maintaining the relative timing. This can prevent identifying specific batches while preserving the interval data. Using the test subject’s unique ID ensures that the shifts are consistent for each subject, allowing for accurate analysis without revealing identifiable information. - Cons: Shifting dates introduces complexity in ensuring that the shifts are consistent and do not affect the analysis of the trial. It may require significant computation to calculate the shifts and ensure that the intervals are not distorted. When to use: This option is useful for maintaining privacy while ensuring that the time intervals are preserved. It is appropriate for cases where you need to preserve the interval data (start and stop dates) while obfuscating the exact dates. Option B: "Extract the date using TimePartConfig from each date field and append a random month and year." - Pros: Appending random months and years to dates could obscure the original dates, making it harder to trace specific trial batches. - Cons: This option significantly disrupts the actual interval data by randomly modifying the dates, potentially affecting the integrity of the time intervals. The randomization could break the meaning of the start and stop intervals, which is critical in clinical trial analysis. Randomizing the dates would distort the time frames in ways that may not be acceptable for meaningful analysis. When to use: This approach may be suitable for anonymizing less time-sensitive data, but it's not ideal for preserving critical interval data in clinical trials, as it introduces randomness that could skew the analysis. Option C: "Use bucketing to shift values to a predetermined date based on the initial value." - Pros: Bucketing allows grouping values within a specific range (e.g., days, weeks, months) and can help generalize dates to make them less identifiable. This can obfuscate the exact dates while preserving general intervals. - Cons: While b...

Author: Aarav · Last updated Sep 25, 2026

You have a highly sensitive BigQuery workload that contains personally identifiable information (PII) that you want to ensure is not accessible from the internet. To prevent data exfiltration, only requests fro...

Option A: "Use service perimeter and create an access level based on the authorized source IP address as the condition." - Pros: Service perimeters, part of the VPC Service Controls feature, provide a strong security measure by preventing data exfiltration from Google Cloud services, such as BigQuery. You can define a service perimeter around BigQuery to limit its access to only authorized networks. The ability to create access levels with conditions (such as restricting access based on source IP address) adds an additional layer of control. - Cons: This approach requires configuring VPC Service Controls, which might require a bit of setup and understanding of network access rules, but it is very effective for preventing unauthorized data access and exfiltration. When to use: This option is highly effective for ensuring sensitive data in BigQuery is only accessible from authorized sources, especially in environments where security is paramount and data exfiltration risks need to be mitigated. Option B: "Use Google Cloud Armor security policies defining an allowlist of authorized IP addresses at the global HTTPS load balancer." - Pros: Google Cloud Armor provides a security solution for protecting applications against DDoS attacks and can create allowlists for IP addresses, restricting access to certain resources. This is useful for controlling access to web applications or APIs. - Cons: Google Cloud Armor is designed for managing access to HTTP(S) traffic and is not intended for directly controlling access to BigQuery, which does not rely on an HTTP(S) interface for querying data. Therefore, it’s not suitable for preventing unauthorized access to BigQuery workloads, as BigQuery queries don’t go through a web load balancer. When to use: This option is useful for securing HTTP(S) traffic to web applications or APIs but not for controlling access to BigQuery or other non-HTTP services. Option C: "Use the Restrict Resource Service Usage organization policy constraint along with Cloud Data Loss Prevention (DLP)." - Pros: The Restrict Resource Service Usage organization policy allows organization...

Author: GlowingTiger · Last updated Sep 25, 2026

Your organization is moving virtual machines (VMs) to Google Cloud. You must ensure that operating system images that are used across your projects are t...

Option A: "Implement an organization policy to enforce that boot disks can only be created from images that come from the trusted image project." - Pros: This option directly addresses the need to enforce the use of trusted operating system images across projects by ensuring that only images from a specific, trusted image project can be used to create boot disks. This policy can enforce a clear boundary and minimize the risk of using untrusted or insecure images. - Cons: While this approach is effective at enforcing the use of trusted images, it doesn't directly address the security or integrity of the images themselves. For example, it doesn't ensure that the images are free of vulnerabilities or meet other security standards beyond being sourced from a trusted project. When to use: This option is ideal when the organization has a centralized image repository and wants to enforce that only specific trusted images are used across all projects. It’s effective in environments where trusted images are managed and maintained in one project. Option B: "Implement an organization policy constraint that enables the Shielded VM service on all projects to enforce the trusted image repository usage." - Pros: The Shielded VM service adds an additional layer of security by protecting the VM from certain types of attacks, such as rootkits and bootkits. It helps ensure the integrity of the VM and its image. This option ensures that Shielded VMs are used, which enhances the overall security of the operating system images. - Cons: While Shielded VMs provide enhanced security, this option doesn't directly enforce the use of trusted images in the sense of preventing the use of untrusted images. It focuses more on hardening the VM environment but doesn't fully restrict the image repository from being used if it’s not trusted. When to use: This is suitable if you want to enhance the security of VMs in addition to enforcing trusted images. However, it should be paired with other measures (such as image restrictions) to fully address the requirement of using only trusted OS images. Option C: "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." - Pros: Automating a function that...

Author: RadiantPhoenixX · Last updated Sep 25, 2026

You have stored company approved compute images in a single Google Cloud project that is used as an image repository. This project is protected with VPC Service Controls and exists in the perimeter along with other projects in your organization. This lets other projects deploy images from the image repository project. A team requires deploying a third-party disk image that is st...

To grant read access to a third-party disk image that is stored in an external Google Cloud organization, the correct option needs to ensure the external project can access the image within your VPC Service Controls perimeter. Let’s analyze each option to determine which one meets the requirement. Option A: Allow the external project by using the organizational policy, constraints/compute.trustedImageProjects. - Explanation: This option refers to using the `compute.trustedImageProjects` constraint, which allows specifying projects that contain trusted images. While this can control which projects are allowed to use images, it does not directly address access across VPC Service Controls boundaries or between projects in separate organizations. - Why rejected: The requirement is to allow read access to an image stored in an external Google Cloud project within a VPC Service Controls perimeter, which is not directly related to the `trustedImageProjects` policy constraint. It also doesn't handle egress/ingress access or service-level permissions for cross-organization deployments. Option B: 1. Update the perimeter. 2. Configure the egressTo field to include the external Google Cloud project number as an allowed resource and the serviceName to compute.googleapis.com. 3. Configure the egressFrom field to set identityType to ANY_IDENTITY. - Explanation: This option involves configuring the VPC Service Controls perimeter to allow egress to the external Google Cloud project, making the third-party image accessible for deployment. The `egressTo` field allows access to external projects, while `egressFrom` specifies that any identity can access the resource. This option provides the right permissions to allow access outside of the perimeter. - Why rejected: This approach works for making the image available externally, but the requirement specifically mentions deploying an external disk image into the perimeter, which would need ingress permissions. This o...

Author: Sam · Last updated Sep 25, 2026

A service account key has been publicly exposed on multiple public code repositories. After reviewing the logs, you notice that the keys were used to generate short-lived credentials. You n...

When a service account key has been publicly exposed, immediate action is required to mitigate any further unauthorized access and secure the system. Let’s go through each option to determine the best course of action. Option A: Delete the compromised service account. - Explanation: Deleting the compromised service account will revoke access, but it is a drastic measure. If the service account is associated with multiple critical systems, deleting it could cause service disruptions, and restoring those systems could be time-consuming. - Why rejected: While deleting the service account will immediately revoke access, it may cause significant disruptions and would require manually reconfiguring all services that rely on that service account. This is a more extreme action than necessary, especially if you can just revoke the key. Option B: Disable the compromised service account key. - Explanation: Disabling the specific compromised service account key immediately prevents it from being used without needing to delete the entire service account. This action focuses on cutting off the specific exposed access while leaving the service account itself intact for continued use in other scenarios. - Why selected: This is the most appropriate and immediate action. By disabling the specific compromised key, you immediately revoke the access provided by that key, preventing any further use of the compromised credentials without causing disruptions to other services that may be using the service account. It is a precise and effective response in this scenario. ...

Author: Olivia · Last updated Sep 25, 2026

A company is using Google Kubernetes Engine (GKE) with container images of a mission-critical application. The company wants to scan the images for known security issues and securely share the report wi...

In this scenario, the company wants to scan their container images for known security issues and securely share the report with the security team, without exposing it outside Google Cloud. Let's evaluate each option to find the best solution. Option A: 1. Enable Container Threat Detection in the Security Command Center Premium tier. 2. Upgrade all clusters that are not on a supported version of GKE to the latest possible GKE version. 3. View and share the results from the Security Command Center. - Explanation: Container Threat Detection is part of the Security Command Center, which provides visibility into security risks within Google Cloud. The feature can detect vulnerabilities in GKE workloads and container images, and the results can be shared with the security team. However, Security Command Center is a premium-tier feature, and its focus is broader than just vulnerability scanning—it's more focused on threat detection across the entire environment, including GKE. Sharing the results within the platform could still expose them to broader Google Cloud services. - Why rejected: While this option offers strong security monitoring and vulnerability detection, it is a more general-purpose tool. The company’s goal is to scan images and securely share the results within Google Cloud, and Security Command Center might expose the reports to broader services, which doesn't fully meet the requirement of keeping the reports within Google Cloud and securely sharing them. Option B: 1. Use an open-source tool in Cloud Build to scan the images. 2. Upload reports to publicly accessible buckets in Cloud Storage by using gsutil. 3. Share the scan report link with your security department. - Explanation: Using an open-source tool to scan container images can be useful for detecting vulnerabilities, and the results can be stored in Cloud Storage. However, uploading reports to publicly accessible buckets goes against the goal of securely sharing the reports within Google Cloud, as it would expose the results externally. - Why rejected: Storing reports in publicly accessible Cloud Storage buckets directly contradicts the goal of securely sharing the scan reports, as it makes them publicly accessible, potentially exposing sensit...

Author: Ming88 · Last updated Sep 25, 2026

Your application is deployed as a highly available, cross-region solution behind a global external HTTP(S) load balancer. You notice significant spikes in traffic from multiple IP addresses, but it is unknown whether the IPs are malicious. You are concerned about your applicat...

To address the concern of traffic spikes from multiple IP addresses and limit their impact on your application's availability, the solution must focus on controlling traffic based on the number of requests over a specified time interval. Let’s evaluate the options: Option A: Configure a throttle action by using Google Cloud Armor to limit the number of requests per client over a specified time interval. - Explanation: A throttle action in Google Cloud Armor can be configured to limit the number of requests a client can make within a specified time frame. This approach helps mitigate excessive traffic while not completely blocking the client, ensuring that the application remains available to legitimate users. - Why rejected: Google Cloud Armor does not specifically have a "throttle" action, but it can provide rate-limiting actions like the rate-based ban (option B). So, while it can help reduce the request rate, throttling itself is not directly an option under Google Cloud Armor. This makes it less suitable for the task. Option B: Configure a rate_based_ban action by using Google Cloud Armor and set the ban_duration_sec parameter to the specified time interval. - Explanation: This option uses the `rate_based_ban` action, which allows you to set a threshold for the maximum number of requests from a client within a given time interval. If the threshold is exceeded, the client is temporarily banned for a specified duration (`ban_duration_sec`). This effectively limits the traffic from malicious or aggressive clients while maintaining application availability for other clients. - Why selected: This is the most appropriate option. It directly addresses the problem of limiting traffic from clients that may be causing traffic spikes by temporarily banning them after they exceed a set number of requests in a specified time frame. It strikes the right balance between mitigating potential malicious traffic and ensuring that legitimate traffic is not impacted unnecessarily. Option C: Config...

Author: Layla · Last updated Sep 25, 2026

Your organization is using Active Directory and wants to configure Security Assertion Markup Language (SAML). You must set up and enforce...

To configure Single Sign-On (SSO) for all users in your organization using Security Assertion Markup Language (SAML), we need to look at the options in terms of their alignment with SAML-based configurations. Option A: 1. Create a new SAML profile. 2. Populate the sign-in and sign-out page URLs. 3. Upload the X.509 certificate. 4. Configure Entity ID and ACS URL in your IdP. - Explanation: This option involves creating a new SAML profile, which is an essential step for SSO configuration. It requires setting up important parameters like the sign-in and sign-out URLs, uploading the X.509 certificate, and configuring the Entity ID and Assertion Consumer Service (ACS) URL in your Identity Provider (IdP). These steps are indeed essential for setting up and enforcing SSO, but they lack specifics on enforcing SSO for all users, which could be an implied part of configuring it but isn’t fully outlined. - Why rejected: Although the steps mentioned are crucial for configuring SAML, there is no direct mention of enforcing SSO for all users across your organization. It's more about configuring the SAML connection itself without dealing with specific user assignment or organizational unit integration. Option B: 1. Configure prerequisites for OpenID Connect (OIDC) in your Active Directory (AD) tenant. 2. Verify the AD domain. 3. Decide which users should use SAML. 4. Assign the pre-configured profile to the selected organizational units (OUs) and groups. - Explanation: This option starts by configuring prerequisites for OpenID Connect (OIDC), which is a separate protocol from SAML. After that, it talks about verifying the AD domain and assigning the profile to specific organizational units (OUs) and groups, but it doesn’t mention anything about setting up or configuring SAML specifically. - Why rejected: OpenID Connect is a different authentication protocol and doesn't directly relate to the SAML-based c...

Author: Charlotte · Last updated Sep 25, 2026

Employees at your company use their personal computers to access your organization's Google Cloud console. You need to ensure that users can only access the Google Cloud console from their corporate-issued...

To solve the problem of ensuring that employees can only access the Google Cloud console from corporate-issued devices and verify that they have a valid enterprise certificate, let’s evaluate the available options: A) Implement an Access Policy in BeyondCorp Enterprise to verify the device certificate. Create an access binding with the access policy just created. - Reasoning: BeyondCorp Enterprise is specifically designed for securing access to applications, including Google Cloud services, by verifying the device’s security posture and identity. It allows you to create policies that enforce conditions, such as verifying that the device has a valid enterprise certificate. BeyondCorp ensures that only trusted devices (corporate-issued) can access sensitive resources. - Scenario suitability: This is ideal for environments where you need strong, device-centric access controls. It verifies the device certificate, ensuring the device is corporate-issued and meets security standards. B) Implement a VPC firewall policy. Activate packet inspection and create an allow rule to validate and verify the device certificate. - Reasoning: VPC firewall policies are designed to control traffic between resources in your cloud environment, but they are not tailored to device-level certificate verification. While you can inspect packets and control access, verifying the device certificate through firewall policies is not the intended use case. Firewall policies focus on network-level security, not device integrity. - Scenario suitability: This is not appropriate for enforcing device certificate checks before accessing Google Cloud services since it focuses on network traffic and not the actual device's authentication or certifica...

Author: Isabella1 · Last updated Sep 25, 2026

Your organization is rolling out a new continuous integration and delivery (CI/CD) process to deploy infrastructure and applications in Google Cloud. Many teams will use their own instances of the CI/CD workflow. It will run on Google Kubernetes Eng...

To determine the most secure and effective way for CI/CD pipelines to authenticate with Google Cloud APIs in Google Kubernetes Engine (GKE), we need to focus on best practices for identity management and secure access to resources. Here’s an analysis of each option: A) 1. Create two service accounts, one for the infrastructure and one for the application deployment. 2. Use workload identities to let the pods run the two pipelines and authenticate with the service accounts. 3. Run the infrastructure and application pipelines in separate namespaces. - Reasoning: This option proposes creating two service accounts (one for infrastructure and one for application deployment) and using workload identity to authenticate pods with these service accounts. The separation of pipelines into different namespaces adds an additional layer of isolation. - Scenario suitability: This is a strong solution because workload identity is a Google-recommended practice that allows GKE workloads to use Google Cloud APIs securely without managing long-lived credentials. Separating pipelines into namespaces enhances security and organization. - Drawback: This approach can be over-complicated if the organization does not need a separation of infrastructure and application pipelines, making it unnecessarily complex. B) 1. Create a dedicated service account for the CI/CD pipelines. 2. Run the deployment pipelines in a dedicated nodes pool in the GKE cluster. 3. Use the service account that you created as identity for the nodes in the pool to authenticate to the Google Cloud APIs. - Reasoning: This option focuses on creating a dedicated service account for the CI/CD pipelines and running them in a separate node pool. The service account is associated with the nodes, meaning the nodes themselves authenticate to Google Cloud APIs. - Scenario suitability: This solution works, but it is less granular compared to using workload identity. By associating the service account with the entire node pool, all pods in that pool will have access to the same permissions, which could potentially create security risks if pods do not require the same level of access. - Drawback: This approach lacks the fine-grained control and isolation that workload identity offers, making it less ideal for a multi-team environment with varying access needs. C) 1. Creat...

Author: Akash · Last updated Sep 25, 2026

Your organization's Customers must scan and upload the contract and their driver license into a web portal in Cloud Storage. You must remove all personally identifiable information (PII) from files that are older than 12 mo...

To address the need to remove personally identifiable information (PII) from files older than 12 months in Cloud Storage, the most effective approach must ensure data security, privacy, and retention. Let's analyze each option: A) Set a time to live (TTL) of 12 months for the files in the Cloud Storage bucket that removes PII and moves the files to the archive storage class. - Reasoning: TTL can automatically delete or move files based on their age. However, this option does not specifically address the removal of PII from the files; it only moves the files to an archive class after 12 months. The PII remains in the files unless explicitly processed and anonymized before the files are archived. - Scenario suitability: This approach does not meet the requirement to anonymize or de-identify the PII, only to move the files to an archival storage class. - Drawback: It doesn't remove or anonymize the PII, which is a core requirement of the scenario. B) Create a Cloud Data Loss Prevention (DLP) inspection job that de-identifies PII in files created more than 12 months ago and archives them to another Cloud Storage bucket. Delete the original files. - Reasoning: This is a robust solution that addresses both de-identification and retention. Cloud DLP can detect and de-identify PII from files. Once the files are processed, they can be archived in a different Cloud Storage bucket, and the original files can be deleted, ensuring that only anonymized data remains. - Scenario suitability: This solution is well-suited for the requirement, as it ensures PII is removed, files are archived, and the original files are deleted. Cloud DLP also provides the necessary tools for identifying and anonymizing PII. - Drawback: The only drawback might be the operational complexity of setting up and mana...

Author: Noah Williams · Last updated Sep 25, 2026

You plan to synchronize identities to Cloud Identity from a third-party identity provider (IdP). You discovered that some employees used their corporate email address to set up consumer accounts to access Google services. You need to ensure that the organization has con...

When synchronizing identities from a third-party identity provider (IdP) to Cloud Identity, it is important to ensure that the organization has full control over the configuration, security, and lifecycle of all user accounts. In this case, you need to address the fact that some employees have created consumer accounts using their corporate email addresses. Let's evaluate each option in light of the requirements. A) Mandate that those corporate employees delete their unmanaged consumer accounts. - Reasoning: Asking employees to delete their unmanaged consumer accounts would be an attempt to eliminate accounts that may be using corporate email addresses. However, enforcing this action on individual users could be difficult and might not guarantee control over the accounts since it depends on employees' compliance. Additionally, it doesn’t directly address the synchronization or transfer of control over these accounts. - Drawback: While this could eventually help clean up the situation, it doesn't provide a direct mechanism to regain control over existing consumer accounts or to synchronize them with Cloud Identity. B) Reconcile accounts that exist in Cloud Identity but not in the third-party IdP. - Reasoning: This option involves ensuring that any accounts in Cloud Identity that do not exist in the third-party IdP are reconciled and properly managed. However, this only addresses synchronization for accounts that are in Cloud Identity but not the consumer accounts that were created outside the organization. This does not solve the problem of consumer accounts created with corporate emails, which are a critical focus of the issue. - Drawback: While reconciliation may be part of the broader identity management process, it doesn’t directly address the challenge of consumer accounts that need to be brought under organizational control. C) Evict the unmanaged consumer accounts in the third-party IdP before you sync identities. - Reasoning: This option involves removing the unmanaged consumer accounts from the third-party IdP before synchronizing identities. This is a proactive approach to ensuring that only the organization's managed accounts are included in the synchronization process. It removes any unmanaged accounts that may be using corporate emails, preventing these accounts from being synchronized and ensuring that they fall under the organization's control. - Scenario suitabili...

Author: Lucas Carter · Last updated Sep 25, 2026

You are auditing all your Google Cloud resources in the production project. You want to identify all principals who...

To identify all principals who can change firewall rules in a Google Cloud production project, it's crucial to focus on actions that directly impact firewall rule changes, such as creating, updating, or deleting rules. Let’s evaluate each option: A) Use Policy Analyzer to query the permissions `compute.firewalls.get` or `compute.firewalls.list`. - Reasoning: The permissions `compute.firewalls.get` and `compute.firewalls.list` are related to reading firewall rules (getting the details or listing the rules), not modifying or changing them. These permissions allow viewing the firewall rules, but they do not grant the ability to modify or create firewall rules. - Drawback: This option is not suitable because it focuses on read-only actions, which are not related to identifying principals who can change (create, update, or delete) firewall rules. B) Use Firewall Insights to understand your firewall rules usage patterns. - Reasoning: Firewall Insights helps analyze and understand firewall rule usage patterns, such as which rules are frequently used or unused, but it does not focus on identifying who has permissions to modify firewall rules. - Drawback: While useful for understanding the state and effectiveness of firewall rules, Firewall Insights does not provide information on who has the ability to change or modify them. C) Reference the Security Health Analytics – Firewall Vulnerability Findings in the Security Command Center. - R...

Author: IronLion88 · Last updated Sep 25, 2026

Your organization previously stored files in Cloud Storage by using Google Managed Encryption Keys (GMEK), but has recently updated the internal policy to require Customer Managed Encryption Keys (CMEK). You nee...

To re-encrypt the files with Customer Managed Encryption Keys (CMEK), let’s evaluate each option carefully in terms of efficiency, cost, and ease of implementation. A) Reupload the files to the same Cloud Storage bucket specifying a key file by using gsutil - Reasoning: This option involves re-uploading the files to the same bucket but specifying a different encryption key during the upload process. While this might seem like a simple approach, it will require a full re-upload, which can be costly in terms of time, bandwidth, and potential compute costs. Additionally, this option doesn’t leverage any native functionality for re-encrypting files that already exist in the bucket. - Why rejected: This is inefficient and costly, especially for large datasets, as it would require uploading all the files again. B) Encrypt the files locally, and then use gsutil to upload the files to a new bucket - Reasoning: This option would require you to first download the files locally, manually encrypt them with the required key, and then upload them again to a new bucket. While this might give you complete control over the encryption process, it is very cumbersome and could be error-prone, especially with a large volume of files. - Why rejected: This method introduces a lot of manual effort, data transfer, and potential human error. It's time-consuming and could significantly increase costs due to downloading, encrypting locally, and re-uploading the files. C) Copy the files to a new bucket with CMEK enabled in a secondary region - Reasoning...

Author: Alexander · Last updated Sep 25, 2026

You run applications on Cloud Run. You already enabled container analysis for vulnerability scanning. However, you are concerned about the lack of control on the applications that are deployed. You must ensure that ...

To ensure that only trusted container images are deployed on Cloud Run, you need to control the source and integrity of the container images before they are used in production. Let’s evaluate the available options: A) Enable Binary Authorization on the existing Cloud Run service - Reasoning: Binary Authorization provides an additional layer of security to ensure that only trusted container images can be deployed in Cloud Run. By enabling Binary Authorization, you can enforce policies that prevent unapproved images from being deployed. This works by integrating with a container signing system, and only images that have been signed by an approved authority will be allowed for deployment. - Why selected: This is directly related to ensuring that only trusted container images are deployed. It enforces the security policy and integrates with the Cloud Run environment. This is a necessary action for controlling deployments. B) Set the organization policy constraint constraints/run.allowedBinaryAuthorizationPolicies to the list of allowed Binary Authorization policy names - Reasoning: Setting the organization policy constraint (`constraints/run.allowedBinaryAuthorizationPolicies`) will limit the list of Binary Authorization policies that can be used for Cloud Run services within the organization. This ensures that only the defined policies can be applied to Cloud Run services, making it possible to control which specific Binary Authorization policies are enforced in the organization. - Why selected: This option further refines the control over the deployment process by restricting which Binary Authorization policies are allowed, ensuring more granular and enforceable security controls over Cloud Run applications. C) Enable Binary Authorization on the existing Kubernetes cluster - Reaso...

Author: Ethan · Last updated Sep 25, 2026

Your organization has on-premises hosts that need to access Google Cloud APIs. You must enforce private connectivity between these hosts, minimize cost...

To ensure private connectivity between your on-premises hosts and Google Cloud APIs while minimizing costs and optimizing for operational efficiency, let’s evaluate the options: A) Set up VPC peering between the hosts on-premises and the VPC through the internet - Reasoning: VPC peering connects two Virtual Private Clouds (VPCs) directly, but for on-premises hosts to connect to a Google Cloud VPC over the internet, it requires internet exposure. This exposes traffic to public networks, potentially introducing security risks and latency. Also, VPC peering doesn’t offer the level of privacy and control that private connectivity solutions like VPNs or Interconnect do. - Why rejected: This option does not provide private connectivity and relies on the public internet, which is not optimal for secure, low-cost, and operationally efficient communication between on-premises hosts and Google Cloud APIs. B) Route all on-premises traffic to Google Cloud through an IPsec VPN tunnel to a VPC with Private Google Access enabled - Reasoning: This option uses an IPsec VPN to create a secure, private connection between on-premises hosts and Google Cloud. Private Google Access ensures that your on-premises hosts can access Google APIs securely over the private Google network. This solution offers encrypted traffic, low operational complexity, and cost savings compared to dedicated connections. - Why selected: This solution strikes a balance between security, cost, and operational efficiency. The VPN is cost-effective and provides a secure private connectio...

Author: NightmareDragon2025 · Last updated Sep 25, 2026

As part of your organization's zero trust strategy, you use Identity-Aware Proxy (IAP) to protect multiple applications. You need to ingest logs into a Security Information and Event Management (SIEM) s...

In the context of protecting applications with Identity-Aware Proxy (IAP) as part of a zero trust strategy, you need to ensure that you are monitoring for potential intrusions and unusual behavior. To identify threats, you need to analyze the most relevant logs that give insight into access patterns and security events. Let’s analyze each option: A) Data Access audit logs - Reasoning: Data Access audit logs contain information about the actual access to data resources, such as when data is read or written. While these logs are useful for auditing access to specific data, they are less relevant when you are focusing on securing access to applications through IAP. These logs typically focus on interactions with Google Cloud data services, rather than monitoring authentication and access events specific to IAP-protected applications. - Why rejected: This is not the most appropriate log to monitor for intrusions involving application access and user authentication via IAP. B) Policy Denied audit logs - Reasoning: Policy Denied audit logs contain entries for situations where access requests are denied due to policy constraints (such as Identity-Aware Proxy policies). These logs are crucial for understanding failed access attempts due to misconfigurations or security policies that are blocking access. They can be used to detect malicious attempts to bypass security or unauthorized access, which aligns well with intrusion detection. - Why selected: These logs are directly relevant to monitoring unauthorized access attempts, and analyzing them h...

Author: Aditya · Last updated Sep 25, 2026

Your company must follow industry specific regulations. Therefore, you need to enforce customer-managed encryption keys (CMEK) for all new Cloud Storage resource...

In this scenario, the goal is to enforce customer-managed encryption keys (CMEK) for all new Cloud Storage resources in your organization (org1). The key concern is ensuring that Cloud Storage uses CMEK and that any resources created do not use Google's default encryption. Let's evaluate each option: A) organization policy:constraints/gcp.restrictStorageNonCmekServices binding at: org1 policy type: allow policy value: all supported services - Reasoning: This option allows the use of all supported services, but it doesn't specifically enforce CMEK. It doesn't focus on restricting non-CMEK encryption for Cloud Storage resources. Instead, it seems to allow more flexibility in terms of services, which doesn’t align with the goal of ensuring CMEK for Cloud Storage. - Why Rejected: The purpose of this policy is too broad, as it allows all services and doesn't directly enforce or restrict non-CMEK encryption for Cloud Storage, making it ineffective for enforcing CMEK for Cloud Storage resources. B) organization policy:constraints/gcp.restrictNonCmekServices binding at: org1 policy type: deny policy value: storage.googleapis.com - Reasoning: This policy denies the use of any non-CMEK encryption services for Cloud Storage (`storage.googleapis.com`). It restricts Cloud Storage to only use CMEK, preventing the use of Google's default encryption (which is not customer-managed). This policy aligns with the requirement to enforce CMEK for Cloud Storage resources. - Why Selected: This policy directly meets the need to restrict Cloud Storage to only use CMEK encryption, ensuring compliance with industry-specific regulations that require customer-managed encryption keys. ...

Author: NightmareDragon2025 · Last updated Sep 25, 2026

Your company's Google Cloud organization has about 200 projects and 1,500 virtual machines. There is no uniform strategy for logs and events management, which reduces visibility for your security operations team. You need to design a logs management solution that...

In this scenario, the goal is to design a log management solution that provides visibility into the environment and allows the security operations team to monitor configurations. Each option has distinct strengths and weaknesses, and each can be evaluated based on the key factors of visibility, security team access, cost-efficiency, scalability, and ease of management. Let's analyze the options: --- Option A: 1. Create a dedicated log sink for each project: This creates a separate log sink for each project, leading to better isolation and easier project-specific log management. 2. Use BigQuery with time partitioning: BigQuery can efficiently store and query large volumes of logs. Time partitioning is beneficial for managing logs over time, especially for long-term storage and analysis. 3. Deploy alerts based on log metrics in each project: This approach allows for per-project alerting, increasing specificity in responding to issues. 4. Grant "Monitoring Viewer" role to the security team in each project: This allows the security team to monitor logs in each individual project. Advantages of Option A: - Granularity: Logs can be isolated and filtered per project. - Flexibility: Security team access is finely controlled at the project level. - Visibility: Alerts and metrics can be specific to each project, allowing the security team to get relevant data. - Scalability: Can scale by adding new projects. Disadvantages: - Management Complexity: Managing individual log sinks for each project is time-consuming and error-prone, especially with 200 projects. - Cost: Each project will incur individual costs for logging and storage, making this solution potentially costly. Best for: Organizations that prioritize fine-grained control over logs at the project level, but it is cumbersome for large-scale environments due to the management overhead. --- Option B: 1. One log sink at the organization level: This consolidates logs from all projects into a single sink, simplifying the management of logs at the organization level. 2. Use Pub/Sub to ingest logs into an SIEM system: This is an effective way to get logs into an external SIEM for more advanced analysis and monitoring. 3. Grant "Viewer" role at organization level: This ensures that the security team can access logs from all projects, centralizing visibility. Advantages of Option B: - Centralized Management: A single log sink simplifies configuration and avoids individual management for each project. - Scalability: Easily scales across the organization without needing to configure separate sinks for each project. - Integration: The use of Pub/Sub to forward logs to a SIEM is a standard industry practice and can be used for advanced security monitoring. - Cost-Effective: Centralizing the log sink reduces management costs and can also help reduce storage costs. Disadvantages: - Granularity: Security team access may not be as fine-grained. The team gets full access at the organization level, which might not be ideal for specific projects. - Potential Latency: Forwarding logs through Pub/Sub might introduce latency compared to local logging systems. Best for: Large organizations wit...

Author: Julian · Last updated Sep 25, 2026

Your Google Cloud organization allows for administrative capabilities to be distributed to each team through provision of a Google Cloud project with Owner role (roles/owner). The organization contains thousands of Google Cloud projects. Security Command Center Premium has surfaced multiple OPEN_MYSQL_...

The task is to prevent common misconfigurations like the OPEN_MYSQL_PORT findings, which expose MySQL services to the internet (i.e., from `0.0.0.0/0`). To do this effectively, the chosen solution needs to enforce security guardrails at a scalable level across the thousands of projects while being efficient in preventing unwanted exposure. Let's evaluate each option: --- Option A: Create a hierarchical firewall policy configured at the organization to deny all connections from 0.0.0.0/0. - Advantages: - Centralized control: A hierarchical firewall policy allows you to apply a rule across all projects within the organization. This provides a centralized mechanism for enforcing the guardrail. - Scalable: This option scales well with a large number of projects (thousands in this case) as the policy is inherited by all child projects. - Preventive: Denying traffic from `0.0.0.0/0` ensures that no project exposes resources to the internet, mitigating common misconfigurations. - Disadvantages: - Overblocking: This rule could block all inbound traffic from the internet, which might not be desirable for every use case (e.g., public-facing applications). - Lack of granularity: It denies traffic globally, but there may be legitimate use cases where some services require external access (e.g., for some types of API or web applications). Best for: This option is best for organizations that want to lock down all external access to their cloud environment as a preventative measure but may cause disruption if there are legitimate external-facing services. --- Option B: Create a hierarchical firewall policy configured at the organization to allow connections only from internal IP ranges. - Advantages: - Restrictive access: This rule allows connections only from internal IP ranges, ensuring that all resources are accessible only from within the organization or its network. - Centralized policy: Like Option A, this applies across the organization, which is scalable and ensures consistency. - Disadvantages: - Potential access issues: This option would block all external internet access. If there are legitimate external services or applications that need to connect to internal resources (like databases), it could cause operational issues. - Complexity: Maintaining a list of internal IP ranges may require frequent updates as the organization's network evolves. Best for: This option is ideal for highly secure environments where internal-only access is required. However, it is not flexible for situations where external service...

Author: ShadowWolf101 · Last updated Sep 25, 2026

Your organization must comply with the regulation to keep instance logging data within Europe. Your workloads will be hosted in the Netherlands in region europe-west4 in a new project. You mu...

The goal here is to ensure that instance logging data remains within the Netherlands (Europe) to comply with regulations. Each of the options should be evaluated based on compliance requirements, ease of implementation, and best practices for data residency. Option A: Configure the organization policy constraint gcp.resourceLocations to europe-west4. - Explanation: - The `gcp.resourceLocations` organization policy constraint controls the locations in which resources can be provisioned. By setting this policy, it would ensure that resources (like virtual machines or storage) are created only in the specified location (`europe-west4` in this case). - However, this only controls resource provisioning, not where logs are stored. - Advantages: - Ensures that all resources, including compute instances, are located in the desired region for compliance. - Disadvantages: - This does not directly solve the problem of logging data storage as it doesn't configure the logging service or the storage of logs themselves. Logs could still potentially be stored outside the desired region if Cloud Logging is not configured accordingly. Best for: This option could be useful for controlling where resources are located, but it doesn't directly address logging data residency. --- Option B: Configure log sink to export all logs into a Cloud Storage bucket in europe-west4. - Explanation: - Cloud Logging log sinks allow you to export logs to external destinations like Cloud Storage, BigQuery, or Pub/Sub. By configuring the log sink to export logs to a Cloud Storage bucket located in `europe-west4`, you ensure that the logs are stored within the region, satisfying data residency requirements. - Advantages: - Directly addresses the requirement by exporting logs to a specific Cloud Storage bucket located in the desired region. - Simple to configure and manage. - Disadvantages: - While effective for controlling where logs are stored, exporting logs to Cloud Storage might not be the most efficient solution for log management, especially if you need to perform frequent searches or analysis on the logs. For complex analysis, BigQuery may be more suitable. Best for: Ideal for organizations that need to ensure logs are stored in a specific region but may not require advanced querying or complex analysis of the logs. --- Option C: Create a new log bucket in europe-west4, and redirect the _Default bucket to the ne...

Author: Olivia · Last updated Sep 25, 2026

You are using Security Command Center (SCC) to protect your workloads and receive alerts for suspected security breaches at your company. You need to detect ...

To detect cryptocurrency mining software in your workloads, we need to focus on the type of service that is most suitable for identifying suspicious activities and threats within your infrastructure, such as processes or software running on virtual machines (VMs) or containers. Let’s break down the options: --- Option A: Virtual Machine Threat Detection - Explanation: - Virtual Machine Threat Detection is part of Security Command Center Premium and is designed to detect threats specifically on virtual machines. It can identify suspicious activities such as anomalous processes, which is ideal for detecting cryptocurrency mining software that often runs as background processes on VMs. - The tool works by detecting anomalies and known malware patterns, including those associated with cryptocurrency mining, which often exhibits unusual CPU utilization or specific known mining signatures. - Advantages: - Directly targets VMs, which are commonly used for unauthorized cryptocurrency mining activities. - Can detect abnormal behavior indicative of mining, such as high CPU consumption and abnormal network traffic patterns. - Disadvantages: - Focuses only on VMs and would not detect mining software running in containers or other parts of your environment. Best for: This is the most suitable option for detecting cryptocurrency mining on VMs. --- Option B: Container Threat Detection - Explanation: - Container Threat Detection focuses on detecting security issues in containers. It provides insight into container configurations, vulnerabilities, and runtime behaviors, but it doesn't specifically address VM-based threats or processes. - Advantages: - It is ideal for detecting vulnerabilities and security issues within containers or containerized applications. - Disadvantages: - This option is not focused on virtual machines, making it less suitable for detecting cryptocurrency mining software if it's running on VMs rather than containers. - While containers can also be used for cryptocurrency mining, the primary use case for this service is container environments. Best for: This is ideal for environments with containers, but not suitable for detecting cryptocurrency mining on VMs. --- Option C: Rapid Vulner...

Author: Ahmed97 · Last updated Sep 25, 2026

You are running applications outside Google Cloud that need access to Google Cloud resources. You are using workload identity federation to grant external identities Identity and Access Management (IAM) roles to eliminate the maintenance and security burden associated with service account keys. You must protect again...

To protect against identity spoofing and unauthorized access to Google Cloud resources while using workload identity federation, it’s crucial to implement measures that ensure only legitimate identities can access your resources. Let's analyze the options: --- Option A: Enable data access logs for IAM APIs - Explanation: - Enabling data access logs for IAM APIs provides audit logs of activities related to IAM, which can be useful for monitoring and detecting potential abuse or suspicious activity. However, while audit logs are helpful for tracking access patterns, they do not directly prevent identity spoofing or unauthorized access. The logs alone do not offer proactive security measures. - Advantages: - Provides visibility into how IAM APIs are used, potentially helping you detect suspicious behavior after it occurs. - Disadvantages: - This option is reactive rather than proactive. It doesn't directly mitigate the risk of identity spoofing during the authentication phase or access control. The logs help detect issues after they happen but don't prevent them. Best for: Monitoring and auditing after the fact, but not directly addressing identity protection during the access process. --- Option B: Limit the number of external identities that can impersonate a service account - Explanation: - Limiting the number of external identities that can impersonate a service account is a proactive security measure. By restricting which external identities can impersonate service accounts, you reduce the attack surface and minimize the risk of unauthorized identity impersonation. This ensures that only authorized external identities can assume the roles of service accounts, thus preventing unauthorized access. - Advantages: - Reduces risk of identity spoofing: Only trusted external identities can impersonate service accounts, which significantly decreases the likelihood of unauthorized access due to identity spoofing. - Disadvantages: - Potentially reduces flexibility, as you must explicitly manage which external identities can assume which service accounts. However, this is a trade-off for enhanced security. Best for: Preventing unauthorized access by limiting which external identities can impersonate service accounts, directly addressing the risk of identity spoofing. --- Option C: Use a dedicated project to manage workload identity pools and providers - Explanation: - Using a dedicated project to manage workload identity pools and providers is a good organizational practice for structuring and centralizing identity management. However, it does not directly protect against identity spoofing or unauthorized access. It helps with organization and scalability but doesn’t enforce tighter security controls by itself. - Advantages: - Helps with centralized management and scalability of identity pools, which can simplify the administration of external identities. - Disadvantages: - While it aids in manage...

Author: Noah · Last updated Sep 25, 2026

You manage a BigQuery analytical data warehouse in your organization. You want to keep data for all your customers in a common table while you also restrict query access based on rows and columns permiss...

In this scenario, you are aiming to keep data for all customers in a common table while controlling query access based on both rows and columns, and ensuring that non-query operations are restricted. Let's analyze each option: Option A: Create row-level access policies to restrict the result data when you run queries with the filter expression set to TRUE. - Reasoning: Row-level access policies allow you to specify who can access certain rows in a table based on user attributes or other conditions. However, setting the filter expression to `TRUE` doesn't provide the desired behavior for restricting data based on user access; it would effectively allow everyone to access the data. For row-level access policies to work, you would typically set the filter expression to `FALSE` for restricting access (which we will cover in Option C). This option is not optimal because the filter expression being set to `TRUE` allows unrestricted access. - Rejection reason: Filter expression set to `TRUE` does not restrict data; it allows everyone access. Option B: Configure column-level encryption by using Authenticated Encryption with Associated Data (AEAD) functions with Cloud Key Management Service (KMS) to control access to columns at query runtime. - Reasoning: Column-level encryption using AEAD and KMS is a good approach for securing sensitive data at rest. However, AEAD encryption focuses on protecting data from unauthorized access at the storage level, not directly controlling access at the query level. This would not prevent users from running queries or even accessing the encrypted data at runtime. - Rejection reason: AEAD encryption is not a suitable method for query-based access control, especially for non-query operations, which are to be restricted. Option C: Create row-level access policies to restrict the result data when you run queries with the filter expression set to FALSE. ...

Author: Sophia Clark · Last updated Sep 25, 2026

Your DevOps team uses Packer to build Compute Engine images by using this process: 1. Create an ephemeral Compute Engine VM. 2. Copy a binary from a Cloud Storage bucket to the VM's file system. 3. Update the VM's package manager. 4. Install external packages from the internet onto the VM. Your security team just enabled the organizational policy, constraints/ compute.vmExternalIpAccess, to restrict the usage of public IP Addresses on VMs. In response,...

In this case, the issue arises because the security team's organizational policy `constraints/compute.vmExternalIpAccess` restricts the usage of public IP addresses on the Compute Engine VMs. As a result, the DevOps team's build pipeline is failing due to connectivity issues, as the VM doesn't have internet access to install external packages. Let's analyze each option: Option A: Provision an HTTP load balancer with the VM in an unmanaged instance group to allow inbound connections from the internet to your VM. - Reasoning: This option suggests setting up a load balancer and placing the VM in an unmanaged instance group to allow inbound connections from the internet. However, this wouldn't resolve the issue of outbound internet access for the VM. The DevOps process requires outbound access to the internet to download and install packages, not inbound access to the VM. This approach focuses on inbound traffic, which isn't the core problem. - Rejection reason: This option addresses inbound traffic but does not help with outbound internet connectivity, which is necessary for downloading external packages. Option B: Provision a Cloud NAT instance in the same VPC and region as the Compute Engine VM. - Reasoning: Cloud NAT (Network Address Translation) is the right solution for providing outbound internet access to private VMs (those without public IP addresses) in a VPC. Cloud NAT allows instances without external IPs to access the internet for tasks like downloading external packages, without exposing the VM to inbound traffic from the internet. - Selection reason: This is the ideal solution because it allows the VM to download packages from the internet while still adhering to the policy that prevents public IP addresses. Option C: Enable Private Google Access on the subnet that the Comp...

Author: Ella · Last updated Sep 25, 2026

Your organization recently activated the Security Command Center (SCC) standard tier. There are a few Cloud Storage buckets that were accidentally made accessible to the public. You need t...

Let's analyze each option in detail to determine the best approach to investigate the impact and remediate the issue with public access to Cloud Storage buckets. Option A: 1. Remove the Identity and Access Management (IAM) granting access to all Users from the buckets. 2. Apply the organization policy `storage.uniformBucketLevelAccess` to prevent regressions. 3. Query the data access logs to report on unauthorized access. - Reasoning: - Step 1: Removing IAM permissions that grant access to all users is crucial to stop further unauthorized access. This is a necessary action. - Step 2: Applying `storage.uniformBucketLevelAccess` is a good step to enforce consistent access control across all objects in the bucket and prevent future misconfigurations. - Step 3: Querying the data access logs is essential to investigate if unauthorized access has occurred and determine the scope of the incident. - Selection reason: This approach involves both immediate remediation (removing IAM access) and preventive measures (applying uniform bucket level access), as well as investigating the impact (using data access logs). This is a comprehensive response. Option B: 1. Change permissions to limit access for authorized users. 2. Enforce a VPC Service Controls perimeter around all the production projects to immediately stop any unauthorized access. 3. Review the administrator activity audit logs to report on any unauthorized access. - Reasoning: - Step 1: Changing permissions to limit access is a necessary immediate action. - Step 2: VPC Service Controls might be a useful security feature, but it is more suited to creating secure service boundaries around production environments. It is not directly related to remediating public access issues in Cloud Storage buckets and would not have an immediate effect on the current incident. - Step 3: Reviewing administrator activity audit logs is good for understanding who made changes but may not directly provide details on the unauthorized access to public data. Data access logs are more relevant in this case. - Rejection reason: While the first step is good, VPC Service Controls are not directly helpful for remediating public Cloud Storage access. Additionally, the focus should be on data access logs, not just administrator activity logs. ...

Author: Leah Davis · Last updated Sep 25, 2026

Your organization is transitioning to Google Cloud. You want to ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters in a project. The containers must be deployed from a centrally m...

To ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters from a centrally managed Container Registry and signed by a trusted authority, we need to focus on enforcing policies related to image trust and deployment validation. Let's break down the available options: Option A: Enable Container Threat Detection in the Security Command Center (SCC) for the project. - Reasoning: Container Threat Detection in Security Command Center helps detect vulnerabilities and misconfigurations in your container environment, but it does not directly enforce policies to restrict deployment to only trusted images. It's focused on threat detection, not on enforcing trust for deployment. - Rejection reason: This option helps with detecting threats in containers, but it does not directly enforce the use of trusted container images or manage image signing. Option B: Configure the trusted image organization policy constraint for the project. - Reasoning: The trusted image organization policy constraint ensures that only container images from specific, trusted sources can be deployed. This policy helps control which images are allowed in the project based on their sources (like Google Container Registry or Artifact Registry) and their security posture. This constraint is a good fit for ensuring only trusted images are deployed in GKE. - Selection reason: This directly addresses the requirement of ensuring that only trusted container images are deployed. Option C: Create a custom organization policy constraint to enforce Binary Authorization for Google Kubernetes Engine (GKE). - Reasoning: Binary Authorization is a Google Cloud service that ensures only signed images are deployed to GKE. It allows you to define policies that specify which images are authorized based on digital signatures and other criteria. T...

Author: GlowingTiger · Last updated Sep 25, 2026

Your company uses Google Cloud and has publicly exposed network assets. You want to discover the assets and perform a security audit on these assets by using...

To discover publicly exposed network assets and perform a security audit on these assets as quickly as possible using a software tool, we need to consider options that streamline the discovery and auditing process. Let's analyze each option in detail: Option A: Run a platform security scanner on all instances in the organization. - Reasoning: Running a platform security scanner on all instances will allow you to scan for vulnerabilities and potential risks within the environment. However, this approach is more general and does not directly focus on discovering publicly exposed assets, nor does it address asset discovery across different resources like networks, services, or storage. - Rejection reason: While useful for scanning instances for security risks, this option doesn’t focus specifically on identifying externally exposed assets in the network, which is the primary objective. Option B: Identify all external assets by using Cloud Asset Inventory, and then run a network security scanner against them. - Reasoning: Cloud Asset Inventory provides a comprehensive view of all resources and their metadata, which includes network assets, services, and configurations within your Google Cloud environment. This will help you identify externally exposed assets, such as public IPs and other resources that might be vulnerable to external access. Once these assets are discovered, you can run a network security scanner to perform the audit, targeting specifically the publicly exposed assets. - Selection reason: This option is the most direct and efficient way to discover publicly exposed assets and immediately run a security audit on...

Author: David · Last updated Sep 25, 2026

Your organization wants to be compliant with the General Data Protection Regulation (GDPR) on Google Cloud. You must implement data residency and opera...

To implement data residency and operational sovereignty in the EU under the General Data Protection Regulation (GDPR), it's essential to ensure that data is stored, processed, and accessed within the EU. The selected options must align with these requirements while addressing security and access control. Explanation of each option: A) Limit the physical location of a new resource with the Organization Policy Service "resource locations constraint." - Reason for Selection: The "resource locations constraint" in Google Cloud allows you to specify where your cloud resources (like virtual machines, storage, databases) can be provisioned. By limiting the resource location to specific countries or regions within the EU, you can ensure data residency within EU borders, which is critical for GDPR compliance. - Scenario: This is particularly useful when creating new resources and ensuring that they reside within specific geographical regions, like EU-based data centers. B) Use Cloud IDS to get east-west and north-south traffic visibility in the EU to monitor intra-VPC and inter-VPC communication. - Reason for Rejection: While Cloud IDS (Intrusion Detection System) can help with security monitoring, it does not directly relate to ensuring data residency or operational sovereignty in the EU. Cloud IDS is focused on security traffic analysis and detection of threats rather than controlling where data is stored or processed. - Scenario: This can be helpful for security monitoring but doesn't directly contribute to the data residency requirement under GDPR. C) Limit Google personnel access based on predefined attributes such as their citizenship or geographic location by using Key Access Justifications. - Reason for Rejection: While this could potentially help with limiting access to sensitive data by Google personnel, it doesn’t specifically address the data residency or sovereignty within the EU. GDPR requires that personal data be processed a...

Author: StarlightBear · Last updated Sep 25, 2026

Your company is moving to Google Cloud. You plan to sync your users first by using Google Cloud Directory Sync (GCDS). Some employees have already created Google Cloud accounts by using their company email addresses that we...

To handle the situation of syncing users with Google Cloud, while taking into account employees who have already created accounts outside of Google Cloud Directory Sync (GCDS), it's important to take the most appropriate approach to ensure the accounts are correctly handled. Explanation of each option: A) Configure GCDS and use GCDS search rules to sync these users. - Reason for Rejection: GCDS typically syncs users from an existing LDAP directory (e.g., Active Directory) to Cloud Identity. While search rules are used to control which users are synced, this option doesn't directly address the issue of employees who have already created accounts in Google Cloud. It is mainly meant for syncing new users from an LDAP source, not for dealing with users already in Google Cloud. - Scenario: Useful if you were starting from an LDAP directory and needed to sync all users, but not for handling existing Google Cloud accounts. B) Use the transfer tool to migrate unmanaged users. - Reason for Selection: The Google Cloud Transfer Tool is designed specifically for migrating unmanaged users (users who have created Google Cloud accounts outside of GCDS) to Cloud Identity. This tool helps you manage users that were created outside of the standard GCDS process, making it the most direct and effective solution to sync users to Cloud Identity. This addresses the need to handle employees who have already created Google Cloud accounts independently. - Scenario: This is ideal when you have existing users who need to be migrated into Cloud Identity, as it effectively handles the transition from unmanaged to managed accounts. C) Write a custom script t...

Author: Manish · Last updated Sep 25, 2026

Your organization is using GitHub Actions as a continuous integration and delivery (CI/CD) platform. You must enable access to Google Cloud resources from...

To enable access to Google Cloud resources securely from GitHub Actions, it’s essential to ensure that credentials are managed properly and securely, minimizing the risk of exposing sensitive information. Let's evaluate each option to understand which best aligns with security practices and compliance. Explanation of each option: A) Create a service account key, and add it to the GitHub pipeline configuration file. - Reason for Rejection: While this option might seem simple, it involves directly embedding the service account key into the GitHub pipeline configuration file. This is highly insecure because the service account key is sensitive information, and embedding it in a configuration file increases the risk of accidental exposure. Keys stored in GitHub pipelines could potentially be leaked if proper security practices are not followed. - Scenario: This method is not recommended for secure practices, as it exposes sensitive credentials in the pipeline configuration. B) Create a service account key, and add it to the GitHub repository content. - Reason for Rejection: Similar to option A, this involves embedding a service account key in the repository content itself. This also presents a significant security risk, as the key could be exposed if the repository is accessed by unauthorized users. Storing credentials in the repository makes it prone to accidental leakage, especially if the repository is shared or if a security breach occurs. - Scenario: While it may seem like a quick fix, this method is still insecure because it involves storing sensitive data (the service account key) in a publicly or privately accessible GitHub repository. C) Configure a Google Kubernetes Engine cluste...

Author: Isabella · Last updated Sep 25, 2026

Your organization processes sensitive health information. You want to ensure that data is encrypted while in use by the virtual machines (VMs). You must create a policy...

To ensure that sensitive health information is encrypted while in use by virtual machines (VMs) within Google Cloud, a secure and enforceable policy must be implemented across the organization. Let’s break down each option and understand its relevance: Explanation of each option: A) Implement an organization policy that ensures that all VM resources created across your organization use customer-managed encryption keys (CMEK) protection. - Reason for Rejection: CMEK protects data at rest by allowing the organization to manage its own encryption keys, but it does not address encryption in use. While CMEK is useful for securing data when it is stored (data at rest), it does not secure data while it is actively being processed or used by the virtual machines (data in use). Thus, this option is not sufficient for ensuring encryption while the data is in use. - Scenario: This approach is ideal for protecting data at rest, but not for encryption during processing. B) Implement an organization policy that ensures all VM resources created across your organization are Confidential VM instances. - Reason for Selection: Confidential VMs are specifically designed to protect data in use. Confidential VMs use hardware-based Trusted Execution Environments (TEEs), which encrypt data while it is actively being processed, ensuring that sensitive data remains secure while in use. This option directly addresses the need to encrypt data while it is processed by the virtual machines. - Scenario: This is the best choice for encrypting sensitive health information while it is bei...

Author: Maya · Last updated Sep 25, 2026

You are a Cloud Identity administrator for your organization. In your Google Cloud environment, groups are used to manage user permissions. Each application team has a dedicated group. Your team is responsible for creating these groups and the application teams can manage the team members on their own through the Google Cloud...

To ensure that application teams can only add users from within your organization to their groups in Google Cloud, you need a policy or setting that explicitly limits the ability to add external users. Let's break down each option: Explanation of each option: A) Change the configuration of the relevant groups in the Google Workspace Admin console to prevent external users from being added to the group. - Reason for Rejection: While this option involves managing groups in Google Workspace, it focuses on preventing external users from being added to the group via the Google Workspace Admin console. However, Google Cloud Identity management for groups can often be handled through the Google Cloud Console or the Google Identity API, making this configuration more relevant for Workspace settings rather than a direct control for Google Cloud group memberships. Additionally, managing permissions and membership directly through the console might offer more granular control. - Scenario: This can work in a Google Workspace environment, but it does not directly address the Google Cloud environment or the required integration with Cloud Identity permissions and IAM roles. B) Set an Identity and Access Management (IAM) policy that includes a condition that restricts group membership to user principals that belong to your organization. - Reason for Selection: IAM policies in Google Cloud allow you to enforce conditions on who can access resources, including restricting group memberships. Setting a policy with conditions can specify that only users whose principals are from your organization can be added to groups. This is a targeted, programmatic way to enforce the restriction and ensure that only internal users are added to the groups, aligning well with your need to prevent external user inclusion. - Scenario: This approach works well when you want to enforce precise conditions programmatically, ensuring that only internal members (users within ...

Author: Jack · Last updated Sep 25, 2026

Your organization wants to be continuously evaluated against CIS Google Cloud Computing Foundations Benchmark v1.3.0 (CIS Google Cloud Foundation 1.3). Some of the controls are irrelevant to your organization and must be disregarded in evaluation. You need to cre...

To address the requirement of automating the evaluation of only relevant controls from the CIS Google Cloud Computing Foundations Benchmark v1.3.0 while disregarding the irrelevant ones, let's analyze each of the options presented. Option A: Mark all security findings that are irrelevant with a tag and a value that indicates a security exception. Select all marked findings, and mute them on the console every time they appear. Activate Security Command Center (SCC) Premium. - Explanation: This option involves tagging irrelevant security findings as exceptions and muting them in the Security Command Center (SCC) console, effectively automating the process of disregarding them. By activating SCC Premium, you can benefit from advanced features such as security findings management and control over which findings should be considered. - Key Factors: - Pros: Automates the muting of irrelevant findings, ensuring they don't show up in evaluations repeatedly. It integrates well into the existing environment (SCC Premium). - Cons: It requires ongoing management of tags and muting, which could be complex if the control set changes frequently. It might not be foolproof if new findings are introduced without proper tagging. Option B: Activate Security Command Center (SCC) Premium. Create a rule to mute the security findings in SCC so they are not evaluated. - Explanation: This option involves creating a rule to mute the findings in SCC, so they won't be evaluated. However, the findings are not marked with any exception tags, just muted. - Key Factors: - Pros: Mutes the findings in SCC, which reduces noise and ensures irrelevant findings don't get evaluated. - Cons: Muting findings without explicitly tagging or categori...

Author: Aria · Last updated Sep 25, 2026

You are routing all your internet facing traffic from Google Cloud through your on-premises internet connection. You want to accomplish this goal secure...

To route all internet-facing traffic from Google Cloud through your on-premises internet connection securely and with the highest bandwidth, let’s evaluate the options provided: Option A: Create an HA VPN connection to Google Cloud. Replace the default 0.0.0.0/0 route. - Explanation: This option uses an HA VPN (High Availability VPN) connection to route all traffic to and from Google Cloud through your on-premises network. The 0.0.0.0/0 route is replaced to direct all outbound traffic through this VPN connection. - Key Factors: - Pros: HA VPN offers high availability and provides a secure connection with encryption. It’s suitable for connecting your on-premises network to Google Cloud. - Cons: While HA VPN is secure, its bandwidth is limited compared to other options, as VPN connections typically offer lower throughput compared to dedicated interconnect options like Cloud Interconnect. The bandwidth might not be the highest available. Option B: Create a routing VM in Compute Engine. Configure the default route with the VM as the next hop. - Explanation: This option involves setting up a routing VM in Google Cloud, which would handle routing all internet traffic through your on-premises network. The default route in the Google Cloud VPC would be configured to send all traffic to the VM, which would then forward it to the on-premises network. - Key Factors: - Pros: This option allows full control over routing. - Cons: A routing VM in Compute Engine adds complexity and is not an efficient solution in terms of bandwidth. It would also require managing the VM, which could be prone to issues like scaling and performance bottlenecks. It’s not optimized for high bandwidth or a secure, scalable production environment. Option C: Configure Cloud Interconnect with HA VPN. Replace the default 0.0.0.0/0 route to an on-premises destination. - Explanation: This option c...

Author: Sofia2021 · Last updated Sep 25, 2026

Your organization uses Google Workspace Enterprise Edition for authentication. You are concerned about employees leaving their laptops unattended for extended periods of time after authenticating into Google Cloud. You must prevent maliciou...

To prevent malicious individuals from using an employee's unattended laptop to modify their environment in Google Cloud after authentication, let's assess each of the options: Option A: Create a policy that requires employees to not leave their sessions open for long durations. - Explanation: This option involves creating a policy that asks employees not to leave their sessions open for extended periods. - Key Factors: - Pros: It encourages employees to be aware of security and potentially reduces the risk of unattended sessions. - Cons: This is a policy-based approach and relies on employee behavior. While useful, it doesn't guarantee compliance and does not technically enforce security measures to protect against unattended sessions. It's a weak solution for addressing the technical vulnerability of an unattended session. Option B: Review and disable unnecessary Google Cloud APIs. - Explanation: This option involves reviewing and disabling unnecessary APIs in Google Cloud to reduce the potential attack surface. - Key Factors: - Pros: Disabling unnecessary APIs can improve security by limiting access to only the essential APIs. - Cons: This approach does not specifically address the issue of unattended sessions. Even if unnecessary APIs are disabled, an unattended session can still be hijacked, and malicious actors can use the laptop to access the Google Cloud environment. Therefore, it does not address the core issue of protecting against unattended sessions. Option C: Require strong passwords and 2SV through a security token or Google Authenticator. - Explanation: This option involves implementing stronger authentication methods, including strong passwords and two-step verification (2SV). - Key Factors: - Pros: Two-factor authentication (2FA) or two-step verificati...

Author: Isabella · Last updated Sep 25, 2026

You are migrating an on-premises data warehouse to BigQuery, Cloud SQL, and Cloud Storage. You need to configure security services in the data warehouse. Your company compliance policies mandate that the data warehouse must: * Protect data at rest with full lifecycle management on cryptographic keys. * Implement a separate key management provider from data...

To meet the compliance policies for your data warehouse implementation, let's assess each option: Option A: Customer-managed encryption keys (CMEK) - Explanation: CMEK allows you to manage your own encryption keys and use them to protect data at rest in Google Cloud services, including BigQuery, Cloud SQL, and Cloud Storage. It provides full lifecycle management of keys and the ability to control when keys are rotated, deleted, or archived. - Key Factors: - Pros: CMEK ensures that encryption keys are fully managed by the customer, meeting the requirement to protect data at rest. It also allows integration with Cloud Key Management Service (KMS) for centralized key management. This approach provides the needed visibility and control over encryption keys, which aligns well with compliance needs. - Cons: There is an administrative overhead in managing and rotating keys, but this is offset by the strong control and flexibility it offers. Option B: Customer-Supplied Encryption Keys (CSEK) - Explanation: CSEK allows you to supply your own encryption keys for encrypting data at rest in Google Cloud. This is used when you want full control over encryption and keys. - Key Factors: - Pros: It offers control over the keys used for data encryption. - Cons: It doesn't provide the level of flexibility and lifecycle management of keys that CMEK does, and it lacks centralized management tools like Cloud KMS. Moreover, managing keys manually increases complexity. CSEK also lacks features like auditing and automated key rotation compared to CMEK, making it less suited for compliance policies requiring visibility into key requests. Option C: Key Access Justifications - Explanation: Key Access Justifications (KJA) is a feature that records the reason or justification for accessing an encryption key. This is used to meet compliance and auditing requirements by providing justification for accessing keys. - Key Factors: - Pros: This feature enhances auditing and accountability, which is valuable for compliance. It provides insight into who is accessing keys and why. - Cons: While useful for logging key access reasons, it doesn't directly address the lifecycle managem...

Author: ThunderBear · Last updated Sep 25, 2026

You manage one of your organization's Google Cloud projects (Project A). A VPC Service Control (SC) perimeter is blocking API access requests to this project, including Pub/Sub. A resource running under a service account in another project (Project B) needs to collect messages from a Pub/Sub topic in your project. Project B is not included in a VPC S...

To resolve the issue of allowing a resource in Project B to access a Pub/Sub topic in Project A while adhering to the principle of least privilege, let's analyze the available options: Option A: Configure an ingress policy for the perimeter in Project A, and allow access for the service account in Project B to collect messages. - Explanation: An ingress policy in VPC Service Controls (SC) is used to allow specific services or resources from outside the perimeter to access resources within the perimeter. In this case, you would configure the ingress policy to allow the service account in Project B to access the Pub/Sub topic in Project A. - Key Factors: - Pros: This approach adheres to the principle of least privilege by granting access only to the specific service account that needs it. It respects the security boundaries of the VPC Service Control perimeter while still allowing the required communication. - Cons: It requires careful configuration of the ingress policy, but overall it is a secure, targeted solution that provides the necessary access without removing or weakening perimeter controls. Option B: Create an access level that allows a developer in Project B to subscribe to the Pub/Sub topic that is located in Project A. - Explanation: Creating an access level grants permission to developers in Project B to subscribe to the Pub/Sub topic in Project A. - Key Factors: - Pros: Access levels are useful for defining broad roles and permissions across multiple users. - Cons: This option is not ideal for adhering to the principle of least privilege since it would grant access to a developer (potentially unnecessary access), and it does not directly address the service account issue. Additionally, this is more focused on user access, not on service-to-service access, which is what is needed here. Option C: Create a perimeter bridge between Project A and Project B to allow the required communication between both projects. - Explanation: A ...

Author: Maya · Last updated Sep 25, 2026

You define central security controls in your Google Cloud environment. For one of the folders in your organization, you set an organizational policy to deny the assignment of external IP addresses to VMs. Two days later, you receive an al...

In this scenario, the alert about a new VM with an external IP address under the folder suggests that the assigned organizational policy isn't being fully enforced or something has bypassed it. Let's go through the options and evaluate each one: A) The VM was created with a static external IP address that was reserved in the project before the organizational policy rule was set. - If the external IP address was already reserved before the policy was applied, it could still be assigned to a VM, even after the policy is implemented. Reserved IPs are independent of the policy being set afterward, meaning the policy wouldn't retroactively prevent using those reserved IPs. - This option is valid because reserved IPs can still be used even if the policy is applied afterward. However, this doesn't imply a policy violation; it just explains the behavior of reserved IPs. B) The organizational policy constraint wasn't properly enforced and is running in "dry run" mode. - If the policy were in "dry run" mode, it would only simulate the enforcement and not actually apply the restriction. As a result, you could still see the VM with an external IP address even though the policy is intended to block it. - This option is unlikely, as the scenario doesn’t mention anything about the policy being in dry run mode. If this were the case, you would expect to see a different type of alert indicating that the policy was in a non-enforced state. C) A project level, the organizational policy control has been overwritten with an "allow" value. - The policy at the project level could override the folder's policy if it has a mo...

Author: Olivia · Last updated Sep 25, 2026

Your company recently published a security policy to minimize the usage of service account keys. On-premises Windows-based applications are interacting with Google Cloud APIs. You need to implement Workload ...

To address the requirement of implementing Workload Identity Federation (WIF) with on-premises Windows-based applications interacting with Google Cloud APIs, it's important to choose the solution that minimizes the usage of service account keys while integrating with an on-premises identity provider. Let's break down each option: A) Set up a workload identity pool with your corporate Active Directory Federation Service (ADFS). Configure a rule to let principals in the pool impersonate the Google Cloud service account. - Active Directory Federation Services (ADFS) is a common enterprise solution for identity management. Configuring WIF with ADFS allows users or applications to authenticate via their existing corporate Active Directory credentials and then impersonate a Google Cloud service account using rules you set in the identity pool. - This option uses the identity provider (ADFS) effectively, while minimizing service account key usage. By configuring a rule that restricts which principals can impersonate the Google Cloud service account, you ensure that only trusted identities are allowed access. - This option is the best choice because it ensures proper security and control over who can impersonate the service account, aligning with the security policy to minimize service account key usage. B) Set up a workload identity pool with your corporate Active Directory Federation Service (ADFS). Let all principals in the pool impersonate the Google Cloud service account. - While this approach still uses ADFS as the identity provider, allowing all principals in the pool to impersonate the Google Cloud service account is risky from a security perspective. It doesn’t provide fine-grained control over which identities or groups can impersonate the service account. - This option is not ideal because ...

Author: Mia · Last updated Sep 25, 2026

After completing a security vulnerability assessment, you learned that cloud administrators leave Google Cloud CLI sessions open for days. You need to reduce the risk of attackers who might exploit these...

To address the issue of administrators leaving Google Cloud CLI sessions open for extended periods, you need to ensure that sessions expire automatically after a short, predefined time. This reduces the window of opportunity for potential attackers to exploit open sessions. Let's analyze the options: A) Set the session duration for the Google session control to one hour. - Session duration would determine how long a user can maintain an authenticated session without needing to re-authenticate. Setting this to one hour ensures that users are required to re-authenticate every hour, which is a good way to mitigate the risk of long-lived sessions. - This option is a solid choice because it directly addresses the issue of long-lived sessions by limiting how long a Google Cloud CLI session can remain active before requiring a new login. B) Set the reauthentication frequency for the Google Cloud Session Control to one hour. - Reauthentication frequency refers to how often users must re-authenticate during their session. This is similar to session duration but typically focuses on specific actions or intervals of activity. If you set the reauthentication frequency to one hour, the user would be prompted to authenticate again after one hour of activity. - This option is also viable, as it ensures users are prompted to re-authenticate periodically, but it is not necessarily the same as enforcing a session expiration after a set time. This is more of a continuous check rather than a session timeout. C) Set the organization policy constraint `constraints/iam.allowServiceAccountCredential...

Author: Oscar · Last updated Sep 25, 2026

You have numerous private virtual machines on Google Cloud. You occasionally need to manage the servers through Secure Socket Shell (SSH) from a remote location. You want to configure remote access to the...

To optimize security and cost efficiency when managing numerous private virtual machines (VMs) on Google Cloud, you need a solution that provides secure remote access while minimizing unnecessary exposure to the internet. Let's evaluate each option: A) Create a site-to-site VPN from your corporate network to Google Cloud. - A site-to-site VPN would establish a secure, persistent connection between your corporate network and Google Cloud. This would allow you to access your private VMs over a secure tunnel. While this is a good solution for secure access, it introduces additional complexity and cost due to the persistent VPN infrastructure and management overhead. - This option is viable for larger environments where continuous access is needed, but it might be overkill for scenarios where you only occasionally need to manage the VMs, and the cost of maintaining the VPN may not be justifiable. B) Configure server instances with public IP addresses. Create a firewall rule to only allow traffic from your corporate IPs. - Assigning public IPs to each VM creates a potential security risk by exposing the servers directly to the internet, even if you restrict traffic to only your corporate IPs. This still opens up the VMs to external threats and requires maintaining firewall rules. It's generally not a good security practice to expose private instances to the public internet. - This option is not recommended because while it’s cost-effective and simple, it compromises security by allowing public internet access, even with restricted IP addresses. C) Create a firewall rule to allow access from the Identity-Aware Proxy (IAP) IP range. Grant the role of an IAP-secured Tunnel User to the administrators. - Identity-Aware Proxy (IAP) is a Google Cloud service that provides secure access to applications and VMs withou...

Author: StarryEagle42 · Last updated Sep 25, 2026

Your organization's record data exists in Cloud Storage. You must retain all record data for at least seven years. Th...

To meet the requirement of retaining all record data for at least seven years with a permanent policy, it's essential to ensure the data cannot be modified or deleted within the retention period. Let’s analyze each option in detail: A) 1. Identify buckets with record data. 2. Apply a retention policy, and set it to retain for seven years. 3. Monitor the bucket by using log-based alerts to ensure that no modifications to the retention policy occur. - Retention policy can ensure that objects are not deleted within the retention period. However, this option relies on monitoring for any changes, which is reactive. Even with alerts, if someone modifies the retention policy, the data could still be at risk until the modification is detected and addressed. - This option is not ideal because it doesn't fully enforce protection against modifications to the retention policy, leaving a gap in ensuring the data is retained permanently. B) 1. Identify buckets with record data. 2. Apply a retention policy, and set it to retain for seven years. 3. Remove any Identity and Access Management (IAM) roles that contain the storage buckets update permission. - Removing IAM roles that allow updates to the buckets would limit who can modify the retention policy or delete objects, enhancing security. While this approach strengthens access control, it doesn’t prevent someone from modifying the retention policy through other means (e.g., API access or accidental role escalation). The key issue is that without more direct enforcement, there's still the possibility of unintentional or unauthorized changes. - This option is a step forward but still relies on a manual restriction of permissions, which isn't a foolproof method to prevent all possible changes. C) 1. Identify buckets with record data. 2. Enable the bucket policy only to ensure that data is ret...

Author: Ava · Last updated Sep 25, 2026

Your organization wants to protect all workloads that run on Compute Engine VM to ensure that the instances weren't compromised by boot-level or kernel-level malware. Also, you need to ensure that data in use on the VM cannot...

To address the need to protect Compute Engine VM workloads from boot-level or kernel-level malware and ensure that data in use on the VM cannot be accessed by the underlying host system, we need to focus on both hardware-based security and preventing data leakage. Let's evaluate each option based on the requirements: Option A: 1. Use Google Shielded VM including secure boot, Virtual Trusted Platform Module (vTPM), and integrity monitoring. 2. Create a Cloud Run function to check for the VM settings, generate metrics, and run the function regularly. - Google Shielded VM provides hardware-based protection that ensures that the VM's boot process is secure and cannot be tampered with, making it an excellent option for protecting against boot-level and kernel-level malware. vTPM adds hardware-backed security to protect the VM from unauthorized access, and integrity monitoring checks for signs of compromise, which directly addresses your requirement for boot-level and kernel-level security. - The second part of this option, creating a Cloud Run function, is not directly related to protecting against the described threats. It adds monitoring capabilities but doesn't directly address the data-in-use protection or the hardware-level isolation requirement. The use of Cloud Run functions is less efficient for this specific use case and adds unnecessary complexity. Reason for rejection: While Shielded VMs are a good choice, the addition of Cloud Run functions does not effectively contribute to the protection goals. Option B: 1. Activate Virtual Machine Threat Detection in Security Command Center (SCC) Premium. 2. Monitor the findings in SCC. - Virtual Machine Threat Detection can help detect and analyze threats on VMs, which is useful for identifying compromised workloads. However, this is more focused on post-compromise detection rather than prevention, and it doesn't offer the necessary protection at the boot or kernel level. - The approach here focuses on monitoring, which is reactive rather than proactive, and it doesn’t address the specific requirement of using a hardware-based solution to protect against kernel-level malware or data leakage from the underlying host system. Reason for rejection: This option focuses more on threat detection after a compromise has occurred, not on proactively preventing boot-level or kernel-level threats or securing data in u...

Author: Ethan · Last updated Sep 25, 2026

You are migrating your users to Google Cloud. There are cookie replay attacks with Google web and Google Cloud CLI SDK sessions on endpoint devices. You need to ...

To mitigate cookie replay attacks in Google Cloud and Google web/CLI SDK sessions, we need to focus on reducing the potential for session hijacking and enhancing the security of authentication mechanisms. Let’s evaluate each option: Option A: Configure Google session control to a shorter duration - Explanation: This option involves setting a shorter session duration, meaning that sessions will expire more quickly, limiting the window of opportunity for an attacker to hijack a session. This can help reduce the risk of replay attacks because once the session expires, the attacker will no longer be able to use the session. - Reason for selection: This is effective because reducing the lifetime of sessions means attackers have a smaller timeframe to exploit stolen cookies. - Scenario: Useful for environments where session security is critical, such as when sensitive data or critical infrastructure is accessed. Option B: Set an organizational policy for OAuth 2.0 access token with a shorter duration - Explanation: OAuth tokens are used for authentication in Google Cloud services, and reducing their expiration time limits the risk of replay attacks by shortening the validity of the token. A shorter duration ensures that any stolen token becomes useless relatively quickly. - Reason for selection: This helps reduce the time window for potential token replay attacks, aligning well with the goal of minimizing risk. - Scenario: Useful when managing OAuth tokens and looking to limit the risk of token reuse. Option C: Set a reauthentication policy for Google Cloud services to a shorter duration - Explanation: This option forces users to reauthenticate more frequently, potentially improving security by ensuring that even if an attacker compromises a session, they will have to continuously reauthenticate to maintain access. - Reason for rejection: While reauthentication policies are useful for some security contexts, they don’t directly address the cookie replay attack risk, which is more focused on session tokens and credentials being hijacked. - Scenario: This is more appr...

Author: StarryEagle42 · Last updated Sep 25, 2026

You manage a mission-critical workload for your organization, which is in a highly regulated industry. The workload uses Compute Engine VMs to analyze and process the sensitive data after it is uploaded to Cloud Storage from the endpoint computers. Your compliance team has detected that this workload does not meet the data protection requirements for sensitive data. You need to meet these requirements: * Manage the data encryption key (DEK) outside the Google Cloud boundary. * Maintain full control of encryption keys through a third-party provider. * Encrypt th...

To meet the data protection requirements for sensitive data while using Compute Engine VMs and Cloud Storage, the solution must address the following key objectives: 1. Manage the data encryption key (DEK) outside the Google Cloud boundary. 2. Maintain full control of encryption keys through a third-party provider. 3. Encrypt sensitive data before uploading to Cloud Storage. 4. Decrypt sensitive data during processing in Compute Engine VMs. 5. Encrypt sensitive data in memory while in use in Compute Engine VMs. Let's evaluate each option based on these requirements: Option A: Configure Customer Managed Encryption Keys (CMEK) to encrypt the sensitive data before it is uploaded to Cloud Storage, and decrypt the sensitive data after it is downloaded into your VMs. - Explanation: CMEK allows you to control the encryption keys used to protect your data in Cloud Storage. However, CMEK manages keys within Google Cloud, not outside the Google Cloud boundary, and does not fulfill the requirement of managing the DEK through a third-party provider. CMEK also does not encrypt the data in memory while in use, which is a critical requirement. - Reason for rejection: This option doesn't meet the key requirements for key management outside Google Cloud and for encrypting data in memory. Option B: Configure Cloud External Key Manager (Cloud EKM) to encrypt the sensitive data before it is uploaded to Cloud Storage, and decrypt the sensitive data after it is downloaded into your VMs. - Explanation: Cloud EKM allows you to manage encryption keys outside Google Cloud by integrating with a third-party key provider. It ensures that the data is encrypted before uploading to Cloud Storage and decrypted when it is downloaded into VMs. While it addresses key management outside Google Cloud, it doesn't address the need to encrypt the data in memory while in use on the VMs, which is a critical requirement. - Reason for rejection: This option does not fulfill the requirement of encrypting the sensitive data while it is in use in memory on the Compute Engine VMs. Option C: Create Confidential VMs to access the sensitive data. - Explanation: Confidential VMs are designed to protect...

Author: Elijah · Last updated Sep 25, 2026

Your organization wants to be General Data Protection Regulation (GDPR) compliant. You want to ensure that your DevOps teams can only create Googl...

To ensure your DevOps teams can only create Google Cloud resources in Europe regions, we need to focus on restricting resource creation at the organizational level, specifically in terms of location. Let's evaluate each option: Option A: Use Identity-Aware Proxy (IAP) with Access Context Manager to restrict the location of Google Cloud resources. - Explanation: Identity-Aware Proxy (IAP) is designed to secure access to applications running on Google Cloud. Access Context Manager (ACM) is used to manage access policies for resources based on attributes like the user, location, and device security. While this helps with access control, it doesn't directly restrict the location of resources (like VMs, storage buckets, etc.) at the infrastructure level. - Reason for rejection: IAP and ACM are not suited for restricting where resources can be provisioned. They are more focused on controlling access to services based on user attributes, not on enforcing region-specific resource creation. Option B: Use the org policy constraint 'Google Cloud Platform – Resource Location Restriction' on your Google Cloud organization node. - Explanation: The "Resource Location Restriction" org policy constraint is specifically designed to restrict the locations where Google Cloud resources can be created. By setting this policy at the organization node, you can enforce that resources can only be provisioned in specific geographic regions. This ensures compliance with GDPR by limiting the regions where data can be stored and processed. - Reason for selection: This option directly addresses the requirement of restricting resource creation to specific regions, in this case, Europe. It’s the most efficient way to enforce regi...

Author: Aditya · Last updated Sep 25, 2026

For data residency requirements, you want your secrets in Google Clouds Secret Manager to only have payloads in europe-west1 and europe-west4. Your secret...

To meet the data residency requirements and ensure that your secrets in Google Cloud's Secret Manager are stored only in the `europe-west1` and `europe-west4` regions, while also maintaining high availability across both regions, let's evaluate each option: Option A: Create your secret with a user-managed replication policy, and choose only compliant locations. - Explanation: The user-managed replication policy allows you to manually select specific regions for storing the secret payload. In this case, you can select only `europe-west1` and `europe-west4` as the compliant regions for replication, ensuring that the secret resides only in these locations. This ensures data residency compliance and can also allow for high availability if both regions are selected. - Reason for selection: This option allows for precise control over the secret’s location, ensuring that secrets are stored only in the required regions, while still maintaining high availability by replicating across both regions. Option B: Create your secret with an automatic replication policy, and choose only compliant locations. - Explanation: The automatic replication policy manages replication across multiple regions automatically. However, Secret Manager does not allow you to select specific regions for replication when using the automatic replication policy. It automatically replicates secrets across Google Cloud regions, but you can't limit it to specific regions like `europe-west1` and `europe-west4`. - Reason for rejection: Since automatic replication doesn't allow you to choose specific regions, you cannot guarantee that the secret will only reside in `europe-west1` and `europe-west4`, making it unsuitable for strict data residency requirements. Option C: Create two secrets by using Terraform, one in `europe-west1` and the other in `europe-west4`. - Explanation: This approach involves creating two separate secrets, one i...

Author: IceDragon2023 · Last updated Sep 25, 2026

You are migrating an application into the cloud. The application will need to read data from a Cloud Storage bucket. Due to local regulatory requirements, you need to hold the key material used for encryption fully under your...

When migrating an application to the cloud, and needing to ensure that the key material for encryption remains under your full control, the ideal solution should provide the necessary security features and meet regulatory requirements. Let's evaluate each option based on key factors: Option A: Encrypt the data in the Cloud Storage bucket by using Customer Managed Encryption Keys. Configure an IAM deny policy for unauthorized groups. - Pros: - Customer Managed Encryption Keys (CMEK) give you control over encryption keys stored in Google Cloud's Key Management Service (KMS). - You can control access by managing IAM policies, specifying which identities are allowed to access the keys. - Cons: - While this option allows control over keys, it doesn't fully satisfy the requirement of keeping the key material under your control if the key is stored in a cloud-based KMS. - The rationale for accessing the key would be handled by IAM policies and not a more detailed justification mechanism. Conclusion: This option does not meet the requirement of keeping the key material fully under your control, as the keys are still managed by Google Cloud's KMS, even though you control access via IAM policies. --- Option B: Generate a key in your on-premises environment to encrypt the data before you upload the data to the Cloud Storage bucket. Upload the key to the Cloud Key Management Service (KMS). Activate Key Access Justifications (KAJ) and have the external key system reject unauthorized accesses. - Pros: - This option allows you to control the key in your on-premises environment, ensuring that the key material is under your control before uploading the encrypted data. - Key Access Justifications (KAJ) provide a valid rationale for accessing the key material, meeting the regulatory requirement for key access justification. - Cons: - Uploading the key to KMS contradicts the requirement of keeping the key fully under your control, as KMS still handles key management. - This introduces potential risks related to key exposure, as once the key is in KMS, it’s managed by Google Cloud, even if you have KAJ configured. Conclusion: This approach ...

Author: Sofia · Last updated Sep 25, 2026

Your organization uses the top-tier folder to separate application environments (prod and dev). The developers need to see all application development audit logs, but they are not permitted to review production logs. Your security team can review all logs in production and development environments. You must grant Identity and Access ...

When considering the proper IAM roles for both developers and the security team, it’s important to ensure the principle of least privilege is followed while fulfilling the necessary access requirements. Let's review each option carefully to determine which meets the needs while also ensuring security: Option A: 1. Grant `logging.viewer` role to the security team at the organization resource level. 2. Grant `logging.viewer` role to the developer team at the folder resource level that contains all the dev projects. - Pros: - The `logging.viewer` role allows both the security team and the developers to view logs without modifying them, which fits the least privilege principle. - By granting the security team access at the organization level, they can view all logs in both production and development environments. - By granting the developers access at the folder level containing only the dev projects, you limit their access to only the development logs, adhering to the requirement that they should not see production logs. - Cons: - None significant; this option fits the need to segregate access between environments and still allows sufficient access for both teams. Conclusion: This is the most suitable option as it ensures that developers have access only to the logs from development environments, and the security team can review logs across both environments. --- Option B: 1. Grant `logging.viewer` role to the security team at the organization resource level. 2. Grant `logging.admin` role to the developer team at the organization resource level. - Pros: - The security team is granted the `logging.viewer` role at the organization level, which allows them to view all logs across both production and development environments. - The `logging.admin` role gives developers the ability to manage logs, which is too broad of a permission for this scenario. - Cons: - Developers should not have the `logging.admin` role in the organization as it provides far more privileges than they need (e.g., the ability to modify or delete logs). This violates the principle of least privilege and could expose the organization to unnecessary risk. Conclusion: This option is...

Author: Vivaan · Last updated Sep 25, 2026

What Our Friends Say

What Our Friends Say

Google Practice Questions, Discussions & Exam Topics by our Authors

Your company conducts clinical trials and needs to analyze the results of a recent study that are stored in BigQuery. The interval when the medicine was taken contains start and stop dates. The interval data is critical to the analysis, but specific dates may identify a particular batch and in...

You have a highly sensitive BigQuery workload that contains personally identifiable information (PII) that you want to ensure is not accessible from the internet. To prevent data exfiltration, only requests fro...

Your organization is moving virtual machines (VMs) to Google Cloud. You must ensure that operating system images that are used across your projects are t...

A service account key has been publicly exposed on multiple public code repositories. After reviewing the logs, you notice that the keys were used to generate short-lived credentials. You n...

A company is using Google Kubernetes Engine (GKE) with container images of a mission-critical application. The company wants to scan the images for known security issues and securely share the report wi...

Your application is deployed as a highly available, cross-region solution behind a global external HTTP(S) load balancer. You notice significant spikes in traffic from multiple IP addresses, but it is unknown whether the IPs are malicious. You are concerned about your applicat...

Your organization is using Active Directory and wants to configure Security Assertion Markup Language (SAML). You must set up and enforce...

Employees at your company use their personal computers to access your organization's Google Cloud console. You need to ensure that users can only access the Google Cloud console from their corporate-issued...

Your organization is rolling out a new continuous integration and delivery (CI/CD) process to deploy infrastructure and applications in Google Cloud. Many teams will use their own instances of the CI/CD workflow. It will run on Google Kubernetes Eng...

Your organization's Customers must scan and upload the contract and their driver license into a web portal in Cloud Storage. You must remove all personally identifiable information (PII) from files that are older than 12 mo...

You plan to synchronize identities to Cloud Identity from a third-party identity provider (IdP). You discovered that some employees used their corporate email address to set up consumer accounts to access Google services. You need to ensure that the organization has con...

You are auditing all your Google Cloud resources in the production project. You want to identify all principals who...

Your organization previously stored files in Cloud Storage by using Google Managed Encryption Keys (GMEK), but has recently updated the internal policy to require Customer Managed Encryption Keys (CMEK). You nee...

You run applications on Cloud Run. You already enabled container analysis for vulnerability scanning. However, you are concerned about the lack of control on the applications that are deployed. You must ensure that ...

Your organization has on-premises hosts that need to access Google Cloud APIs. You must enforce private connectivity between these hosts, minimize cost...

As part of your organization's zero trust strategy, you use Identity-Aware Proxy (IAP) to protect multiple applications. You need to ingest logs into a Security Information and Event Management (SIEM) s...

Your company must follow industry specific regulations. Therefore, you need to enforce customer-managed encryption keys (CMEK) for all new Cloud Storage resource...

Your company's Google Cloud organization has about 200 projects and 1,500 virtual machines. There is no uniform strategy for logs and events management, which reduces visibility for your security operations team. You need to design a logs management solution that...

Your organization must comply with the regulation to keep instance logging data within Europe. Your workloads will be hosted in the Netherlands in region europe-west4 in a new project. You mu...

You are using Security Command Center (SCC) to protect your workloads and receive alerts for suspected security breaches at your company. You need to detect ...

You manage a BigQuery analytical data warehouse in your organization. You want to keep data for all your customers in a common table while you also restrict query access based on rows and columns permiss...

Your organization recently activated the Security Command Center (SCC) standard tier. There are a few Cloud Storage buckets that were accidentally made accessible to the public. You need t...

Your organization is transitioning to Google Cloud. You want to ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters in a project. The containers must be deployed from a centrally m...

Your company uses Google Cloud and has publicly exposed network assets. You want to discover the assets and perform a security audit on these assets by using...

Your organization wants to be compliant with the General Data Protection Regulation (GDPR) on Google Cloud. You must implement data residency and opera...

Your company is moving to Google Cloud. You plan to sync your users first by using Google Cloud Directory Sync (GCDS). Some employees have already created Google Cloud accounts by using their company email addresses that we...

Your organization is using GitHub Actions as a continuous integration and delivery (CI/CD) platform. You must enable access to Google Cloud resources from...

Your organization processes sensitive health information. You want to ensure that data is encrypted while in use by the virtual machines (VMs). You must create a policy...

Your organization wants to be continuously evaluated against CIS Google Cloud Computing Foundations Benchmark v1.3.0 (CIS Google Cloud Foundation 1.3). Some of the controls are irrelevant to your organization and must be disregarded in evaluation. You need to cre...

You are routing all your internet facing traffic from Google Cloud through your on-premises internet connection. You want to accomplish this goal secure...

Your organization uses Google Workspace Enterprise Edition for authentication. You are concerned about employees leaving their laptops unattended for extended periods of time after authenticating into Google Cloud. You must prevent maliciou...

You define central security controls in your Google Cloud environment. For one of the folders in your organization, you set an organizational policy to deny the assignment of external IP addresses to VMs. Two days later, you receive an al...

Your company recently published a security policy to minimize the usage of service account keys. On-premises Windows-based applications are interacting with Google Cloud APIs. You need to implement Workload ...

After completing a security vulnerability assessment, you learned that cloud administrators leave Google Cloud CLI sessions open for days. You need to reduce the risk of attackers who might exploit these...

You have numerous private virtual machines on Google Cloud. You occasionally need to manage the servers through Secure Socket Shell (SSH) from a remote location. You want to configure remote access to the...

Your organization's record data exists in Cloud Storage. You must retain all record data for at least seven years. Th...

Your organization wants to protect all workloads that run on Compute Engine VM to ensure that the instances weren't compromised by boot-level or kernel-level malware. Also, you need to ensure that data in use on the VM cannot...

You are migrating your users to Google Cloud. There are cookie replay attacks with Google web and Google Cloud CLI SDK sessions on endpoint devices. You need to ...

Your organization wants to be General Data Protection Regulation (GDPR) compliant. You want to ensure that your DevOps teams can only create Googl...

For data residency requirements, you want your secrets in Google Clouds Secret Manager to only have payloads in europe-west1 and europe-west4. Your secret...

You are migrating an application into the cloud. The application will need to read data from a Cloud Storage bucket. Due to local regulatory requirements, you need to hold the key material used for encryption fully under your...