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

Updated On: 31-Aug-2026

Your customer wants to capture multiple GBs of aggregate real-time key performance indicators (KPIs) from their game servers running on Google Cloud Platform and monitor the KPIs with low latency. How should they capture the KPIs?

  1. Store time-series data from the game servers in Google Bigtable, and view it using Google Data Studio.
  2. Output custom metrics to Stackdriver from the game servers, and create a Dashboard in Stackdriver Monitoring Console to view them.
  3. Schedule BigQuery load jobs to ingest analytics files uploaded to Cloud Storage every ten minutes, and visualize the results in Google Data Studio.
  4. Insert the KPIs into Cloud Datastore entities, and run ad hoc analysis and visualizations of them in Cloud Datalab.

Answer(s): B

Explanation:

Option B, outputting custom metrics to Stackdriver, is the most appropriate solution for capturing and monitoring real-time KPIs with low latency. Stackdriver (now part of Google Cloud Observability) is designed for handling time-series data like metrics. Game servers can directly push these custom metrics to Stackdriver. Stackdriver Monitoring then offers robust visualization tools through its console dashboards,
enabling immediate monitoring of the KPIs. This approach provides the required real-time visibility with minimal latency, as the data is directly streamed and available for viewing quickly. Options A, C, and D involve batch processing or storage solutions less suited for real-time monitoring. Bigtable, while fast, is primarily a storage database, requiring additional querying and visualization steps. BigQuery and Cloud Storage rely on batch ingestions which incur delays in availability. Cloud Datastore is also unsuitable for time-series data and real-time analytics. The direct metric push from game servers to Stackdriver, coupled with its built-in monitoring tools, makes option B the superior choice for low-latency KPI visualization.
Further research:
Google Cloud Observability: https://cloud.google.com/stackdriver Custom Metrics in Cloud Monitoring: https://cloud.google.com/monitoring/custom-metrics Dashboards in Cloud Monitoring: https://cloud.google.com/monitoring/dashboards



You have a Python web application with many dependencies that requires 0.1 CPU cores and 128 MB of memory to operate in production. You want to monitor and maximize machine utilization. You also want to reliably deploy new versions of the application.
Which set of steps should you take?

  1. Perform the following: 1. Create a managed instance group with f1-micro type machines. 2. Use a startup script to clone the repository, check out the production branch, install the dependencies, and start the Python app. 3. Restart the instances to automatically deploy new production releases.
  2. Perform the following: 1. Create a managed instance group with n1-standard-1 type machines. 2. Build a Compute Engine image from the production branch that contains all of the dependencies and automatically starts the Python app. 3. Rebuild the Compute Engine image, and update the instance template to deploy new production releases.
  3. Perform the following: 1. Create a Google Kubernetes Engine (GKE) cluster with n1-standard-1 type machines. 2. Build a Docker image from the production branch with all of the dependencies, and tag it with the version number. 3. Create a Kubernetes Deployment with the imagePullPolicy set to 'IfNotPresent' in the staging namespace, and then promote it to the production namespace after testing.
  4. Perform the following: 1. Create a GKE cluster with n1-standard-4 type machines. 2. Build a Docker image from the master branch with all of the dependencies, and tag it with 'latest'. 3. Create a Kubernetes Deployment in the default namespace with the imagePullPolicy set to 'Always'. Restart the pods to automatically deploy new production releases.

Answer(s): C

Explanation:

