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

Updated On: 31-Aug-2026

You have an application deployed on Google Kubernetes Engine using a Deployment named echo-deployment. The deployment is exposed using a Service called echo-service. You need to perform an update to the application with minimal downtime to the application.
What should you do?

  1. Use kubectl set image deployment/echo-deployment <new-image>
  2. Use the rolling update functionality of the Instance Group behind the Kubernetes cluster
  3. Update the deployment yaml file with the new container image. Use kubectl delete deployment/echo-deployment and kubectl create "f <yaml-file>
  4. Update the service yaml file which the new container image. Use kubectl delete service/echo-service and kubectl create "f <yaml-file>

Answer(s): A

Explanation:

Here's a detailed justification for why option A is the correct way to perform a rolling update on a Kubernetes Deployment, with minimal downtime:
Option A, kubectl set image deployment/echo-deployment <new-image> , leverages Kubernetes' built-in rolling update strategy for Deployments. This command directly modifies the image used in the Deployment's Pod template. Kubernetes then orchestrates a phased update, creating new Pods with the updated image while gradually terminating the old ones. This approach minimizes downtime because the service continues to serve requests during the update.
Option B, focusing on Instance Group rolling updates, is incorrect. Instance Groups manage virtual machines, while we're dealing with Kubernetes Pods within the cluster. GKE handles the underlying node infrastructure updates; Kubernetes deployments handle application updates. Option C is disruptive. Deleting and recreating the Deployment would cause a brief period of downtime while new Pods are being created. The service won't be available during this transition. Option D incorrectly targets the Service instead of the Deployment. Services abstract the backend Pods; they do not control the images used. Changing a service won’t trigger an update of the application.
Kubernetes Deployments are designed for declarative updates, and kubectl set image provides a simple and efficient way to trigger rolling updates. The rolling update process ensures a gradual transition, using health checks to prevent downtime if a new Pod does not become healthy. The old Pods are only terminated after new Pods are running and ready to serve requests. This ensures that the service remains continuously available.
Authoritative links for further research:
Kubernetes Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ kubectl set image: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#set Rolling Updates: https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/



Your company is using BigQuery as its enterprise data warehouse. Data is distributed over several Google Cloud projects. All queries on BigQuery need to be billed on a single project. You want to make sure that no query costs are incurred on the projects that contain the data. Users should be able to query the datasets, but not edit them. How should you configure users' access roles?

  1. Add all users to a group. Grant the group the role of BigQuery user on the billing project and BigQuery dataViewer on the projects that contain the data.
  2. Add all users to a group. Grant the group the roles of BigQuery dataViewer on the billing project and BigQuery user on the projects that contain the data.
  3. Add all users to a group. Grant the group the roles of BigQuery jobUser on the billing project and BigQuery dataViewer on the projects that contain the data.
  4. Add all users to a group. Grant the group the roles of BigQuery dataViewer on the billing project and BigQuery jobUser on the projects that contain the data.

Answer(s): C

Explanation:

The correct answer is C. To ensure queries are billed to a single project and users can access data without modifying it, we need to configure roles appropriately. The billing project should be granted the BigQuery jobUser role. This role allows users to run queries and create jobs within that project, meaning all query costs are associated with it. For the projects containing the data, users need BigQuery dataViewer role. This enables read-only access to the datasets, allowing them to query and view data but not modify anything. Option A is incorrect because BigQuery user doesn't allow users to create jobs required for querying. Option B has the roles reversed for billing and data projects, leading to incorrect billing. Option D also has roles reversed, causing users to be unable to initiate queries from the billing project. Centralized billing control is achieved by having all query jobs initiated in the billing project. Using a group for managing users simplifies role assignment and maintenance. This approach aligns with the principle of least privilege, granting only necessary permissions for the task. By separating query execution from data storage, costs can be effectively managed.
Supporting Links:
BigQuery Roles and Permissions: https://cloud.google.com/bigquery/docs/access-control BigQuery IAM Roles: https://cloud.google.com/iam/docs/understanding-roles#bigquery-roles BigQuery Jobs: https://cloud.google.com/bigquery/docs/jobs-overview



You have developed an application using Cloud ML Engine that recognizes famous paintings from uploaded images. You want to test the application and allow specific people to upload images for the next 24 hours. Not all users have a Google Account. How should you have users upload images?

  1. Have users upload the images to Cloud Storage. Protect the bucket with a password that expires after 24 hours.
  2. Have users upload the images to Cloud Storage using a signed URL that expires after 24 hours.
  3. Create an App Engine web application where users can upload images. Configure App Engine to disable the application after 24 hours. Authenticate users via Cloud Identity.
  4. Create an App Engine web application where users can upload images for the next 24 hours. Authenticate users via Cloud Identity.

Answer(s): B

Explanation:

