PCD Practice Test 35 — 15 Questions

Question 1

You are a Cloud Developer at a fintech company. Your team has developed a Node.js application that processes real-time financial transactions. The application is deployed on Cloud Run and uses Cloud Pub/Sub to receive transaction messages. The application must have high availability and low latency. Recently, the team noticed that during peak hours, the application experiences increased latency and some messages are not processed within the required 10-minute SLA. The team has configured Cloud Run with a minimum of 5 instances and a maximum of 50, with a concurrency setting of 80. The CPU usage per instance rarely exceeds 40% during peak times. The team also uses Cloud Monitoring and Logging for observability. After analyzing the logs, you find that the message processing time increases due to a database call that often takes 2-3 seconds. The Pub/Sub subscription is configured with a delivery deadline of 10 minutes. What should you recommend to reduce latency and ensure messages are processed within SLA?

Accepted Answer

Increase the concurrency setting to 200 to allow each instance to handle more requests simultaneously, reducing queuing.. Increasing the concurrency setting to 200 allows each Cloud Run instance to handle more requests simultaneously, which reduces the queuing delay caused by the 2-3 second database call. Since CPU usage is only 40%, the instances have headroom to process additional concurrent requests without being CPU-bound, directly addressing the latency issue within the 10-minute SLA.

Answer

Migrate the application to GKE with Horizontal Pod Autoscaler to scale based on custom metrics.

Answer

Increase the CPU limit per container to 2 CPUs to speed up database call.

Answer

Increase the minimum number of instances to 50 to ensure capacity during peak hours.

Question 2

A company uses Cloud Deploy for continuous delivery with multiple targets (dev, staging, prod). After a successful promotion to staging, the team discovers a critical bug and needs to roll back the production target to the previous release. The production target has already been promoted to the current release, but the staging target should remain on the current release. How should the team roll back the production target?

Accepted Answer

Use the 'gcloud deploy rollback' command targeting the production target.. Option B is correct because the 'gcloud deploy rollback' command is specifically designed to roll back a Cloud Deploy target to its previous successful release without affecting other targets. This command reverts the production target to the prior release while leaving the staging target on the current release, as required. It operates by redeploying the last known good release to the specified target, ensuring minimal disruption and preserving the promotion history.

Answer

Create a new release with the same image tag as the previous release and promote it to production.

Answer

Redeploy the previous release by running the previous Cloud Deploy command.

Answer

Manually delete the current release and then promote the previous release again.

Question 3

A team is using Cloud Spanner for a global application. They notice that read latency is high for queries that filter on a non-key column. The table has a primary key of (CustomerID, OrderDate) and there are millions of rows. The query uses a WHERE clause on the 'Status' column. The team wants to reduce latency without significantly increasing storage costs. What is the most effective action?

Accepted Answer

Create a secondary index on the 'Status' column.. Creating a secondary index on the 'Status' column (Option B) allows Cloud Spanner to directly locate rows matching the filter without scanning the entire table. This reduces read latency because Spanner can use the index to perform a point lookup or small range scan instead of a full table scan. Indexes in Spanner are stored as separate tables, but they add minimal storage overhead compared to the latency improvement they provide.

Answer

Create an interleaved table for 'Status' values.

Answer

Increase the number of nodes in the Spanner instance.

Answer

Use stale reads with a 15-second staleness.

Question 4

A company runs a containerized application on Google Kubernetes Engine (GKE) with a regional cluster. The application experiences intermittent slowdowns during peak hours. The team notices that the number of nodes is not scaling up quickly enough. The application consists of a frontend deployment with a HorizontalPodAutoscaler (HPA) targeting 80% CPU utilization, and the cluster has a Cluster Autoscaler enabled with a maximum of 10 nodes. During a recent spike, the HPA increased replicas, but the Cluster Autoscaler was slow to add nodes, causing the new pods to remain pending. What is the most likely cause of this delay?

Accepted Answer

