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

Updated On: 15-Sep-2026

You have found an error in your App Engine application caused by missing Cloud Datastore indexes. You have created a YAML file with the required indexes and want to deploy these new indexes to Cloud Datastore.
What should you do?

  1. Point gcloud datastore create-indexes to your configuration file
  2. Upload the configuration file to App Engine's default Cloud Storage bucket, and have App Engine detect the new indexes
  3. In the GCP Console, use Datastore Admin to delete the current indexes and upload the new configuration file
  4. Create an HTTP request to the built-in python module to send the index configuration file to your application

Answer(s): A

Explanation:

The correct answer is A. Point gcloud datastore create-indexes to your configuration file.
Here's why: Google Cloud Datastore relies on indexes to efficiently query data.
When you introduce new query patterns that aren't covered by existing indexes, you need to define these indexes. App Engine manages index creation via a configuration file, typically index.yaml . Once you've created or modified this file to reflect required indexes, the gcloud datastore create-indexes command is the appropriate tool to submit the index definitions to the Datastore service. This command parses your index.yaml and orchestrates the index creation process within Datastore. Option B is incorrect because App Engine does not automatically detect or deploy new indexes from the storage bucket; specific commands are needed. Option C is also wrong; you don't manually delete existing indexes; gcloud datastore create-indexes will handle updating them. Lastly,
Option D is not a standard method of deploying index configurations; the command-line tool is the primary means. Using the gcloud tool ensures a streamlined and managed deployment process for Datastore indexes,
directly communicating with the service to register the new requirements. This approach allows you to avoid downtime for your application because the indexes are built in the background, without needing to rebuild or migrate data.
Authoritative Links:
gcloud datastore indexes create Configuring Datastore indexes



You have an application that will run on Compute Engine. You need to design an architecture that takes into account a disaster recovery plan that requires your application to fail over to another region in case of a regional outage.
What should you do?

  1. Deploy the application on two Compute Engine instances in the same project but in a different region. Use the first instance to serve traffic, and use the HTTP load balancing service to fail over to the standby instance in case of a disaster.
  2. Deploy the application on a Compute Engine instance. Use the instance to serve traffic, and use the HTTP load balancing service to fail over to an instance on your premises in case of a disaster.
  3. Deploy the application on two Compute Engine instance groups, each in the same project but in a different region. Use the first instance group to serve traffic, and use the HTTP load balancing service to fail over to the standby instance group in case of a disaster.
  4. Deploy the application on two Compute Engine instance groups, each in a separate project and a different region. Use the first instance group to serve traffic, and use the HTTP load balancing service to fail over to the standby instance group in case of a disaster.

Answer(s): C

Explanation:

The correct answer is C because it provides a robust and scalable disaster recovery solution utilizing Google Cloud's infrastructure effectively. Deploying applications across two instance groups, each in a different region within the same project, achieves geographic redundancy. This ensures that if one region experiences an outage, the application can seamlessly fail over to the other region. Using HTTP(S) Load Balancing is crucial as it intelligently routes traffic to the healthy instance group. The load balancer monitors the health of each instance group and automatically directs user requests to the active instance group. Crucially, having both instance groups within the same project simplifies management, resource access, and billing. Option A fails as it uses single instances rather than managed instance groups which makes automated scaling and failover less effective. Option B is incorrect as it mixes on-premises resources which will increase latency and management complexity for disaster recovery. Option D's approach with different projects introduces unnecessary management overhead, as resources across different projects are harder to manage and share. Therefore, option C balances high availability, disaster recovery, and ease of management.
https://cloud.google.com/compute/docs/instance-groupshttps://cloud.google.com/load-
balancing/docs/https/https://cloud.google.com/architecture/disaster-recovery



You are deploying an application on App Engine that needs to integrate with an on-premises database. For security purposes, your on-premises database must not be accessible through the public internet.
What should you do?

  1. Deploy your application on App Engine standard environment and use App Engine firewall rules to limit access to the open on-premises database.
  2. Deploy your application on App Engine standard environment and use Cloud VPN to limit access to the on-premises database.
  3. Deploy your application on App Engine flexible environment and use App Engine firewall rules to limit access to the on-premises database.
  4. Deploy your application on App Engine flexible environment and use Cloud VPN to limit access to the on-premises database.

Answer(s): D

Explanation:

The correct answer is D: Deploy your application on App Engine flexible environment and use Cloud VPN to limit access to the on-premises database. Here's why:
App Engine standard environment operates in a sandboxed environment, limiting direct network access to resources outside of Google Cloud. It does not support the direct creation of secure, private tunnels necessary for communication with on-premises resources behind a firewall. Options A and B are therefore incorrect because they rely on this environment's limitations.
App Engine flexible environment, on the other hand, provides more flexibility and direct control over the underlying infrastructure. It allows the creation of custom networking configurations, enabling the establishment of a secure connection to your on-premises network. This is achieved using Google's Cloud VPN service which establishes an encrypted tunnel between your Google Cloud VPC network and your on-premises network. This is why option D correctly states the use of flexible environment and Cloud VPN. Option C uses the App Engine firewall rules, which cannot reach on-premises infrastructure. App Engine firewall rules manage access to app engine application endpoints, not underlying VPC network infrastructure.
Therefore, to securely connect to an on-premises database not exposed to the public internet, the best approach is to deploy your application on App Engine flexible environment and utilize Cloud VPN. This setup provides the required network-level isolation and secure communication channel. Using Cloud VPN encrypts data in transit, enhancing the overall security of your application and protecting your database from external threats.
Relevant resources for further research:
App Engine Environments: https://cloud.google.com/appengine/docs/the-appengine-environments Connecting from App Engine to VPC networks: https://cloud.google.com/appengine/docs/flexible/python/connecting-vpc Cloud VPN: https://cloud.google.com/vpn/docs App Engine firewall rules: https://cloud.google.com/appengine/docs/standard/python/access-control



