Google PCA Practice Test 37 — 15 Questions

Question 1

Your company has migrated its legacy web application from a single Compute Engine instance to a managed instance group (MIG) behind an HTTP(S) load balancer. The application was updated to a new version as part of the migration. After the migration, users report intermittent 502 Bad Gateway errors. The application logs show no errors, and the load balancer backend health checks are reported as healthy. On investigation, the developers discover that the new version requires a specific environment variable for authentication to a downstream service. This variable was set manually on the original instance but is missing from the MIG's instance template. The health check endpoint does not depend on this variable and always returns a 200 status even when the variable is absent. As a result, instances created from the template are considered healthy by the load balancer, but when they receive requests that require authentication, they fail and return a 502 error to the client. What is the most likely cause of the 502 errors?

Accepted Answer

The missing environment variable causes authentication failures on new instances.. The 502 errors occur because the new application version requires a specific environment variable for authentication to a downstream service. The health check endpoint does not depend on this variable, so instances are marked healthy even though they cannot authenticate real requests. When the load balancer routes traffic to these instances, the missing variable causes authentication failures, leading to 502 Bad Gateway errors.

Answer

The health check is configured to check the old application path, which no longer exists.

Answer

The load balancer's backend timeout is too short for the application's response time.

Answer

The MIG is not scaling out fast enough to handle peak traffic.

Question 2

You are the lead cloud architect for a startup that runs a web application on Google Kubernetes Engine (GKE) with a standard (zonal) cluster. The application is deployed with 3 replicas of a stateless frontend service. During a recent incident, a zone outage caused all GKE nodes to become unavailable, leading to application downtime of 45 minutes. You need to redesign the cluster to tolerate a single zone failure with no more than 5 minutes of downtime. Your budget allows for at most a 20% increase in compute costs. Which approach should you take?

Accepted Answer

Migrate the cluster to a regional GKE cluster with nodes in 3 zones and distribute replicas across zones. D is correct because a regional GKE cluster distributes nodes across three zones, ensuring that if one zone fails, the remaining two zones continue serving traffic. By spreading the 3 replicas across zones (e.g., one per zone), the application tolerates a single zone outage with near-zero downtime, and the 20% cost increase covers the additional node pool overhead without exceeding the budget.

Answer

Increase the number of replicas from 3 to 9 and keep the zonal cluster

Answer

Change the frontend deployment to use regional persistent disks

Answer

Deploy second GKE cluster in another region and use global load balancer for failover

Question 3

A company runs a real-time data analytics platform on Google Cloud that ingests streaming data from IoT devices. The architecture uses Cloud Pub/Sub to receive messages, Dataflow for processing, and BigQuery for storage. Recently, the team noticed that the processing latency has increased significantly during peak hours. Upon investigation, they found that the Dataflow pipeline is experiencing high system lag and some workers are being killed due to out-of-memory errors. The pipeline uses a fixed window of 10 seconds and writes to BigQuery using streaming inserts. The company wants to reduce latency without sacrificing data accuracy. Which course of action should they take?

Accepted Answer

Enable Dataflow streaming engine and use exactly-once processing mode. Option D is correct. Dataflow Streaming Engine offloads the shuffle operation to a backend service, reducing memory pressure and allowing workers to handle more data. Increasing workers (A) may help but root cause is memory. Changing windowing (B) sacrifices timeliness. Dead-letter queue (C) does not address latency.

Answer

Change the windowing to a global window and use batch inserts to BigQuery

Answer

Increase the number of Dataflow workers and machine type to handle the load

Answer

Implement a dead-letter queue for unprocessed messages and use a slower processing rate

Question 4

A company runs an e-commerce platform on Google Cloud. The application is deployed on Google Kubernetes Engine (GKE) with a regional cluster (us-central1, three zones). The frontend service is exposed via an HTTP Load Balancer with Cloud CDN. Recently, during a flash sale, users experienced high latency and occasional 502 errors. The backend service is a Java application that reads from Cloud Spanner. The team has observed that Spanner CPU utilization averaged 65% during the sale, with a few spikes to 80%. The number of frontend pods was auto-scaled to 50, each running on n1-standard-2 nodes. The node pool is set to autoscale up to 100 nodes. The errors appear to correlate with periods of high CPU on the nodes, but not always. What is the most likely cause and recommended action?

Accepted Answer

Change the backend service to use a multi-zone NEG that includes endpoints from all three zones, and ensure the load balancer is configured for cross-zone load balancing.. The high latency and 502 errors are likely caused by the HTTP Load Balancer sending requests to unhealthy backend pods due to zone-imbalanced traffic. A regional GKE cluster with a multi-zone NEG and cross-zone load balancing ensures that the load balancer distributes requests evenly across all pods in all three zones, preventing node CPU spikes in a single zone from causing errors. Option B directly addresses this by enabling proper traffic distribution, which is the most probable root cause given that node CPU spikes correlate with errors but not always.