The Cluster Autoscaler has a built-in delay before adding nodes to avoid flapping.. The Cluster Autoscaler includes a built-in cooldown period (default 10–15 minutes) to prevent flapping—rapidly adding and removing nodes in response to transient spikes. During this delay, pending pods cannot be scheduled on new nodes, which explains why the HPA increased replicas but the new pods remained pending. This is the most likely cause given that the cluster is regional and the autoscaler is enabled.

Answer

The cluster is configured with a single zone, limiting node pool expansion.

Answer

The HPA is using a custom metric that is not supported by the Cluster Autoscaler.

Answer

The node pool's autoscaling is limited by the quota for Compute Engine resources in that zone.

Question 5

A company is migrating a legacy Java application to Cloud Run. The application requires a specific Java version (Java 11) and writes temporary files to disk. The application also uses a proprietary library that is not available in public repositories. The team has created a Dockerfile that installs Java 11, copies the JAR file, and sets the entrypoint. They are using Cloud Build to build the container and deploying to Cloud Run. The deployment succeeds, but when they send requests, the application fails with a "Permission denied" error when trying to write to /tmp. The team has verified that the Cloud Run service has the correct permissions via a service account. They have also checked that the filesystem is writable at /tmp by default. What is the most likely cause of the error?

Accepted Answer

Change the base image to one that includes Java 11 and ensures the /tmp directory is writable.. Option B is correct because the base image used might not have the proper filesystem layout or permissions for /tmp. Using a standard base image like gcr.io/distroless/java or an official OpenJDK image ensures that /tmp is writable. Option A is incorrect because memory limits do not affect write permissions. Option C is incorrect because if the filesystem is read-only, chmod will also fail; moreover, Cloud Run's security constraints may prevent such changes. Option D is incorrect because Cloud Storage FUSE is not needed and adds complexity; the issue is with the base image.

Answer

Add a RUN chmod 777 /tmp command in the Dockerfile before the entrypoint.

Answer

Increase the memory limit of the Cloud Run service.

Answer

Use a Cloud Storage FUSE mount for temporary storage.

Question 6

A company is deploying a static website on Cloud Storage with a custom domain. They want to serve the website over HTTPS. They have created a bucket with the same name as the domain and uploaded the files. They have verified the domain ownership in Search Console and added the bucket as a CNAME record in their DNS. Users report that when they navigate to the domain, they get a 404 error. The company has verified that the bucket's main page suffix is set to index.html. The team is confident the files are uploaded correctly. They need to resolve the 404 error and serve the site over HTTPS. What should they do?

Accepted Answer

Create a Cloud Load Balancer with the bucket as backend and update DNS.. Option C is correct because to serve a static website on Cloud Storage with a custom domain and HTTPS, you must use a Cloud Load Balancer (HTTP(S) LB) with the bucket as the backend, and then point your DNS to the load balancer's IP address. Option A is incorrect because you cannot point an A record directly to a bucket; Cloud Storage does not provide a static IP. Option B is incorrect because Cloud CDN improves performance but does not enable HTTPS for a custom domain. Option D is incorrect because setting public ACLs is not sufficient for HTTPS; you still need a load balancer for SSL termination.

Answer

Add a DNS A record pointing to the load balancer IP instead of a CNAME.

Answer

Enable Cloud CDN on the bucket.

Answer

Set the bucket's default object ACL to public read.

Question 7

You are deploying a Node.js application on Cloud Run. The container image is stored in Artifact Registry. After deploying with gcloud run deploy, the revision fails with 'Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.' The application listens on port 8080 by default. The Dockerfile uses EXPOSE 8080. The Cloud Run service is configured with container port 8080. You have verified that the container starts locally using docker run -p 8080:8080. What is the most likely cause of the startup failure?

Accepted Answer

