Google Associate-Cloud-Engineer Free Certification Exam Questions Answer Aug 2025 update

Question # 81

You need to deploy an application, which is packaged in a container image, in a new project. The application exposes an HTTP endpoint and receives very few requests per day. You want to minimize costs. What should you do

Deploy the container on Cloud Run.

Deploy the container on Cloud Run on GKE.

Deploy the container on App Engine Flexible.

Deploy the container on Google Kubernetes Engine, with cluster autoscaling and horizontal pod autoscaling enabled.

Question # 82

You are deploying an application to Google Kubernetes Engine (GKE) that needs to call an external third-party API. You need to provide the external API vendor with a list of IP addresses for their firewall to allow traffic from your application. You want to follow Google-recommended practices and avoid any risk of interrupting traffic to the API due to IP address changes. What should you do?

Configure your GKE cluster with one node, and set the node to have a static external IP address. Ensure that the GKE cluster autoscaler is off. Send the external IP address of the node to the vendor to be added to the allowlist.

Configure your GKE cluster with private nodes. Configure a Cloud NAT instance with static IP addresses. Provide these IP addresses to the vendor to be added to the allowlist.

Configure your GKE cluster with public nodes. Write a Cloud Function that pulls the public IP addresses of each node in the cluster. Trigger the function to run every day with Cloud Scheduler. Send the list to the vendor by email every day.

Configure your GKE cluster with private nodes. Configure a Cloud NAT instance with dynamic IP addresses. Provide these IP addresses to the vendor to be added to the allowlist.

Explanation:

The requirement is for a stable set of egress IP addresses from a GKE cluster for allowlisting by a third party, following best practices.

Option A is not recommended: Using a single node lacks scalability and high availability. Relying on a single node's static IP creates a single point of failure and doesn't align with GKE's design principles. Disabling autoscaling hinders elasticity.

Option C is complex and unreliable: Public nodes typically have ephemeral external IPs (unless manually configured per node, which is difficult to manage with autoscaling). Dynamically tracking and emailing IPs daily is operationally burdensome and prone to race conditions where the allowlist might lag behind IP changes.

Option D uses Cloud NAT but with dynamic IPs. Dynamic IPs change over time, making them unsuitable for stable firewall allowlists.

Option B is the Google-recommended practice: Configuring the GKE cluster with private nodes enhances security as nodes don't have direct external IPs. Cloud NAT provides managed network address translation for these private nodes to access the internet. By configuring Cloud NAT with a static allocation of external IP addresses, all egress traffic from the private GKE nodes will appear to originate from this stable, predictable set of IPs. This set can be given to the vendor for allowlisting without worrying about node IP changes due to scaling or maintenance.

This approach decouples the application's egress IP from the individual nodes, providing stability and adhering to the principle of least privilege (private nodes).