Here's a detailed justification for why option B is the correct solution:
Option B, using Cloud Storage signed URLs, provides a secure and efficient way for users, regardless of whether they have a Google account or not, to upload images for a limited period. Signed URLs grant temporary access to a specific Cloud Storage object (in this case, the bucket for uploads). Critically, these URLs can be configured with an expiration time, which perfectly aligns with the 24-hour requirement outlined in the scenario. This allows you to grant write permissions for the specific window without the need to manage user identities directly.
Here's why other options are less suitable:
Option A (Password-protected bucket): While you could technically protect a bucket with a password, this is not a standard security practice for Cloud Storage, and managing and distributing a single password for multiple users is cumbersome and insecure. It does not allow for controlled temporary access. Option C & D (App Engine with Cloud Identity): These options introduce unnecessary complexity. Cloud Identity requires users to have Google accounts and creates a dependency on a full-blown web application, which is overkill for a simple image upload test. Furthermore, disabling an app after 24 hours (option C) is not a scalable solution.
Why signed URLs are the optimal approach:
1. Security: Signed URLs are inherently more secure than password-protected buckets because access is granular and time-limited. 2. Simplicity: They are easy to generate and share and do not require user authentication. 3. Scalability: They can be generated programmatically and distributed efficiently. 4. Temporary access: They enforce the 24-hour constraint, which is a key requirement of the scenario. 5. No Google account required: Users do not need a Google account to utilize signed URLs, which perfectly addresses that requirement.
In summary: Option B provides a secure, efficient, and temporary mechanism for users to upload images, addressing all the specific constraints of the scenario without unnecessary complexity or security vulnerabilities.
Authoritative Links for further research:
Cloud Storage Signed URLs: https://cloud.google.com/storage/docs/access-control/signed-urls Cloud Storage Security Overview: https://cloud.google.com/storage/docs/security Cloud IAM Overview: https://cloud.google.com/iam/docs/overview



Your web application must comply with the requirements of the European Union's General Data Protection Regulation (GDPR). You are responsible for the technical architecture of your web application.
What should you do?

  1. Ensure that your web application only uses native features and services of Google Cloud Platform, because Google already has various certifications and provides pass-on compliance when you use native features.
  2. Enable the relevant GDPR compliance setting within the GCPConsole for each of the services in use within your application.
  3. Ensure that Cloud Security Scanner is part of your test planning strategy in order to pick up any compliance gaps.
  4. Define a design for the security of data in your web application that meets GDPR requirements.

Answer(s): D

Explanation:

The correct answer is D. Define a design for the security of data in your web application that meets GDPR requirements. This is because GDPR compliance is not a passive setting or a feature of a specific platform like GCP, but rather an active responsibility of the data controller (you, in this case, as you own the web application). You must proactively design and implement data security measures that adhere to GDPR's stringent requirements.
Option A is incorrect because while GCP provides many tools and features that can aid in compliance, simply using native services does not guarantee GDPR compliance. Compliance is a shared responsibility, and you must configure and use these services correctly within your specific architecture. Option B is also incorrect, as there isn't a global "GDPR compliance setting" within the GCP console. Compliance is granular and must be addressed service by service and within your data processing logic. Option C is a good practice for security testing but insufficient alone to achieve GDPR compliance; it's one aspect of a broader plan.
GDPR mandates specific requirements like data minimization, purpose limitation, storage limitation, security, integrity, and confidentiality of personal data. The responsibility falls on you to design your application architecture, data flows, and security measures to meet these requirements explicitly. This includes pseudonymization, encryption, access control, and establishing procedures for data breaches and user rights requests. Designing for GDPR must be baked into the application's architecture from the start, not applied as an afterthought.
Authoritative Links for Further Research:
GDPR Official Website: https://gdpr-info.eu/ Google Cloud Platform GDPR Documentation: https://cloud.google.com/security/gdpr
Shared Responsibility Model: https://cloud.google.com/security/overview/concepts#shared_responsibility



You need to set up Microsoft SQL Server on GCP. Management requires that there's no downtime in case of a data center outage in any of the zones within a GCP region.
What should you do?

  1. Configure a Cloud SQL instance with high availability enabled.
  2. Configure a Cloud Spanner instance with a regional instance configuration.
  3. Set up SQL Server on Compute Engine, using Always On Availability Groups using Windows Failover Clustering. Place nodes in different subnets.
  4. Set up SQL Server Always On Availability Groups using Windows Failover Clustering. Place nodes in different zones.

Answer(s): A

Explanation:

The correct answer is A, configuring a Cloud SQL instance with high availability (HA) enabled. This is because Cloud SQL's HA feature provides automatic failover in case of a zonal outage, ensuring minimal downtime. Cloud SQL manages the underlying infrastructure, abstracting away the complexity of manual failover setup. Options C and D involve setting up SQL Server on Compute Engine using Always On Availability Groups (AAGs) with Windows Failover Clustering (WFC).
While this approach can achieve high availability, it requires significant manual configuration, management, and maintenance of the VMs, OS, SQL Server, and clustering setup. Cloud Spanner (Option B) is a globally distributed database service, not directly intended for SQL Server deployments, and would be an inappropriate choice for migrating a SQL Server workload. Cloud SQL simplifies this complex setup, making it a more straightforward and efficient option for achieving high availability without the overhead of managing an entire clustered environment. By choosing Cloud SQL's HA option, you can focus on application development rather than infrastructure management, ensuring business continuity and ease of use. This aligns with Google Cloud's managed services approach, optimizing for agility and cost-effectiveness.
Supporting links:
Cloud SQL High Availability: https://cloud.google.com/sql/docs/mysql/high-availability (This link shows the MySQL version, but the same concepts apply to SQL Server Cloud SQL instances.) Cloud SQL for SQL Server: https://cloud.google.com/sql/docs/sqlserver Always On Availability Groups: https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-ver16



Viewing page 13 of 98
Viewing questions 61 - 65 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!