Answer

Scale up the Cloud Spanner instance to handle higher peak CPU, as the 80% spikes indicate insufficient capacity.

Answer

Increase the CPU request for the frontend pods and set a higher target CPU utilization for the Horizontal Pod Autoscaler.

Answer

Increase the health check interval and timeout settings to give pods more time to respond before being marked unhealthy.

Question 5

Your company runs a stateful web application on Compute Engine instances in a managed instance group (MIG) with autoscaling based on CPU utilization. The application maintains session state in memory on each instance. Recently, users have been experiencing session timeouts and data loss during scaling events. Additionally, the application's performance degrades under load due to frequent database queries for session data. You need to design a solution that ensures session persistence, improves performance, and minimizes application changes. The application is written in Java and uses Tomcat. Which of the following should you do?

Accepted Answer

Deploy Cloud Memorystore for Redis as a session store, and configure Tomcat to use Redis-backed session persistence using the Redisson or Spring Session framework.. Option B is correct because it introduces an external, highly available, in-memory session store (Cloud Memorystore for Redis) that decouples session state from individual Compute Engine instances. This eliminates session loss during autoscaling events and reduces database load by serving session data from fast Redis memory, all while requiring minimal application changes via Tomcat's built-in session persistence or Spring Session integration.

Answer

Rewrite the application to be stateless by moving all state to the frontend using JWT tokens, eliminating the need for server-side sessions.

Answer

Configure the load balancer to use session affinity (sticky sessions) and increase the instance size to handle more sessions per instance.

Answer

Store session data in Cloud SQL using Spring Session JDBC, and configure the application to retrieve sessions from the database.

Question 6

Your company runs a multi-tier web application on Google Kubernetes Engine (GKE). The application consists of a frontend service, a backend API service, and a PostgreSQL database deployed using a StatefulSet with persistent volumes. The backend service exposes a gRPC endpoint. Recently, the team noticed that the backend service experiences intermittent high latency and occasional timeouts. The frontend service is stateless and scales well. The backend service is CPU-bound. The database is not the bottleneck. The cluster has three nodes of type n1-standard-4. The backend service is deployed with 10 replicas, each requesting 1 CPU and 2 Gi memory. Node utilization is around 70% CPU. The team suspects the network is the issue. However, after reviewing the GKE monitoring dashboard, they see that the network bytes sent/received per second for the backend pods is well below the node's network bandwidth limit. The latency spikes seem correlated with periods of high CPU throttling on the backend pods. The backend service's gRPC requests are small (under 1 KB), and the responses are also small. The team has already optimized the application code. What should the team do to reduce latency?

Accepted Answer

Increase the CPU request for the backend pods to 2 CPUs.. The correct answer is C because the latency spikes correlate with CPU throttling, and increasing the CPU request to 2 CPUs ensures that each backend pod receives a guaranteed CPU share, reducing throttling under load. Since the backend is CPU-bound and node utilization is 70%, the current 1 CPU request may be insufficient, causing the Kubernetes CPU manager to throttle the pods when the node's CPU is contended. This directly addresses the root cause without adding unnecessary replicas or memory.

Answer

Increase the number of nodes in the cluster to reduce network contention.

Answer

Increase the number of backend replicas to 20.

Answer

Increase the memory request for the backend pods to 4 Gi.

Question 7

Your company runs a critical application on Google Kubernetes Engine (GKE) with 5 nodes. The application experiences intermittent high latency every Friday afternoon. The team has ruled out infrastructure issues and suspects the application logic. You need to instrument the application to identify the root cause. Which approach should you take?

Accepted Answer

Use Cloud Monitoring to create custom metrics for application performance and investigate recent code changes.. Option A is correct because the team has already ruled out infrastructure issues and suspects application logic. Creating custom metrics in Cloud Monitoring allows you to instrument the application with key performance indicators (e.g., request latency, error rates) and correlate them with recent code changes to pinpoint the root cause of intermittent high latency. This approach directly addresses the need to monitor application-level behavior rather than infrastructure metrics.

Answer

Increase the number of nodes in the GKE cluster to handle the load.

Answer

Enable Cloud Logging and analyze logs for error messages during the latency periods.

Answer

Configure GKE usage metering to track resource consumption by namespace.

Question 8

Your company runs a containerized microservices application on Google Kubernetes Engine (GKE) with a regional cluster. The application consists of a frontend service, a backend API service, and a background worker service that processes messages from Cloud Pub/Sub. The worker service uses a Deployment with 3 replicas. Recently, the team noticed that the worker service is frequently failing with 'ContainerCreating' errors. The error message in the pod events is: 'Failed to pull image "gcr.io/my-project/my-worker:latest": rpc error: code = DeadlineExceeded desc = context deadline exceeded'. The image is stored in Container Registry in the same project. The cluster nodes are n1-standard-2 VMs with 10 GB of disk space. The team has confirmed that the image exists and that the nodes have internet access. What is the most likely cause of the issue?

