Google Google Cloud Architect Professional Exam Prep
Google Cloud Certified - Professional Cloud Architect (Page 17 )

Updated On: 31-Aug-2026

Your company pushes batches of sensitive transaction data from its application server VMs to Cloud Pub/Sub for processing and storage.
What is the Google- recommended way for your application to authenticate to the required Google Cloud services?

  1. Ensure that VM service accounts are granted the appropriate Cloud Pub/Sub IAM roles.
  2. Ensure that VM service accounts do not have access to Cloud Pub/Sub, and use VM access scopes to grant the appropriate Cloud Pub/Sub IAM roles.
  3. Generate an OAuth2 access token for accessing Cloud Pub/Sub, encrypt it, and store it in Cloud Storage for access from each VM.
  4. Create a gateway to Cloud Pub/Sub using a Cloud Function, and grant the Cloud Function service account the appropriate Cloud Pub/Sub IAM roles.

Answer(s): A

Explanation:

The correct answer is A: "Ensure that VM service accounts are granted the appropriate Cloud Pub/Sub IAM roles." This approach aligns with Google's best practices for secure and manageable authentication within Google Cloud Platform (GCP). Service accounts are a special type of Google account intended to be used by applications and virtual machines, not by individual users.
When an application runs on a Compute Engine VM, it can utilize the VM's associated service account to authenticate with other Google Cloud services. Assigning the necessary IAM roles directly to the VM's service account grants the required permissions to access Cloud Pub/Sub. This method minimizes the risk of exposing credentials, simplifies access management and leverages Google's built-in identity and access management framework. Other options like using access scopes are outdated and have security disadvantages. Manually handling OAuth tokens is error-prone and can easily introduce security vulnerabilities, such as accidental exposure of credentials. Similarly, creating a gateway using a Cloud Function adds unnecessary complexity and latency. Using the VM's service account promotes least privilege principles, as the service account can be granted specific Cloud Pub/Sub roles and no others. This ensures that only the intended application has the permission to perform the necessary Pub/Sub operations.
Here are some authoritative links for further research:
Service Accounts: https://cloud.google.com/iam/docs/service-accounts IAM Roles: https://cloud.google.com/iam/docs/understanding-roles Compute Engine Service Accounts: https://cloud.google.com/compute/docs/access/service-accounts Best practices for service accounts: https://cloud.google.com/iam/docs/best-practices-service-accounts



You want to establish a Compute Engine application in a single VPC across two regions. The application must communicate over VPN to an on-premises network. How should you deploy the VPN?

  1. Use VPC Network Peering between the VPC and the on-premises network.
  2. Expose the VPC to the on-premises network using IAM and VPC Sharing.
  3. Create a global Cloud VPN Gateway with VPN tunnels from each region to the on-premises peer gateway.
  4. Deploy Cloud VPN Gateway in each region. Ensure that each region has at least one VPN tunnel to the on-premises peer gateway.

Answer(s): D

Explanation:

The correct answer is D. Deploy Cloud VPN Gateway in each region. Ensure that each region has at least one VPN tunnel to the on-premises peer gateway. Here's why:
The scenario requires connecting a Compute Engine application spanning two regions within a single VPC to an on-premises network via VPN. Option D addresses this requirement by establishing separate Cloud VPN gateways within each region. This ensures high availability and redundancy. If a VPN gateway in one region fails, the application in the other region can still communicate with the on-premises network through its own VPN tunnel. Option A (VPC Network Peering) is unsuitable for connecting to on-premises environments as it's designed for inter-VPC communication within Google Cloud. Option B (IAM and VPC Sharing) is for sharing VPC resources within your Google Cloud organization and not for connecting to external networks. Option C (global Cloud VPN Gateway) does not provide zonal redundancy, meaning if the single global gateway fails, both regions will lose connectivity. By deploying regional VPN gateways, each region maintains an independent connection to the on-premises network. This approach leverages the inherent fault-tolerance of regional resources in Google Cloud. For further information, refer to the Google Cloud documentation on Cloud VPN https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview and choosing the right type of connectivity https://cloud.google.com/architecture/choose-your-cloud-connectivity . Regional gateways enable optimal traffic routing and network performance. Utilizing regional gateways also improves resource management by confining the VPN connections to the specific regions where needed.