The application is hardcoded to listen on port 8080 but the Cloud Run environment variable PORT may override it to a different value.. Option A is correct because Cloud Run sets the PORT environment variable to 8080 by default, but if the application is hardcoded to listen on 8080 instead of reading PORT, it may fail if the variable is not set or incorrect. Option B is wrong because the DEFAULT port variable is not used. Option C is wrong because the container port is set correctly. Option D is wrong because port 8080 is not privileged.

Answer

The application is trying to bind to a privileged port.

Answer

The Cloud Run service is configured with container port 443 by default.

Answer

The container does not have a proper HEALTHCHECK instruction.

Question 8

A team is deploying a containerized application to Google Kubernetes Engine using a Deployment and a Service of type LoadBalancer. The application is a web server that should be accessible on port 80. After deployment, the external IP is assigned, but when they try to access http://<EXTERNAL_IP>:80, they get a connection timeout. The pods are running, and the logs show the web server is listening on port 8080. The team has verified that the cluster firewall rules allow traffic on port 80. They have also confirmed that the pods are healthy and no network policies are in place. What is the most likely cause?

Accepted Answer

The Deployment's containerPort is set to 8080, but the Service's port is set to 80 and targetPort is not specified.. Option B is correct because if the Service's targetPort is not specified, it defaults to the same value as the port (80). However, the container is listening on port 8080, so traffic forwarded to port 80 on the pod results in a connection timeout. Option A is incorrect because having targetPort set to 80 would be incorrect; it should be 8080. Option C is incorrect because externalTrafficPolicy: Local affects client IP preservation, not basic connectivity. Option D is incorrect because network policies are not in place and firewall rules allow traffic.

Answer

The cluster has a network policy that blocks incoming traffic.

Answer

The Service is missing the externalTrafficPolicy: Local setting.

Answer

The Service's targetPort is set to 80 instead of 8080.

Question 9

A company is deploying a batch job that runs once a day on Compute Engine. They are using a startup script to install dependencies and run the job. The job writes output to Cloud Storage. Recently, the job started failing intermittently with "No space left on device" errors, even though the persistent disk has 100 GB free. The team has verified that the disk is not fragmented and that the inode usage is low. The job processes large files and creates many temporary files in /tmp. They suspect the /tmp directory is filling up. What is the most likely cause?

Accepted Answer

The /tmp partition is using a small temporary disk that is separate from the persistent disk.. Option A is correct because on many Compute Engine images, /tmp is mounted as a tmpfs (in-memory filesystem) which has a limited size, often a fraction of the instance's memory. When the job creates many temporary files, it can fill the tmpfs, causing "No space left on device" even though the persistent disk has ample free space. Option B is incorrect because while cleanup would help, the root cause is limited space in /tmp. Option C is incorrect because insufficient RAM would cause swapping, not a filesystem full error. Option D is incorrect because Cloud Storage quota would produce errors when writing to the bucket, not on the local filesystem.

Answer

The instance's RAM is insufficient, causing swap to fill the disk.

Answer

The startup script is not cleaning up temporary files.

Answer

The Cloud Storage bucket quota is exceeded.

Question 10

Your company runs a multi-tier application on GKE. The frontend is a Deployment with 5 replicas, backend is a StatefulSet with 3 replicas, and a database runs on Cloud SQL. Recently, after a cluster upgrade, the frontend pods are failing with 'Connection refused' errors when trying to reach the backend service. The backend pods are running and healthy. You have verified that the Service and Endpoints objects exist. The backend service is of type ClusterIP on port 8080, and the frontend uses the service name 'backend-svc'. The frontend pods are in a different namespace 'frontend-ns', while the backend is in 'backend-ns'. What is the most likely cause of the error?

Accepted Answer

The frontend pods are not using the correct DNS name that includes the namespace.. Option C is correct because the frontend is in a different namespace and not using the fully qualified DNS name (backend-svc.backend-ns.svc.cluster.local) or the namespace is not properly configured for DNS resolution. Option A is wrong because the service type ClusterIP does not require a firewall rule. Option B is wrong because the StatefulSet is backed by a Service that provides DNS. Option D is wrong because network policy would cause timeout not connection refused.