The correct answer is C because it leverages containerization and Kubernetes for efficient resource utilization, deployment, and scaling. Option A, while using managed instance groups, suffers from a lack of automation in deployment and does not promote optimal resource utilization with f1-micro instance types,
which would be underutilized given the application's needs. Option B creates a custom Compute Engine image, which is less flexible and requires rebuilding the entire image for each deployment, hindering quick iterations. Option D uses a n1-standard-4 machine type, which is too large for the application's requirements,
leading to wasted resources, and using the "latest" tag for Docker images can lead to unpredictable deployments.
Option C's approach of using a Google Kubernetes Engine (GKE) cluster with n1-standard-1 machines allows for fine-grained resource allocation. Kubernetes enables the application to run in a containerized environment, ensuring portability and isolation. Building a Docker image with the version number facilitates easy rollback. The IfNotPresent policy for pulling images improves deployment speed and is consistent with best practices for a staging environment. Promoting the deployed image to production after testing is critical for stable releases. Kubernetes provides mechanisms for automatic scaling based on CPU usage and memory, promoting maximized utilization. Furthermore, Kubernetes’ deployment features, such as rolling updates, significantly improve application availability during updates. This combination of containerization, Kubernetes, and controlled deployments provides a robust and scalable solution.
Supporting links:
Google Kubernetes Engine (GKE): https://cloud.google.com/kubernetes-engine Docker: https://www.docker.com/ Kubernetes Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ ImagePullPolicy: https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy Containerization: https://www.redhat.com/en/topics/containers/what-is-containerization



Your company wants to start using Google Cloud resources but wants to retain their on-premises Active Directory domain controller for identity management.
What should you do?

  1. Use the Admin Directory API to authenticate against the Active Directory domain controller.
  2. Use Google Cloud Directory Sync to synchronize Active Directory usernames with cloud identities and configure SAML SSO.
  3. Use Cloud Identity-Aware Proxy configured to use the on-premises Active Directory domain controller as an identity provider.
  4. Use Compute Engine to create an Active Directory (AD) domain controller that is a replica of the on-premises AD domain controller using Google Cloud Directory Sync.

Answer(s): B

Explanation:

The correct answer is B. Use Google Cloud Directory Sync to synchronize Active Directory usernames with cloud identities and configure SAML SSO.
Here's why:
Centralized Identity Management: The core requirement is to leverage the existing on-premises Active Directory (AD) for identity management while adopting Google Cloud. Maintaining a single source of truth for user identities is crucial for consistency and security. Google Cloud Directory Sync (GCDS): GCDS is specifically designed to synchronize user and group data from on-premises directories (like AD) to Google Cloud Identity. This allows users to access Google Cloud resources with their existing AD credentials. Synchronization, Not Authentication: GCDS synchronizes identities but doesn't directly authenticate against the on-premises AD during user login to Google Cloud. It creates corresponding Google Cloud identities tied to the AD users. SAML SSO for Authentication: After synchronization, configuring Security Assertion Markup Language (SAML) Single Sign-On (SSO) is essential. SAML SSO redirects authentication requests to the on-premises AD, allowing users to authenticate using their AD credentials when accessing Google Cloud services. This ensures that authentication remains tied to the existing AD domain.
Why other options are not suitable:

A: Admin Directory API: While the Admin Directory API allows managing Google Cloud users, it doesn't inherently bridge the gap with on-premises Active Directory for direct authentication.
C: Cloud Identity-Aware Proxy (IAP): IAP is primarily for controlling access to applications based on user identity, not for direct user authentication against an on-premises domain controller.
While it can utilize external identity providers, it does not perform identity synchronization. D. Creating an AD Replica on Compute Engine: This adds unnecessary complexity and overhead. It requires managing a second AD domain controller in the cloud and may not provide optimal cost savings when identity federation via GCDS and SAML SSO is a viable alternative.
In summary, GCDS synchronizes AD identities to Google Cloud and SAML SSO delegates authentication to your existing on-premises AD, meeting the company's requirements efficiently.
Authoritative Links:
Google Cloud Directory Sync Documentation: https://support.google.com/a/answer/1069323?hl=en SAML SSO with Google Cloud: https://cloud.google.com/identity/docs/how-to/saml



