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

Updated On: 31-Aug-2026

Your company is running a stateless application on a Compute Engine instance. The application is used heavily during regular business hours and lightly outside of business hours. Users are reporting that the application is slow during peak hours. You need to optimize the application's performance.
What should you do?

  1. Create a snapshot of the existing disk. Create an instance template from the snapshot. Create an autoscaled managed instance group from the instance template.
  2. Create a snapshot of the existing disk. Create a custom image from the snapshot. Create an autoscaled managed instance group from the custom image.
  3. Create a custom image from the existing disk. Create an instance template from the custom image. Create an autoscaled managed instance group from the instance template.
  4. Create an instance template from the existing disk. Create a custom image from the instance template. Create an autoscaled managed instance group from the custom image.

Answer(s): C

Explanation:

The correct answer is C . Here's a detailed justification:
The problem describes a stateless application on a Compute Engine instance experiencing performance issues during peak hours. The key to solving this is to implement autoscaling, which dynamically adjusts the number of running instances based on demand. This ensures that more resources are available during peak hours and fewer during off-peak hours, optimizing both performance and cost.
To implement autoscaling, we need to create a managed instance group (MIG). A MIG manages multiple identical VM instances. These instances must be created from a consistent configuration, which is best achieved using an instance template. An instance template defines the VM's machine type, boot disk, network configurations, and other specifications.
The existing application's configuration is on the current VM's disk. To replicate this for multiple instances, we need to capture that disk configuration. The most efficient way to do this is by creating a custom image, which is a reusable representation of a VM's boot disk. Unlike a snapshot, which is a point-in-time backup, a custom image is ready to be used to create new VMs. The custom image will contain the operating system and all the installed applications.
Therefore, the correct sequence of actions is:
1. Create a custom image from the existing disk. This ensures we have a reusable image containing the application setup. 2. Create an instance template from the custom image. The template allows consistent configuration of the VMs in the MIG. 3. Create an autoscaled managed instance group using the instance template. This group automatically scales the number of VMs according to defined rules (e.g., CPU utilization), ensuring optimal performance during peak hours.
Options A, B, and D are incorrect because they either utilize a snapshot instead of a custom image (which isn't efficient for VM creation) or reverse the sequence of custom image creation and template creation, rendering the process inefficient or ineffective. Option A uses a snapshot which is suitable for backup and restore operations, not for creating new VMs. Option D attempts to create a custom image after an instance template which defeats the purpose of the template (to capture a custom config) and is a fundamentally incorrect approach.
Authoritative Links for Further Research:
Creating custom images: https://cloud.google.com/compute/docs/images/create-custom Instance templates: https://cloud.google.com/compute/docs/instance-templates Managed instance groups: https://cloud.google.com/compute/docs/instance-groups Autoscaling: https://cloud.google.com/compute/docs/autoscaling



Your web application has several VM instances running within a VPC. You want to restrict communications between instances to only the paths and ports you authorize, but you don't want to rely on static IP addresses or subnets because the app can autoscale. How should you restrict communications?

  1. Use separate VPCs to restrict traffic
  2. Use firewall rules based on network tags attached to the compute instances
  3. Use Cloud DNS and only allow connections from authorized hostnames
  4. Use service accounts and configure the web application to authorize particular service accounts to have access

Answer(s): B

Explanation:

The correct answer is B. Use firewall rules based on network tags attached to the compute instances.
Here's why:
Network tags provide a flexible and dynamic way to manage firewall rules in Google Cloud Platform (GCP). Unlike static IP addresses or subnets, tags are applied directly to VM instances, allowing firewall rules to apply to groups of instances regardless of their IP address or subnet.
When your application autoscales, new instances automatically inherit the tags from the instance template, and consequently, the corresponding firewall rules apply to them without manual intervention. This ensures consistent security policies are maintained even as your environment grows or shrinks.
Using separate VPCs (option A) is an unnecessarily complex solution for restricting intra-VPC traffic.
While VPCs offer isolation, they are not needed for simply controlling traffic between VMs within the same network. Cloud DNS (option C) manages hostname resolution, not firewall access. It's irrelevant to restricting communication between instances based on their characteristics. Similarly, service accounts (option D) control identity and access to GCP services, not intra-VPC network traffic. They are for authorization to resources, not connections between instances. Firewall rules based on network tags are precisely designed to filter network traffic based on tagged instances. This ensures that only authorized communication occurs as the rules are evaluated based on the tags the VMs have.
Further reading:
Google Cloud VPC Firewall Rules : https://cloud.google.com/vpc/docs/firewalls Google Cloud Network Tags: https://cloud.google.com/vpc/docs/add-remove-network-tags



You are using Cloud SQL as the database backend for a large CRM deployment. You want to scale as usage increases and ensure that you don't run out of storage, maintain 75% CPU usage cores, and keep replication lag below 60 seconds.
What are the correct steps to meet your requirements?

  1. 1. Enable automatic storage increase for the instance. 2. Create a Stackdriver alert when CPU usage exceeds 75%, and change the instance type to reduce CPU usage. 3. Create a Stackdriver alert for replication lag, and shard the database to reduce replication time.
  2. 1. Enable automatic storage increase for the instance. 2. Change the instance type to a 32-core machine type to keep CPU usage below 75%. 3. Create a Stackdriver alert for replication lag, and deploy memcache to reduce load on the master.
  3. 1. Create a Stackdriver alert when storage exceeds 75%, and increase the available storage on the instance to create more space. 2. Deploy memcached to reduce CPU load. 3. Change the instance type to a 32-core machine type to reduce replication lag.
  4. 1. Create a Stackdriver alert when storage exceeds 75%, and increase the available storage on the instance to create more space. 2. Deploy memcached to reduce CPU load. 3. Create a Stackdriver alert for replication lag, and change the instance type to a 32-core machine type to reduce replication lag.

Answer(s): A

Explanation:

Here's a detailed justification for why option A is the correct approach:
Option A correctly addresses all requirements for scaling, storage management, CPU utilization, and replication lag for Cloud SQL. Enabling automatic storage increase (1) ensures that the database won't run out of space as data grows. This proactive approach prevents application downtime due to storage limitations. Creating a Stackdriver alert for CPU usage exceeding 75% (2), and then scaling the instance to reduce CPU load ensures that the database operates within the desired parameters and handles increasing workloads. This keeps the performance consistent. Finally, creating an alert for replication lag and employing sharding (3) is the appropriate strategy to keep latency under 60 seconds. Sharding partitions the database, distributing the load across multiple instances, which accelerates replication and reduces lag.
Option B suggests upgrading to a 32-core instance to handle CPU usage. This can be wasteful if not necessary and should only be considered after monitoring via Stackdriver alerts. It also recommends memcache for replication lag which does not impact the lag in replication, its more of a query optimisation tool. Option C focuses on storage exceeding 75%, which is too late to alert when the aim is not to run out of storage. It also suggests using memcached for CPU, this is more for query caching and not core CPU load reduction. Finally option D has similar flaws to C and suggests changing instance type to reduce replication lag which is not how replication lag works. It must be managed through database sharding to reduce replication load.
In essence, Option A uses proactive monitoring (Stackdriver alerts), responsive scaling (automatic storage increase and instance type changes), and sharding, to ensure the Cloud SQL database remains performant and reliable under increasing loads.
Authoritative Links:
Cloud SQL Automatic Storage Increase: https://cloud.google.com/sql/docs/mysql/manage-storage Stackdriver Monitoring: https://cloud.google.com/monitoring/ Cloud SQL Replication: https://cloud.google.com/sql/docs/mysql/replication/about-replication Database Sharding: https://cloud.google.com/architecture/database-sharding-strategies



You are tasked with building an online analytical processing (OLAP) marketing analytics and reporting tool. This requires a relational database that can operate on hundreds of terabytes of data.
What is the Google-recommended tool for such applications?

  1. Cloud Spanner, because it is globally distributed
  2. Cloud SQL, because it is a fully managed relational database
  3. Cloud Firestore, because it offers real-time synchronization across devices
  4. BigQuery, because it is designed for large-scale processing of tabular data

Answer(s): D

Explanation:

The correct answer is D. BigQuery because it is specifically designed for large-scale processing of tabular data, making it ideal for OLAP workloads. OLAP systems analyze large datasets for business intelligence, requiring fast querying and aggregation capabilities, which BigQuery excels at. Unlike traditional relational databases, BigQuery is a fully-managed, serverless data warehouse that scales automatically and provides optimized columnar storage for analytical queries. This columnar storage allows for efficient retrieval of specific columns of data required for analytical computations, significantly improving query performance.
Cloud Spanner (A) is a globally distributed database suitable for transactional applications with strong consistency requirements but is not optimized for large-scale analytical processing like BigQuery. Cloud SQL (B) is a managed relational database but is typically used for OLTP (Online Transaction Processing) workloads rather than OLAP, and it might struggle with hundreds of terabytes of data. Cloud Firestore (C) is a NoSQL document database mainly designed for mobile and web applications requiring real-time synchronization, not for analytical processing.
BigQuery's built-in features like SQL support, serverless architecture, and its integration with other Google Cloud services make it a perfect fit for creating an OLAP marketing analytics and reporting tool handling hundreds of terabytes of data. Its powerful query engine efficiently processes massive datasets, providing near real-time results for data analysis.
Authoritative Links:
Google Cloud BigQuery Overview: https://cloud.google.com/bigquery/docs/introduction BigQuery for Data Warehousing: https://cloud.google.com/architecture/data-warehouse Understanding OLAP: https://en.wikipedia.org/wiki/Online_analytical_processing



You have deployed an application to Google Kubernetes Engine (GKE), and are using the Cloud SQL proxy container to make the Cloud SQL database available to the services running on Kubernetes. You are notified that the application is reporting database connection issues. Your company policies require a post- mortem.
What should you do?

  1. Use gcloud sql instances restart.
  2. Validate that the Service Account used by the Cloud SQL proxy container still has the Cloud Build Editor role.
  3. In the GCP Console, navigate to Stackdriver Logging. Consult logs for (GKE) and Cloud SQL.
  4. In the GCP Console, navigate to Cloud SQL. Restore the latest backup. Use kubectl to restart all pods.

Answer(s): C

Explanation:

The correct answer is C. In the GCP Console, navigate to Stackdriver Logging. Consult logs for (GKE) and Cloud SQL. Here's why:
When troubleshooting application issues involving a Cloud SQL database accessed via the Cloud SQL proxy in GKE, the first step should always be examining logs. Stackdriver Logging (now part of Google Cloud Logging) consolidates logs from various GCP services, including GKE and Cloud SQL. This allows you to identify the root cause of the database connection issues. GKE logs will reveal potential problems with the application pods or the Cloud SQL proxy itself, such as container crashes, configuration errors, or failed connection attempts. Cloud SQL logs will show if there are any issues within the database instance, such as connection limits, slow queries, or errors during authentication. Examining these logs together provides a holistic view of the situation, enabling quick diagnosis of the issue. Options A, B, and D are more reactive steps and may be premature without identifying the root cause through logging analysis. Restarting the instance (A), is a troubleshooting step that should be taken once the issue has been identified by logs analysis. Checking the Service Account (B) is important for permissions, but this isn't the correct first step. Similarly, restoring a backup (D) is a last resort, and should only be done if data corruption is identified as the root cause. Prioritize log analysis with Stackdriver (C) for efficient and effective troubleshooting.
Authoritative Links:
Google Cloud Logging Documentation: https://cloud.google.com/logging/docs Cloud SQL Proxy Documentation: https://cloud.google.com/sql/docs/mysql/sql-proxy GKE Logging: https://cloud.google.com/kubernetes-engine/docs/how-to/logging



Viewing page 16 of 98
Viewing questions 76 - 80 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!