Accepted Answer

The nodes have insufficient disk space to pull the new image, causing the pull to time out.. The error 'context deadline exceeded' when pulling an image indicates that the kubelet timed out while trying to download the container image. With only 10 GB of disk space on n1-standard-2 nodes, the node's disk may be nearly full, causing the image pull to stall or fail due to insufficient space to unpack the layers. This is the most likely cause because the image exists and internet access is confirmed, ruling out authentication or connectivity issues.

Answer

The worker pods require node affinity to a specific node pool that is not configured.

Answer

The nodes do not have the necessary permissions to access Container Registry.

Answer

The cluster is a regional cluster, but the worker pods are all scheduled in the same zone, causing resource contention.

Question 9

A company runs a critical web application behind an external HTTPS load balancer. The backend consists of a managed instance group of Compute Engine instances. Users report intermittent 502 Bad Gateway errors. The load balancer logs show occasional health check failures for some instances. The instances have a custom health check endpoint that returns a 200 status code only if the application is fully healthy. The application logs do not show any errors, and CPU/memory usage on the instances is normal. What should be the first troubleshooting step to identify the root cause?

Accepted Answer

Check the application's logs on the instances to see why the health check endpoint sometimes returns non-200. Option B is correct. The health check is failing, and since the instances show normal CPU/memory, the application might be slow to respond under certain conditions. Checking the application logs on the instances will reveal why the health check endpoint returns non-200. Option A is wrong because increasing the interval doesn't fix the underlying issue. Option C is wrong because adding instances won't help if the health check is flaky. Option D is wrong because TCP health check would not validate application health and could mask the problem.

Answer

Change the health check to a TCP check on the application's port

Answer

Increase the health check check interval and decrease the unhealthy threshold

Answer

Increase the number of instances in the managed instance group

Question 10

A startup is deploying a microservices application on Google Kubernetes Engine (GKE) with a regional cluster. They have services that need to communicate with each other and also with external APIs. The cluster uses VPC-native routing. They have enabled Cloud NAT to allow outbound internet access for nodes without external IPs. However, the development team reports that some pods cannot reach the external APIs, while others can. All pods are in the same namespace and are not using any network policies. The pods that fail have the annotation 'cloud.google.com/gke-nat-ips' set to a list of static IP addresses. The pods that work do not have this annotation. What is the most likely cause of the failure?

Accepted Answer

The annotation 'cloud.google.com/gke-nat-ips' is not compatible with Cloud NAT for outbound traffic.. The annotation 'cloud.google.com/gke-nat-ips' is used to assign specific static IP addresses for outbound traffic from pods, but it is only compatible with the GKE Native Networking (formerly VPC-native) and the Cloud NAT gateway when the pods use the default NAT configuration. When this annotation is set, Cloud NAT is bypassed for those pods, and the traffic is sent directly from the specified static IPs, which may not be properly routed or may be blocked by the external API's firewall rules. In contrast, pods without the annotation use Cloud NAT's dynamic IPs, which are correctly routed and allowed.

Answer

Network policies are blocking outbound traffic for those pods.

Answer

The VPC-native routing is misconfigured for the pods with the annotation.

Answer

The annotation is used to assign static IPs for inbound traffic only.

Question 11

Your company runs a critical application on Google Kubernetes Engine (GKE) in us-central1. The application consists of a frontend deployment with 3 replicas and a backend statefulset with 5 replicas using persistent volumes (SSD). Recently, the team noticed that during a regional outage in us-central1, the application became completely unavailable. They want to design a multi-region architecture that can survive a regional failure with RPO of 1 hour and RTO of 30 minutes. The application is stateless on the frontend but the backend stores critical data on persistent disks. The backend can operate in a read-only mode from a secondary region if needed. They have a limited budget and want to minimize ongoing costs. Which approach should they take?

Accepted Answer

Deploy the frontend and backend in a regional GKE cluster across us-central1, and use a CronJob to take snapshots of persistent volumes every hour and copy them to a secondary region. In disaster, restore the snapshots to a new cluster in the secondary region.. Option D meets the RPO of 1 hour by using a CronJob to take hourly snapshots of PersistentVolume data and copy them to a secondary region. In a disaster, you restore those snapshots to a new GKE cluster in the secondary region, achieving an RTO of 30 minutes by automating the restore process. This approach minimizes ongoing costs because snapshots are incremental and you only pay for storage in the secondary region when needed, while the frontend remains stateless and can be redeployed quickly.

Answer

Migrate the backend to Cloud SQL for MySQL with cross-region replication, and keep the frontend on GKE with multi-region ingress.

Answer