[References:, , Cloud NAT Overview: "Cloud NAT lets certain resources without external IP addresses create outbound connections to the internet." - https://cloud.google.com/nat/docs/overview, Cloud NAT IP Addresses: "When you configure a NAT gateway... You can configure the NAT gateway to automatically allocate regional external IP addresses... Alternatively, you can manually assign a fixed number of static external IP addresses to the gateway." - https://cloud.google.com/nat/docs/overview#ip-addresses, GKE and Cloud NAT: "Configure Cloud NAT with GKE... Use Case: You want a GKE pod to deterministically egress traffic from a static set of IP addresses that you control." - https://cloud.google.com/nat/docs/gke-example, Private Clusters: "Private nodes do not have endpoint-accessible external IP addresses." - https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters , , , ]

Question # 83

You are planning to migrate a database and a backend application to a Standard Google Kubernetes Engine (GKE) cluster. You need to prevent data loss and make sure there are enough nodes available for your backend application based on the demands of your workloads. You want to follow Google-recommended practices and minimize the amount of manual work required. What should you do?

Run your database as a StatefulSet. Configure cluster autoscaling to handle changes in the demands of your workloads.

Run your database as a single Pod. Run the resize command when you notice changes in the demands of your workloads.

Run your database as a Deployment. Configure cluster autoscaling to handle changes in the demands of your workloads.

Run your database as a DaemonSet. Run the resize command when you notice changes in the demands of your workloads.

Question # 84

(You are developing an internet of things (IoT) application that captures sensor data from multiple devices that have already been set up. You need to identify the global data storage product your company should use to store this data. You must ensure that the storage solution you choose meets your requirements of sub-millisecond latency. What should you do?)

Store the IoT data in Spanner. Use caches to speed up the process and avoid latencies.

Store the IoT data in Bigtable.

Capture IoT data in BigQuery datasets.

Store the IoT data in Cloud Storage. Implement caching by using Cloud CDN.

Explanation:

Let's evaluate each option based on the requirement of sub-millisecond latency for globally stored IoT data:

A. Spanner with Caching: While Spanner offers strong consistency and global scalability, the base latency might not consistently be sub-millisecond for all read/write operations globally. Introducing caching adds complexity and doesn't guarantee sub-millisecond latency for all initial reads or cache misses.

B. Bigtable: Bigtable is a highly scalable NoSQL database service designed for low-latency, high-throughput workloads. It excels at storing and retrieving large volumes of time-series data, which is typical for IoT sensor data. Its architecture is optimized for single-key lookups and scans, providing consistent sub-millisecond latency, making it a strong candidate for this use case.

C. BigQuery: BigQuery is a fully managed, serverless data warehouse designed for analytical queries on large datasets. While it's excellent for analyzing IoT data in batch, it's not optimized for the low-latency, high-throughput ingestion and retrieval required for real-time IoT applications with sub-millisecond latency needs.

D. Cloud Storage with Cloud CDN: Cloud Storage is object storage and is not designed for low-latency transactional workloads. Cloud CDN is a content delivery network that caches content closer to users for faster delivery, but it's not suitable for the primary storage of rapidly incoming IoT sensor data requiring sub-millisecond write latency.

Google Cloud Documentation References:

Cloud Bigtable Overview: https://cloud.google.com/bigtable/docs/overview - This document highlights Bigtable 's suitability for low-latency and high-throughput applications, including IoT. It mentions its ability to handle massive amounts of data with consistent performance.

Spanner Overview: https://cloud.google.com/spanner/docs/overview - While Spanner offers low latency, Bigtable is generally preferred for extremely high-throughput, low-latency use cases like raw sensor data ingestion due to its optimized architecture for such workloads.

BigQuery Overview: https://cloud.google.com/bigquery/docs/introduction - This emphasizes BigQuery 's analytical capabilities rather than low-latency operational workloads.

Cloud Storage Overview: https://cloud.google.com/storage/docs/overview - This describes Cloud Storage as object storage, not ideal for sub-millisecond latency reads and writes required for real-time IoT data.

===========

Question # 85

You have a large 5-TB AVRO file stored in a Cloud Storage bucket. Your analysts are proficient only in SQL and need access to the data stored in this file. You want to find a cost-effective way to complete their request as soon as possible. What should you do?

Load data in Cloud Datastore and run a SQL query against it.

Create a BigQuery table and load data in BigQuery. Run a SQL query on this table and drop this table after you complete your request.

Create external tables in BigQuery that point to Cloud Storage buckets and run a SQL query on these external tables to complete your request.

Create a Hadoop cluster and copy the AVRO file to NDFS by compressing it. Load the file in a hive table and provide access to your analysts so that they can run SQL queries.

Question # 86

You created a Google Cloud Platform project with an App Engine application inside the project. You initially configured the application to be served from the us-central region. Now you want the application to be served from the asia-northeast1 region. What should you do?

Change the default region property setting in the existing GCP project to asia-northeast1.

Change the region property setting in the existing App Engine application from us-central to asia-northeast1.

Create a second App Engine application in the existing GCP project and specify asia-northeast1 as the region to serve your application.

Create a new GCP project and create an App Engine application inside this new project. Specify asia-northeast1 as the region to serve your application.

Question # 87

Your projects incurred more costs than you expected last month. Your research reveals that a development GKE container emitted a huge number of logs, which resulted in higher costs. You want to disable the logs quickly using the minimum number of steps. What should you do?

1. Go to the Logs ingestion window in Stackdriver Logging, and disable the log source for the GKE container resource.

1. Go to the Logs ingestion window in Stackdriver Logging, and disable the log source for the GKE Cluster Operations resource.

1. Go to the GKE console, and delete existing clusters.2. Recreate a new cluster.3. Clear the option to enable legacy Stackdriver Logging.

1. Go to the GKE console, and delete existing clusters.2. Recreate a new cluster.3. Clear the option to enable legacy Stackdriver Monitoring.

Question # 88

You are developing an application that will be deployed on Google Cloud. The application will use a service account to retrieve data from BigGuery. Before you deploy your application, you want to test the permissions of this service account from your local machine to ensure there will be no authentication issues. You want to ensure that you use the most secure method while following Google-recommended practices What should you do?

Configure the gcloud CLI with Application Default Credentials using your user account. Issue a relevant BigGuery request through the gcloud CLI to test the access.

Grant the service account the BlgQuery Administrator 1AM role to ensure the service account has all required access.

Generate a service account key, and configure the gcloud CLI to use this key. Issue a relevant BlgQuery request through the gcloud CLI to test the access.

Configure the gcloud CLI to use service account impersonation. Issue a relevant BigQuery request through the gcloud CLI to test the access.

Question # 89

Your Dataproc cluster runs in a single Virtual Private Cloud (VPC) network in a single subnet with range 172.16.20.128/25. There are no private IP addresses available in the VPC network. You want to add new VMs to communicate with your cluster using the minimum number of steps. What should you do?

Modify the existing subnet range to 172.16.20.0/24.

Create a new Secondary IP Range in the VPC and configure the VMs to use that range.

Create a new VPC network for the VMs. Enable VPC Peering between the VMs’ VPC network and the Dataproc cluster VPC network.

Create a new VPC network for the VMs with a subnet of 172.32.0.0/16. Enable VPC network Peering between the Dataproc VPC network and the VMs VPC network. Configure a custom Route exchange.

Question # 90

You want to permanently delete a Pub/Sub topic managed by Config Connector in your Google Cloud project. What should you do?

Use kubect1 to delete the topic resource.

Use gcloud CLI to delete the topic.

Use kubect1 to create the label deleted-by-cnrm and to change its value to true for the topic resource.

Use gcloud CLI to update the topic label managed-by-cnrm to false.

Summer Special Limited Time 65% Discount Offer - Ends in 0d 00h 00m 00s - Coupon code: exc65

Free Practice Questions for Google Associate-Cloud-Engineer Exam

The Answer Is:

Explanation:

The Answer Is:

Explanation:

The Answer Is:

The Answer Is:

Explanation:

The Answer Is:

Explanation:

The Answer Is:

Explanation:

The Answer Is:

Explanation:

The Answer Is:

The Answer Is:

Explanation:

The Answer Is: