PCD Practice Test 9 — 10 Questions

Question 1

A company has a multi-region Cloud Run service with traffic splitting between revisions. They notice that a newly rolled-out revision is receiving 0% of traffic even though they set traffic to 100% via the console. The revision shows 'Ready: Yes'. What is the most likely cause?

Accepted Answer

The revision has a tag but no traffic percentage assigned; the tag is being used for routing.. When a revision shows 'Ready: Yes' but receives 0% traffic despite setting 100% via the console, the most likely cause is that the revision has a tag assigned but no traffic percentage. In Cloud Run, tags are used for direct URL routing (e.g., for testing) and do not receive any traffic from the service's main URL unless a traffic percentage is explicitly assigned. The console's traffic splitting UI allows setting a tag without a percentage, which can lead to this confusion.

Answer

The revision has a low CPU limit causing it to be throttled.

Answer

The revision is not healthy because of a misconfigured health check.

Answer

The revision has a concurrency setting of 0, which is invalid.

Question 2

During a deployment to App Engine flexible environment, the new version fails to start and the logs show 'Container failed to start: context deadline exceeded'. The previous version remains serving traffic. What is the most likely cause?

Accepted Answer

The container startup time exceeds the 10-minute timeout.. Option C is correct because the error 'context deadline exceeded' in App Engine flexible environment indicates that the container did not start within the allowed startup timeout. The default timeout for container startup in App Engine flexible is 10 minutes, and if the application takes longer (e.g., due to slow initialization, large dependency downloads, or database migrations), the platform kills the container and logs this error. The previous version continues serving because the new version failed to become healthy.

Answer

The health check is misconfigured, causing the instance to be considered unhealthy.

Answer

The app requires an environment variable that is not set.

Answer

The Dockerfile has a syntax error that prevents the container from building.

Question 3

A developer deploys a Cloud Function (2nd gen) that processes messages from Pub/Sub. The function sometimes fails with 'Deadline Exceeded' for messages that take longer than 9 minutes. What should the developer do to handle these long-running messages without losing them?

Accepted Answer

Set the Pub/Sub subscription acknowledgment deadline to 10 minutes and implement a push endpoint that acknowledges after processing.. Option C is correct because Cloud Functions (2nd gen) have a maximum timeout of 60 minutes, but Pub/Sub push subscriptions have a default acknowledgment deadline of 10 seconds. By setting the acknowledgment deadline to 10 minutes and implementing a push endpoint that acknowledges after processing, the developer ensures the message is not redelivered prematurely while allowing the function up to 10 minutes to complete. This prevents 'Deadline Exceeded' errors for messages that take longer than 9 minutes without losing messages, as the subscription will wait for the acknowledgment before considering the message as failed.

Answer

Configure the function to retry on failure and set a maximum retry count.

Answer

Increase the Cloud Function timeout to 60 minutes.

Answer

Use Cloud Tasks instead of Pub/Sub for asynchronous invocation.

Question 4

A DevOps engineer is automating deployments to Compute Engine using a CI/CD pipeline. They want to minimize downtime and ensure that if a new VM fails health checks, the old VM continues serving. Which deployment strategy should they implement?

Accepted Answer

Blue/green deployment with health checks and a managed instance group. Blue/green deployment with health checks and a managed instance group is correct because it allows the new version (green) to be fully deployed and validated against health checks before any traffic is switched from the old version (blue). If the new VM fails health checks, the managed instance group automatically keeps the old version serving, ensuring zero downtime and immediate rollback without manual intervention.

Answer

Redeploy the old version manually if the new version fails

Answer

Rolling update with a readiness probe

Answer

Canary deployment with a small percentage of traffic

Question 5

A team deploys a containerized web application on Google Kubernetes Engine (GKE) using a Deployment. They need to expose the application externally via a stable IP address and enable SSL termination. Which resource should they use?

Accepted Answer

Ingress with Google-managed SSL certificate. An Ingress with a Google-managed SSL certificate is the correct choice because it provides a single stable IP address via a global forwarding rule, terminates SSL at the Google Cloud HTTP(S) load balancer, and routes traffic to the GKE Deployment. This approach offloads SSL decryption from the application pods and uses a managed certificate that auto-renews, meeting both the stable IP and SSL termination requirements.

Answer

HorizontalPodAutoscaler

Answer

Service type NodePort

Answer

Service type LoadBalancer

Question 6

A company wants to deploy a containerized application on Google Kubernetes Engine (GKE) with zero downtime during updates. The application is stateless and runs on a Deployment with 5 replicas. Which deployment strategy should be used?

Accepted Answer

Rolling update. A rolling update is the default deployment strategy in Kubernetes and is ideal for stateless applications requiring zero downtime. It gradually replaces old Pods with new ones, ensuring that a minimum number of replicas remain available throughout the update. This strategy is configured via the `strategy.type: RollingUpdate` field in the Deployment spec, with parameters like `maxSurge` and `maxUnavailable` controlling the pace.

Answer

Blue/green deployment

Answer

Recreate update

Answer

Canary deployment

Question 7

Which TWO statements about deploying applications on Google Kubernetes Engine (GKE) are correct?

Accepted Answer

HorizontalPodAutoscaler can use custom metrics from Cloud Monitoring.. HorizontalPodAutoscaler (HPA) in GKE can scale pods based on custom metrics from Cloud Monitoring (formerly Stackdriver). This is achieved by using the custom.metrics.k8s.io API, which allows HPA to query metrics like custom application latency or queue depth, not just default CPU/memory. This enables fine-grained, application-specific autoscaling.

Answer

Kubernetes Secrets are encrypted at rest by default.

Answer

A zonal GKE cluster automatically uses regional persistent disks for high availability.

Answer

To expose a Deployment externally, you must create an Ingress resource.

Question 8

A team is deploying a microservice application on Google Kubernetes Engine (GKE). They want to ensure high availability and minimize downtime during rolling updates. Which TWO actions should they take? (Choose two.)

Accepted Answer

Configure pod disruption budgets to limit the number of pods that can be unavailable simultaneously.. Option C is correct because PodDisruptionBudgets (PDBs) allow you to specify the minimum number of pods that must remain available during voluntary disruptions like rolling updates, ensuring high availability. Option D is correct because readiness probes control when a pod is added to a Service's endpoints; during rolling updates, they prevent traffic from being sent to a pod until it is ready, minimizing downtime.

Answer

Use Horizontal Pod Autoscaler to automatically adjust the number of pods based on CPU utilization.

Answer

Enable liveness probes to automatically restart pods that become unresponsive.

Answer

Enable node auto-repair to automatically replace unhealthy nodes.

Question 9

A company is running a microservices application on Google Kubernetes Engine (GKE). They have implemented Cloud Monitoring and Cloud Logging, but recently they noticed that the Istio-proxy sidecar logs are missing from Cloud Logging. The application pods are running correctly and the sidecar containers are present. What is the most likely cause of the missing logs?

Accepted Answer

The cluster was not created with the Istio on GKE add-on enabled, so proxy logs are not automatically collected.. Option B is correct because when using Istio on GKE, the Istio-proxy sidecar logs are automatically collected and sent to Cloud Logging only if the cluster was created with the 'Istio on GKE' add-on enabled. Without this add-on, the sidecar logs are not automatically forwarded, even though the sidecar containers are present and the application pods are running correctly. The add-on configures the necessary logging pipeline for Istio telemetry and logs.

Answer

The Istio-proxy logs are being sent to Stackdriver but are filtered by a log sink exclusion.

Answer

The Cloud Logging agent is not installed on the cluster nodes.

Answer

The sidecar container is not configured to output logs to stdout/stderr.

Question 10

Which THREE practices should be followed when deploying a containerized application to Cloud Run?

Accepted Answer

Avoid writing to the local filesystem for data that must persist across requests.. Option A is correct because Cloud Run instances are ephemeral and the local filesystem is not persisted across requests or instance restarts. Writing to local disk for data that must survive beyond a single request will cause data loss when the instance is recycled, which is a fundamental characteristic of serverless container platforms.

Answer

Set a maximum request timeout of 10 minutes to avoid cold starts.

Answer

Hardcode port 8080 in the container.