Deploy the frontend and backend in a regional GKE cluster and use regional persistent disks for the statefulset, replicating data synchronously across zones.

Answer

Deploy the frontend and backend in a single zonal cluster in us-central1-a, and use scheduled snapshots of persistent disks to a different region.

Question 12

A company is using Cloud Functions (2nd gen) for event-driven processing of uploaded images in Cloud Storage. Each image is resized to multiple sizes and stored back in different buckets. Recently, the number of uploads has increased 10x, and the team notices that some images are not being processed, and logs show function execution timeouts after 60 seconds. The function's timeout is set to 60 seconds. The code processes images sequentially. The team needs to reliably process all images with minimal code changes. What should they do?

Accepted Answer

Use Cloud Tasks to queue the processing and run the function as a task handler.. Option D is correct because using Cloud Tasks decouples the processing, allowing retries and better scaling. Option A (increase timeout) delays the problem. Option B (split into multiple functions) requires significant code changes. Option C (increase memory) may speed up processing but may not handle all image sizes reliably.

Answer

Increase the memory allocation for the function.

Answer

Increase the Cloud Function timeout to 540 seconds.

Answer

Split the function into separate functions for each resize operation.

Question 13

A large enterprise is migrating its on-premises data warehouse to BigQuery. The current warehouse is 100 TB and uses complex ETL jobs that run on SQL Server Integration Services (SSIS). The team wants to minimize migration effort and maintain the same SQL logic for transformations. They plan to use BigQuery's standard SQL. They also need to schedule transformations and load data from multiple on-premises sources. Which approach should they take?

Accepted Answer

Use Cloud Composer (Airflow) to orchestrate SQL statements in BigQuery, and use Data Transfer Service for scheduled loads.. Option A is correct: Cloud Composer (Airflow) can orchestrate BigQuery SQL statements, and Data Transfer Service handles scheduled loads from on-premises sources, minimizing code changes. Option B (Data Fusion) does not directly replicate SSIS. Option C (Dataflow) requires rewriting SSIS packages. Option D (SSIS on Compute Engine) still needs migration and doesn't leverage BigQuery's strengths.

Answer

Connect SSIS to BigQuery using ODBC and run SSIS packages in a VM on Compute Engine.

Answer

Rewrite SSIS packages as Dataflow pipelines using Apache Beam.

Answer

Use Data Fusion to replicate SSIS packages.

Question 14

A company runs a batch job every night that processes large CSV files stored in Cloud Storage. The job runs on a single Compute Engine VM and takes 4 hours to complete. The team wants to reduce execution time without increasing cost substantially. The job is CPU-intensive and can be parallelized. What should they do?

Accepted Answer

Split the input files into smaller chunks and use multiple VMs in a managed instance group with a job scheduler.. Option B is correct: splitting input files and using multiple VMs in a managed instance group leverages parallelism effectively. Option A (bigger VM) increases cost. Option C (Cloud Batch) still requires parallelization design. Option D (Dataproc) may introduce overhead and cost.

Answer

Migrate the job to Dataproc and run it as a Spark job.

Answer

Use Cloud Batch to run the job as a batch job that automatically scales.

Answer

Use a VM with more vCPUs and a higher CPU platform.

Question 15

A large e-commerce company runs a multi-tier application on Google Cloud. The frontend is served by a global HTTP Load Balancer with a backend service pointing to a managed instance group (MIG) of nginx web servers. The application tier consists of a regional internal TCP/UDP load balancer distributing traffic to a MIG of Java application servers. The database tier uses Cloud SQL for PostgreSQL in a failover replica configuration. The architecture is deployed in the us-central1 region across three zones. Recently, the operations team noticed intermittent 502 Bad Gateway errors from the frontend load balancer during peak traffic hours. The errors last for a few minutes and then recover. The team suspects the application tier is overwhelmed. They need to implement a solution that can handle traffic spikes without manual intervention. Which course of action should they take?

Accepted Answer

Configure HTTP health checks on the regional internal load balancer and set the autoscaler to use the 'HTTP load balancing utilization' metric for the application tier MIG.. Option C is correct because the intermittent 502 errors during peak traffic indicate that the application tier MIG is being overwhelmed. By configuring HTTP health checks on the regional internal load balancer and setting the autoscaler to use the 'HTTP load balancing utilization' metric, the autoscaler can scale the application tier MIG based on the actual load distribution from the internal load balancer, ensuring it handles traffic spikes without manual intervention. This directly addresses the root cause—insufficient application instances—by enabling dynamic scaling based on real-time utilization.

Answer

Increase the maximum number of instances in the application tier MIG from 10 to 20.

Answer

Enable Cloud Armor on the frontend load balancer with a rate-limiting rule to block excessive traffic.

Answer

Enable Cloud CDN on the frontend load balancer to cache static assets and reduce load on the application tier.