Answer

The backend Service is not exposed via an Ingress, so it is not reachable from other namespaces.

Answer

The StatefulSet pods are not part of the backend Service's selector.

Answer

A NetworkPolicy is blocking traffic between the namespaces.

Question 11

A startup is deploying a Node.js application on App Engine Standard Environment. They have configured the application in app.yaml with runtime: nodejs16. After deploying with gcloud app deploy, the deployment succeeds, but when they access the application, they get a 502 Bad Gateway error. They check the logs and see "Failed to start container" and "Error: Cannot find module 'express'". The application uses Express. The team has confirmed that the package.json file includes express as a dependency. What is the most likely cause?

Accepted Answer

The node_modules folder was not uploaded because it is in the .gcloudignore file.. Option A is correct because the error indicates that the express module cannot be found. This typically happens if npm install was not run or if node_modules was not included in the deployment. In App Engine Standard, dependencies are automatically installed based on package.json, but if the node_modules folder is present in the project directory and contains an incomplete install, it might cause issues. However, the most common reason is that the node_modules folder was not uploaded because it is listed in .gcloudignore, preventing the automatic install. Option B is the direct cause. Option C is incorrect because a port mismatch would cause a different error. Option D is incorrect because timeout errors are logged as such.

Answer

The application is running on a different port than the one specified in the environment variable PORT.

Answer

The package.json file is missing the express dependency.

Answer

The request exceeds the 60-second timeout.

Question 12

You are a developer at a company that runs a critical pricing engine on Compute Engine instances in a managed instance group (MIG) behind an internal TCP load balancer. The pricing engine is a stateful application that stores state in memory and also writes to a Cloud Bigtable instance for persistence. The application uses a custom port 8080. You need to migrate this application to Cloud Run for better scalability and reduced operational overhead. The application must maintain session affinity so that requests from the same client are routed to the same instance (since the in-memory state is not yet fully externalized). The application currently uses a health check on /healthz that returns 200 OK. You have containerized the application. When you deploy to Cloud Run, you notice that traffic is not sticky; every request might go to a different revision. You also need to ensure that Bigtable writes are performed asynchronously to avoid slowing down the pricing calculations. What should you do?

Accepted Answer

Use Cloud Run with an HTTP(S) External Load Balancer and enable session affinity on the backend service.. Option B is correct because Cloud Run does not support session affinity natively; to achieve stickiness, you need to set the session affinity feature on the external HTTP(S) load balancer and place Cloud Run behind it. Option A is wrong because increasing concurrency does not affect stickiness. Option C is wrong because even with an internal load balancer, Cloud Run does not support session affinity directly; you need an external load balancer with session affinity. Option D is wrong because Cloud Run does not support custom health checks with TCP; it only supports HTTP health checks.

Answer

Implement a custom health check on TCP port 8080 in Cloud Run to ensure only healthy instances receive traffic.

Answer

Increase the container concurrency setting to 1 to force each container to handle one request at a time.

Answer

Deploy the application on Cloud Run and configure an Internal TCP/UDP Load Balancer in front of it with session affinity.

Question 13

A developer is deploying a 2nd gen Cloud Function that needs to connect to a Cloud SQL MySQL instance. The Cloud SQL instance is configured with a private IP only. The Cloud Function is deployed with a VPC connector that is connected to the same VPC network as the Cloud SQL instance. The developer has granted the Cloud Function's service account the Cloud SQL Client role. However, when the function is invoked, connection attempts to the Cloud SQL instance time out. The Cloud Function code uses the MySQL connector with the private IP address of the Cloud SQL instance. The developer has verified that the VPC connector is healthy and that the Cloud SQL instance is running. Which additional configuration is most likely required?

Accepted Answer