Your applications will be writing their logs to BigQuery for analysis. Each application should have its own table. Any logs older than 45 days should be removed. You want to optimize storage and follow Google-recommended practices.
What should you do?

  1. Configure the expiration time for your tables at 45 days
  2. Make the tables time-partitioned, and configure the partition expiration at 45 days
  3. Rely on BigQuery's default behavior to prune application logs older than 45 days
  4. Create a script that uses the BigQuery command line tool (bq) to remove records older than 45 days

Answer(s): B

Explanation:

Option B, making the tables time-partitioned with a 45-day partition expiration, is the correct approach. Time-partitioning in BigQuery divides tables into segments based on a time-related column, enhancing query performance and manageability. Setting a partition expiration policy automatically removes partitions older than 45 days, directly addressing the requirement to remove old logs. This method optimizes storage costs by only keeping necessary data and aligns with Google's best practices for BigQuery. Option A, setting a table expiration, would delete the entire table after 45 days, losing all newer logs. Relying on default behavior (Option C) doesn't provide the required data removal. Creating a custom script (Option D) adds unnecessary complexity and maintenance overhead compared to the built-in partitioning feature. Time-partitioning efficiently handles large datasets, allowing for quicker scans by focusing on relevant partitions, further boosting query efficiency. Google Cloud documentation strongly recommends time-partitioning for data with a time component.
Relevant links:
BigQuery Partitioned Tables BigQuery Partition Expiration Best practices for using BigQuery



You want your Google Kubernetes Engine cluster to automatically add or remove nodes based on CPU load.
What should you do?

  1. Configure a HorizontalPodAutoscaler with a target CPU usage. Enable the Cluster Autoscaler from the GCP Console.
  2. Configure a HorizontalPodAutoscaler with a target CPU usage. Enable autoscaling on the managed instance group for the cluster using the gcloud command.
  3. Create a deployment and set the maxUnavailable and maxSurge properties. Enable the Cluster Autoscaler using the gcloud command.
  4. Create a deployment and set the maxUnavailable and maxSurge properties. Enable autoscaling on the cluster managed instance group from the GCP Console.

Answer(s): A

Explanation:

The correct answer is A because it combines two crucial components for achieving CPU-based autoscaling in Google Kubernetes Engine (GKE). First, the Horizontal Pod Autoscaler (HPA) is essential for scaling the number of pods within your deployment based on observed CPU usage. It monitors the CPU utilization of your pods and automatically adjusts the number of replicas to meet the desired target. This ensures that your application can handle fluctuating workloads. Second, the Cluster Autoscaler is required to dynamically scale the number of nodes in your GKE cluster. It monitors resource requests from pods (including those managed by the HPA).
When it detects pending pods due to insufficient node resources, it adds nodes to the cluster. Conversely, it removes nodes when they are underutilized. By combining HPA (pod scaling) and Cluster Autoscaler (node scaling), the system can adjust the infrastructure to match the application's needs, ensuring efficient resource utilization. Option B incorrectly suggests using the managed instance group's autoscaling directly, which doesn't integrate as effectively with Kubernetes pod resource requirements and HPA metrics. Options C and D focus on deployment update parameters rather than the core autoscaling mechanisms and also suggest utilizing Gcloud CLI for Cluster Autoscaler, which can also be enabled via Google Cloud Console.
Authoritative Links:
Kubernetes Horizontal Pod Autoscaler (HPA): https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ GKE Cluster Autoscaler: https://cloud.google.com/kubernetes-engine/docs/how-to/autoscaling-nodes GKE Autoscaling Overview: https://cloud.google.com/kubernetes-engine/docs/concepts/autoscaling