You are working in a highly secured environment where public Internet access from the Compute Engine VMs is not allowed. You do not yet have a VPN connection to access an on-premises file server. You need to install specific software on a Compute Engine instance. How should you install the software?

  1. Upload the required installation files to Cloud Storage. Configure the VM on a subnet with a Private Google Access subnet. Assign only an internal IP address to the VM. Download the installation files to the VM using gsutil.
  2. Upload the required installation files to Cloud Storage and use firewall rules to block all traffic except the IP address range for Cloud Storage. Download the files to the VM using gsutil.
  3. Upload the required installation files to Cloud Source Repositories. Configure the VM on a subnet with a Private Google Access subnet. Assign only an internal IP address to the VM. Download the installation files to the VM using gcloud.
  4. Upload the required installation files to Cloud Source Repositories and use firewall rules to block all traffic except the IP address range for Cloud Source Repositories. Download the files to the VM using gsutil.

Answer(s): A

Explanation:

The correct answer is A, which proposes using Cloud Storage as a secure intermediary for software installation on a Compute Engine VM without public internet access. Here's why:
Option A leverages Private Google Access, a feature that allows VMs with only internal IP addresses to access Google APIs and services, including Cloud Storage, without traversing the public internet. This satisfies the requirement for a highly secure environment where direct public internet access is disallowed. By uploading the necessary installation files to Cloud Storage, they become accessible to the VM through the private Google network. Then, the gsutil command-line tool can download these files, ensuring a secure transfer. Assigning only an internal IP address further restricts public access, reinforcing the security posture.
Option B, while using Cloud Storage, attempts to utilize firewall rules to restrict access. However, the complexity of maintaining precise firewall rules can introduce errors. Furthermore, it doesn't leverage the benefits of Private Google Access, making it less secure than option A. Option C employs Cloud Source Repositories which are designed for version control and source code.
While you can technically use it as a file repository, it's not its core function, making Cloud Storage more suitable for binary installation files. Finally, option D has similar issues to B, plus it uses a repository designed for source code rather than binary files.
Here are some authoritative links that support this explanation:
Private Google Access: https://cloud.google.com/vpc/docs/private-access-options#private-google-access Cloud Storage: https://cloud.google.com/storage/docs gsutil: https://cloud.google.com/storage/docs/gsutil
Therefore, option A provides the most secure and efficient way to install software on a Compute Engine VM in a restricted environment lacking public internet access by utilizing Cloud Storage and Private Google Access.



Your company is moving 75 TB of data into Google Cloud. You want to use Cloud Storage and follow Google-recommended practices.
What should you do?

  1. Move your data onto a Transfer Appliance. Use a Transfer Appliance Rehydrator to decrypt the data into Cloud Storage.
  2. Move your data onto a Transfer Appliance. Use Cloud Dataprep to decrypt the data into Cloud Storage.
  3. Install gsutil on each server that contains data. Use resumable transfers to upload the data into Cloud Storage.
  4. Install gsutil on each server containing data. Use streaming transfers to upload the data into Cloud Storage.

Answer(s): A

Explanation:

The optimal approach for migrating a large 75 TB dataset into Google Cloud Storage, adhering to Google's best practices, is to utilize a Transfer Appliance. Option A correctly identifies this. Transfer Appliance is a physical device specifically designed for efficient large-scale data transfer to Google Cloud. Given the volume, network uploads using tools like gsutil (options C and D) are likely to be significantly slower and less reliable due to network constraints and potential disruptions. The Transfer Appliance mitigates these issues by allowing you to ship the data to Google. Upon arrival, a Transfer Appliance Rehydrator decrypts the data into Cloud Storage which is part of the appliance.
While other tools like Cloud Dataprep exist, they are not the primary tools for the bulk transfer stage (option B). Cloud Dataprep is a data transformation service, not a transfer service for moving TB scale data. Therefore, the most efficient, secure, and recommended approach for this scenario is to use a Transfer Appliance and Rehydrator. Options C and D, involving gsutil and network uploads, are suitable for smaller datasets or ongoing incremental transfers, but are not optimal for a 75 TB initial migration. Resumable transfers with gsutil (option C) are preferable to streaming, yet using Transfer
Appliance is the ideal choice for this large bulk data movement.
Refer to the following for more information:
Google Cloud Transfer Appliance: https://cloud.google.com/transfer-appliance Google Cloud Storage Overview: https://cloud.google.com/storage gsutil Documentation: https://cloud.google.com/storage/docs/gsutil Cloud Dataprep Documentation: https://cloud.google.com/dataprep/docs



Viewing page 12 of 98
Viewing questions 56 - 60 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!