Configure Private Services Access to establish a VPC peering between the VPC network and the Cloud SQL service network.. Option A is correct. Even though the VPC connector is on the same VPC network as Cloud SQL, the Cloud SQL private IP address is allocated from a private services access range that is not automatically routed. You must set up Private Services Access to create a route from the VPC to the Cloud SQL private IP range. Without this, traffic from the VPC connector cannot reach the Cloud SQL instance. Option B is incorrect because the Cloud Function is using a VPC connector, so it does not need or use a public IP. Option C is incorrect because the Cloud SQL Auth proxy is not needed for private IP connections. Option D is incorrect because SSL/TLS configuration would cause a TLS handshake error, not a timeout.

Answer

Modify the connection string to require SSL/TLS.

Answer

Deploy the Cloud SQL Auth proxy as an additional container in the Cloud Function.

Answer

Assign a public IP to the Cloud SQL instance and configure the function to use it.

Question 14

You are building a data pipeline that ingests streaming data from thousands of IoT devices. The devices send JSON payloads to a Cloud Pub/Sub topic. You want to process the data in near real-time and store the results in BigQuery for analytics. You also need to handle occasional schema changes in the incoming data (new fields added) without manual intervention. You have set up a Dataflow streaming pipeline using Apache Beam to read from Pub/Sub and write to BigQuery. The pipeline uses the `WriteToBigQuery` transform with `createDisposition=CREATE_NEVER` and `writeDisposition=WRITE_APPEND`. Recently, a batch of devices started sending a new field `temperature_celsius` that does not exist in the BigQuery schema. The pipeline logs errors and the data is not written. You need to modify the pipeline to automatically handle such schema evolution. What should you do?

Accepted Answer

Change `createDisposition` to `CREATE_IF_NEEDED` and ensure the BigQuery table schema has `autodetect=true` or is updated to allow new fields.. Option A is correct because with `createDisposition=CREATE_IF_NEEDED`, BigQuery will automatically add new fields if the schema allows updates. This is the simplest approach. Option B is wrong because storing raw data in Cloud Storage and then loading later loses real-time capability. Option C is wrong because Dataflow does not have a transform that automatically flattens schemas without modification. Option D is wrong because updating the table schema manually defeats the purpose of automation.

Answer

Manually update the BigQuery table schema to include the new field and then restart the pipeline.

Answer

Write the raw JSON payloads to Cloud Storage and use a Cloud Function to load them into BigQuery every 10 minutes with schema autodetect.

Answer

Use a `ParDo` transform to flatten all JSON fields into a fixed schema by ignoring unknown fields.

Question 15

Your organization runs a multi-region application on Cloud Run that serves an API. The API is consumed by clients worldwide. You want to reduce latency by routing users to the nearest regional Cloud Run service. Currently, all traffic goes to a single Cloud Run service in us-central1. You have set up additional Cloud Run services in europe-west1 and asia-east1. Each service is fronted by an external HTTPS load balancer with a regional backend. You want to use a single global anycast IP address that automatically directs users to the closest healthy backend. You also need to support HTTPS with a custom domain and a Google-managed certificate. What should you do?

Accepted Answer

Create a global external HTTPS load balancer with serverless NEGs pointing to each regional Cloud Run service, and attach a Google-managed certificate.. Option D is correct because an External HTTPS Load Balancer with a global backend service can route traffic to the closest backend via the Google Front Ends (GFE). The regional Cloud Run services can be added as backends with the appropriate network endpoint groups (NEGs). Option A is wrong because Cloud CDN caches content but does not route based on locality. Option B is wrong because Cloud DNS with geo-routing can direct to different IPs, but that is not a single anycast IP. Option C is wrong because Cloud Run does not support anycast itself.

Answer

Enable anycast on the Cloud Run service by selecting the 'global' setting in the Cloud Run region selection.

Answer

Use Cloud DNS with geo-routing policy to point users to the appropriate regional load balancer IP based on their location.

Answer

Configure Cloud CDN in front of the Cloud Run services to cache responses at edge locations.