You need to develop procedures to verify resilience of disaster recovery for remote recovery using GCP. Your production environment is hosted on-premises. You need to establish a secure, redundant connection between your on-premises network and the GCP network.
What should you do?

  1. Verify that Dedicated Interconnect can replicate files to GCP. Verify that direct peering can establish a secure connection between your networks if Dedicated Interconnect fails.
  2. Verify that Dedicated Interconnect can replicate files to GCP. Verify that Cloud VPN can establish a secure connection between your networks if Dedicated Interconnect fails.
  3. Verify that the Transfer Appliance can replicate files to GCP. Verify that direct peering can establish a secure connection between your networks if the Transfer Appliance fails.
  4. Verify that the Transfer Appliance can replicate files to GCP. Verify that Cloud VPN can establish a secure connection between your networks if the Transfer Appliance fails.

Answer(s): B

Explanation:

The correct answer is B . Here's a detailed justification:
Why B is the correct choice:
Dedicated Interconnect for Primary Connection: Dedicated Interconnect provides a high-bandwidth, low-latency, and secure private connection between on-premises and Google Cloud. This makes it ideal for replicating large volumes of data, such as those required for disaster recovery, and is a best practice for production environments. It establishes a direct physical connection, ensuring performance and reliability. Cloud VPN for Backup Connection: In case Dedicated Interconnect fails, a backup connectivity option is crucial. Cloud VPN offers a secure, IPsec-based connection over the public internet.
While not as high-performance as Dedicated Interconnect, it serves as an effective redundant path, maintaining connection for replication during a failure. VPN establishes an encrypted connection for secure data transfer during a DR failover scenario. Resilience and Redundancy: Using both Dedicated Interconnect and Cloud VPN together provides a robust architecture for disaster recovery replication. Dedicated Interconnect acts as the primary, reliable connection, while Cloud VPN stands ready to take over if necessary, ensuring business continuity. File Replication: Neither solution is directly intended for file replication; rather, they enable secure, resilient connectivity for data transfer from on-premises to GCP. The actual replication is performed by specific services that operate on top of these connections.
Why other options are incorrect:
A - Direct Peering: Direct peering is primarily used to exchange internet traffic with Google, not for establishing private connections between on-premises and GCP for data replication. It does not provide the same level of private, reliable connectivity as Dedicated Interconnect. C & D - Transfer Appliance: Transfer Appliance is a physical device used for transferring massive amounts of data to Google Cloud via shipment. It's not intended for continuous, automated replication for disaster recovery purposes. Moreover, it is a one time process for bulk data transfer and not for continual replication purposes. It cannot be used as a primary or redundant option for continuous replication.
Cloud Computing Concepts:
Hybrid Cloud: This scenario demonstrates a hybrid cloud architecture where resources are distributed between on-premises and a public cloud (GCP). Disaster Recovery (DR): The focus is on establishing procedures to maintain business operations during disruptive events, including having alternate resources to failover. Network Connectivity: The need for secure, reliable, and redundant connectivity between on-premises and GCP is paramount for DR. Redundancy: Having backup solutions like the Cloud VPN is essential for maintaining connectivity during failures of the primary path.
Authoritative Links for Further Research:
Dedicated Interconnect: https://cloud.google.com/network-connectivity/docs/interconnect/concepts/dedicated-interconnect Cloud VPN: https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview Direct Peering: https://cloud.google.com/network-connectivity/docs/peering/direct-peering Transfer Appliance: https://cloud.google.com/transfer-appliance
In summary, using Dedicated Interconnect for primary connectivity and Cloud VPN for a backup option offers a resilient and secure solution for replicating data to Google Cloud for disaster recovery purposes.



Viewing page 17 of 98
Viewing questions 81 - 85 out of 480 questions


Post your Comments and Discuss Google Google Cloud Architect Professional exam prep with other Community members:

AI Tutor AI Tutor 👋 I’m here to help!