You are running a cluster on Kubernetes Engine (GKE) to serve a web application. Users are reporting that a specific part of the application is not responding anymore. You notice that all pods of your deployment keep restarting after 2 seconds. The application writes logs to standard output. You want to inspect the logs to find the cause of the issue.
Which approach can you take?

  1. Review the Stackdriver logs for each Compute Engine instance that is serving as a node in the cluster.
  2. Review the Stackdriver logs for the specific GKE container that is serving the unresponsive part of the application.
  3. Connect to the cluster using gcloud credentials and connect to a container in one of the pods to read the logs.
  4. Review the Serial Port logs for each Compute Engine instance that is serving as a node in the cluster.

Answer(s): B

Explanation:

The correct answer is B. Review the Stackdriver logs for the specific GKE container that is serving the unresponsive part of the application. Here's why:
Kubernetes, and by extension GKE, primarily directs application logs to standard output (stdout) and standard error (stderr). Stackdriver (now Google Cloud Logging) automatically captures these streams from containers within GKE. This centralized logging solution allows for easy inspection of application logs without needing to access individual nodes or containers directly. Since the issue is with a specific part of the application, filtering logs by the relevant GKE container will pinpoint error messages that might explain the rapid pod restarts. Options A and D, focusing on Compute Engine instance logs or serial port logs, are less relevant here. Instance logs track the health and events of the nodes, while serial port logs contain boot messages, not application logs. Option C, connecting to containers, is cumbersome and requires node access, which goes against best practices of managed container environments. Container logs are ephemeral, thus connecting directly may prove unsuccessful as the container is restarting. Stackdriver provides a consistent and persistent view of container logs, including those of crashing containers, making it the most efficient method of troubleshooting this issue.
Relevant Links:
Google Cloud Logging: https://cloud.google.com/logging Kubernetes Logging: https://kubernetes.io/docs/concepts/cluster-administration/logging/
GKE Logging: https://cloud.google.com/kubernetes-engine/docs/how-to/logging



You are using a single Cloud SQL instance to serve your application from a specific zone. You want to introduce high availability.
What should you do?

  1. Create a read replica instance in a different region
  2. Create a failover replica instance in a different region
  3. Create a read replica instance in the same region, but in a different zone
  4. Create a failover replica instance in the same region, but in a different zone

Answer(s): D

Explanation:

Here's a detailed justification for why option D, "Create a failover replica instance in the same region, but in a different zone," is the correct approach for introducing high availability to a Cloud SQL instance within a specific zone:
High availability (HA) in the context of databases means ensuring the database remains accessible even in the event of hardware or software failures. Cloud SQL achieves this through replicas. A read replica allows for read scaling but does not provide automatic failover. A failover replica, on the other hand, is designed for HA and takes over if the primary instance fails. Since you are aiming for HA, a failover replica is required.
Creating a replica in a different region (option B) would introduce geographical redundancy but would be overkill for basic HA and potentially lead to increased latency for the primary application using the same region. Also, read replicas do not promote failover (options A and C). A replica in the same region but a different zone (option D) provides protection against zonal failures within the same region. This approach balances cost, complexity, and latency considerations while achieving the desired high availability. It allows for automatic failover of the primary instance to the replica, minimizing downtime if the zone of the primary instance encounters issues.
Key concepts:
High Availability: Ensuring service uptime by mitigating single points of failure. Failover Replica: A standby instance that automatically takes over when the primary fails. Zonal Failure: An outage affecting a single availability zone within a region. Regional Redundancy: Redundancy across different geographical locations, usually more expensive and introduces latency. Read Replica : An instance used for scaling reads, does not provide failover.
Therefore, option D is the optimal solution for implementing high availability for a Cloud SQL instance, within the constraints of regional proximity to the application, by providing automatic failover to a replica in another zone within the same region.
Relevant links:
Cloud SQL High Availability : Google Cloud's documentation on Cloud SQL High Availability. Regions and Zones : Overview of Google Cloud regions and zones.



Viewing page 15 of 98
Viewing questions 71 - 75 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!