Courseiva

CCNA Deploying Apps Questions

75 of 88 questions · Page 1/2 · Deploying Apps topic · Answers revealed

Practice these questionsExam hubAll questions
1
MCQeasy

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?

A.HorizontalPodAutoscaler
B.Ingress with Google-managed SSL certificate
C.Service type NodePort
D.Service type LoadBalancer
AnswerB

Provides SSL termination and a stable IP via the load balancer.

Why this answer

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.

Exam trap

In the Google Cloud PCD exam, candidates often mistakenly believe a Service type LoadBalancer handles SSL termination. However, it provides only L4 load balancing with a stable IP. SSL termination requires an L7 Ingress with a Google-managed SSL certificate or a dedicated SSL proxy instance.

How to eliminate wrong answers

Option A is wrong because a HorizontalPodAutoscaler only adjusts the number of pod replicas based on CPU/memory metrics and does not expose the application externally or handle SSL termination. Option C is wrong because a Service type NodePort exposes the application on a high-port on each node's IP, which is not a stable IP address and does not provide SSL termination. Option D is wrong because a Service type LoadBalancer creates a regional TCP/UDP load balancer with an ephemeral external IP (unless static IP is manually reserved) and does not natively terminate SSL; it would require additional configuration like a separate SSL proxy or an Ingress.

Practice this question →
2
MCQhard

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?

A.The revision has a low CPU limit causing it to be throttled.
B.The revision is not healthy because of a misconfigured health check.
C.The revision has a tag but no traffic percentage assigned; the tag is being used for routing.
D.The revision has a concurrency setting of 0, which is invalid.
AnswerC

If a revision has a tag, it may be accessible only via that URL; without a traffic percentage, it won't serve at the default URL.

Why this answer

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.

Exam trap

The trap here is that candidates assume setting traffic to 100% in the console automatically distributes traffic to the latest revision, but they overlook that a tag can override this behavior by creating a separate routing path without a traffic percentage.

How to eliminate wrong answers

Option A is wrong because a low CPU limit would cause throttling or performance degradation, not a complete 0% traffic assignment; Cloud Run still routes traffic to the revision even if it is throttled. Option B is wrong because if the revision were unhealthy due to a misconfigured health check, the revision would show 'Ready: No' or be in a failed state, not 'Ready: Yes'. Option D is wrong because a concurrency setting of 0 is invalid and would cause a deployment error or revision failure, not a 0% traffic split with a healthy revision.

Practice this question →
3
MCQeasy

A startup wants to deploy a web application on App Engine standard environment. They need to handle sudden traffic spikes automatically. How should they configure scaling?

A.Use automatic scaling.
B.Use basic scaling with idle timeout.
C.Use manual scaling with a fixed number of instances.
D.Use a combination of manual and automatic scaling.
AnswerA

Automatic scaling adjusts instance count based on traffic.

Why this answer

Automatic scaling is the correct choice because App Engine standard environment natively supports automatic scaling, which dynamically adds or removes instances based on request rate, latency, and other metrics. This allows the application to handle sudden traffic spikes without manual intervention, as the platform automatically provisions resources to meet demand.

Exam trap

The trap is that basic scaling might seem appropriate because it can start instances on demand, but it introduces startup latency and does not automatically scale down based on load, making automatic scaling the better choice for handling sudden traffic spikes in App Engine standard environment.

How to eliminate wrong answers

Option B is wrong because basic scaling requires instances to be manually started and stopped, and while it can handle spikes, it relies on an idle timeout to shut down instances, which is not designed for automatic, seamless handling of sudden traffic spikes. Option C is wrong because manual scaling uses a fixed number of instances, which cannot automatically adjust to traffic spikes, leading to potential over-provisioning or under-provisioning. Option D is wrong because App Engine does not support a combination of manual and automatic scaling; you must choose one scaling type for the entire service.

Practice this question →
4
Multi-Selecteasy

Which TWO features are provided by Google Cloud Deploy? (Choose 2.)

Select 2 answers
A.Rollback to a previous deployment revision.
B.Run containers without managing infrastructure.
C.Automated canary analysis based on deployment verification.
D.Build container images from source code.
E.Manage Kubernetes clusters across multi-cloud environments.
AnswersA, C

Cloud Deploy supports rollbacks.

Why this answer

Google Cloud Deploy is a managed continuous delivery service that automates the rollout of applications to Google Kubernetes Engine (GKE) or GKE Enterprise clusters. It supports rollback to a previous deployment revision (A) by reverting the target cluster to the last known good state, and it provides automated canary analysis (C) by integrating with Cloud Monitoring to verify deployment health metrics before progressing traffic shifts.

Exam trap

Google Cloud often tests the distinction between deployment orchestration (Cloud Deploy) and other GCP services like Cloud Build (image building) or Cloud Run (serverless compute), so candidates mistakenly associate Cloud Deploy with building images or managing infrastructure.

Practice this question →
5
MCQhard

A company deploys a stateful application using StatefulSets on GKE. They need to store persistent data on regional persistent disks for high availability. However, during zonal failures, pods are not rescheduled quickly. What is the best approach to improve recovery time?

A.Increase the number of replicas in the StatefulSet.
B.Configure podDisruptionBudget and use persistent disk with regional replication.
C.Use a headless service with external persistent storage like Filestore.
D.Use a Deployment instead of StatefulSet.
AnswerB

Regional PDs replicate across zones and PDB ensures minimum available pods during disruptions.

Why this answer

Configuring a podDisruptionBudget ensures that a minimum number of Pods remain available during voluntary disruptions, while using regional persistent disks (which replicate data across zones) allows the StatefulSet controller to quickly reschedule Pods in another zone without waiting for the failed zone's disk to become available. This combination minimizes downtime during zonal failures by maintaining quorum and ensuring data is already accessible in the surviving zone.

Exam trap

The PCD exam often tests the misconception that increasing replicas alone improves availability during zonal failures, but the real bottleneck is the persistent volume's zonal binding, which requires regional replication to allow cross-zone attachment.

How to eliminate wrong answers

Option A is wrong because increasing the number of replicas does not address the root cause of slow rescheduling during zonal failures; it only spreads Pods across more nodes but still relies on the same regional disk, which may be stuck in the failed zone. Option C is wrong because using a headless service with external persistent storage like Filestore changes the storage architecture but does not inherently improve recovery time for StatefulSets; Filestore is a network file system that introduces latency and does not provide the same zonal failover guarantees as regional PDs. Option D is wrong because using a Deployment instead of StatefulSet would lose the ordered pod identity and stable storage mapping required for stateful applications, and Deployments do not guarantee that each Pod gets its own persistent volume, which can lead to data corruption or loss.

Practice this question →
6
Multi-Selecthard

Which THREE methods are valid ways to deploy a containerized application to Google Kubernetes Engine (GKE)?

Select 3 answers
A.Use Helm to install a chart.
B.Use gcloud container clusters create to deploy the application.
C.Upload the container image to Cloud Storage and use a trigger to deploy.
D.Use kubectl apply with a Deployment manifest.
E.Use Config Connector to create a KubernetesDeployment resource.
AnswersA, D, E

Helm is a package manager for Kubernetes.

Why this answer

Helm is a package manager for Kubernetes that simplifies deploying containerized applications by using pre-configured charts. A Helm chart packages all the necessary Kubernetes resource definitions (e.g., Deployments, Services) into a single deployable unit, and running `helm install` on a GKE cluster will deploy the application correctly.

Exam trap

Google PCD often tests the distinction between cluster management commands (`gcloud container clusters`) and application deployment commands (`kubectl`, `helm`), and the trap here is that candidates mistakenly think `gcloud container clusters create` deploys an application because it creates a cluster, but it only provisions the cluster infrastructure.

Practice this question →
7
MCQhard

A developer uses this Cloud Build configuration to deploy to Cloud Run. The build succeeds but the deployment fails with an error that the service account lacks permission. What is the most likely missing permission?

A.roles/iam.serviceAccountUser on the Compute Engine default service account.
B.roles/iam.serviceAccountUser on the Cloud Build service account.
C.roles/storage.objectViewer on the container registry.
D.roles/run.admin on the Cloud Run service.
AnswerB

The Cloud Build service account needs to impersonate the runtime service account (default Compute Engine service account) to deploy Cloud Run services.

Why this answer

The Cloud Build service account (typically the default compute engine service account or a user-specified service account) needs the `roles/iam.serviceAccountUser` role on the Cloud Run service account to impersonate it during deployment. Without this permission, Cloud Build cannot act as the Cloud Run service account to deploy the revision, even though the build itself succeeds. This is a common misconfiguration when deploying to Cloud Run from Cloud Build.

Exam trap

Google Cloud certification exams often test the distinction between permissions needed to *use* a service account (iam.serviceAccountUser) versus permissions to *administer* a resource (run.admin), leading candidates to incorrectly choose the broader admin role.

How to eliminate wrong answers

Option A is wrong because the Compute Engine default service account is not the identity used by Cloud Build to deploy; Cloud Build uses its own service account (or a user-specified one) to impersonate the Cloud Run service account. Option C is wrong because `roles/storage.objectViewer` on the container registry is needed for pulling container images, but the error is about deployment permissions, not image access. Option D is wrong because `roles/run.admin` grants full management of Cloud Run services, but the missing permission is specifically the ability for Cloud Build to impersonate the Cloud Run service account, which requires `roles/iam.serviceAccountUser` on that service account, not the `run.admin` role.

Practice this question →
8
MCQhard

A company runs a Java microservice on Google Kubernetes Engine (GKE) using a standard cluster with 3 nodes. They use Cloud Build to build the Docker image and push it to Artifact Registry, then apply a Kubernetes Deployment manifest that references the new image tag. The Deployment has a rolling update strategy with maxSurge=1 and maxUnavailable=0. After a recent deployment, the new pods crash with 'CrashLoopBackOff'. The old pods are still running successfully. The application logs show a connection refused error when trying to connect to a Cloud SQL instance. The Cloud SQL instance is in the same project and region. The GKE cluster nodes have the appropriate scopes to access Cloud SQL. The application uses a Cloud SQL proxy sidecar container to establish the connection. The previous deployment worked fine. What is the most likely cause of the failure?

A.The GKE cluster nodes do not have the Cloud SQL Client role.
B.The Cloud SQL proxy sidecar container is not included in the new Deployment revision.
C.The Kubernetes Secret containing the service account key was not updated to include the new pod's service account.
D.The new image tag points to a broken build that has incorrect code for Cloud SQL connection.
AnswerB

Correct. Without the sidecar, the application cannot connect to Cloud SQL, resulting in connection refused.

Why this answer

The Cloud SQL proxy sidecar container is missing from the new Deployment revision. Since the application relies on the sidecar to establish a secure connection to Cloud SQL, its absence causes the connection refused error. The old pods continue to run because they still have the sidecar from the previous Deployment revision, while the new pods crash due to the missing proxy.

Exam trap

The PCD exam often tests the misconception that a connection refused error implies a code or permission issue, when in fact it is a missing sidecar container that causes the failure, especially in scenarios where the sidecar is defined in the Deployment manifest and accidentally removed during a revision update.

How to eliminate wrong answers

Option A is wrong because the GKE cluster nodes have the appropriate scopes to access Cloud SQL, and the Cloud SQL Client role is an IAM role assigned to the service account, not a scope on the nodes; the sidecar proxy handles authentication. Option C is wrong because the Kubernetes Secret containing the service account key is not relevant here—the Cloud SQL proxy sidecar typically uses Workload Identity or a service account key mounted as a volume, but the issue is the sidecar container itself being absent, not a missing or outdated secret. Option D is wrong because the new image tag points to a build that likely has correct code; the connection refused error is due to the missing sidecar proxy, not a code defect in the application.

Practice this question →
9
MCQmedium

A company is deploying a containerized application on Google Kubernetes Engine (GKE). The development team has built a Docker image and pushed it to Artifact Registry. They want to automate the deployment process so that whenever a new image is pushed to the registry, the application is automatically updated in the GKE cluster. Which combination of services should they use to achieve this?

A.Use Cloud Deploy to create a delivery pipeline that watches the Artifact Registry and promotes the image to GKE.
B.Set up a Cloud Build trigger that monitors the Artifact Registry and runs a build step to update the GKE deployment using kubectl.
C.Schedule a Cloud Scheduler job that periodically checks for new images in Artifact Registry and updates the GKE deployment.
D.Configure a Cloud Run service that is automatically deployed when a new image is pushed to Artifact Registry.
AnswerB

Correct: Cloud Build can be triggered by an Artifact Registry push and execute kubectl commands to update the deployment.

Why this answer

Cloud Build can be configured with a trigger that monitors Artifact Registry for new image pushes. When a new image is pushed, the trigger executes a build step that uses kubectl to update the GKE deployment, enabling continuous deployment without manual intervention.

Exam trap

The trap here is confusing Cloud Deploy's pipeline capabilities with event-driven triggers, leading candidates to choose Option A, but Cloud Deploy requires an explicit trigger (like a Cloud Build invocation) and does not directly watch Artifact Registry for image pushes.

How to eliminate wrong answers

Option A is wrong because Cloud Deploy does not natively watch Artifact Registry for image pushes; it is designed for managing delivery pipelines with Skaffold and requires explicit triggers or integration with Cloud Build. Option C is wrong because Cloud Scheduler is a cron-based job scheduler that does not react to events in real time; it would introduce latency and inefficiency by polling, and it lacks native integration to detect new images. Option D is wrong because Cloud Run is a serverless compute platform for stateless containers, not a deployment automation service for GKE; it cannot update a GKE cluster's deployment.

Practice this question →
10
Multi-Selectmedium

A team is deploying a new version of an application on GKE using a rolling update. They want to ensure that the update proceeds only if the new pods are healthy. Which two steps should they include? (Choose two.)

Select 2 answers
A.Set the minReadySeconds field in the deployment.
B.Define a readiness probe for the container.
C.Define a liveness probe for the container.
D.Set the revisionHistoryLimit to 10.
E.Use a postStart lifecycle hook to test health.
AnswersA, B

minReadySeconds ensures the pod is ready for that duration before being considered available.

Why this answer

Setting `minReadySeconds` in a Deployment ensures that a newly created Pod is considered ready only after it has been stable for that duration, preventing the rolling update from proceeding if the Pod fails shortly after startup. Option B is correct because a readiness probe determines whether a Pod is ready to serve traffic; during a rolling update, the Deployment controller waits for the new Pod's readiness probe to succeed before scaling down old Pods, ensuring the update only continues when new Pods are healthy.

Exam trap

The PCD exam often tests the distinction between readiness and liveness probes, and the trap here is that candidates confuse liveness probes (which restart containers) with readiness probes (which control traffic and rolling update progression), leading them to incorrectly select a liveness probe as a health gate for the update.

Practice this question →
11
Multi-Selecthard

A company wants to automate the deployment of a microservice application to Cloud Run using Cloud Build. They want to ensure zero-downtime deployments and traffic migration. Which three features should they utilize? (Choose three.)

Select 3 answers
A.Cloud Build triggers to build and deploy on code changes.
B.Cloud Run min and max instance settings.
C.Cloud Run managed continuous deployment from a repository.
D.Cloud Run gradual rollout with --no-traffic flag.
E.Cloud Run revision traffic splitting.
AnswersA, D, E

Triggers automate the build and deploy pipeline on code changes.

Why this answer

Cloud Build triggers can be configured to automatically build and deploy a microservice to Cloud Run whenever code changes are pushed to a repository. This enables continuous delivery and ensures that the latest code is deployed without manual intervention, supporting zero-downtime deployments when combined with traffic management features.

Exam trap

Google often tests the distinction between features that enable automation (like triggers) versus features that manage traffic (like splitting and no-traffic flags), and the trap here is that candidates might select 'managed continuous deployment' (C) as a separate feature when it is actually a combination of triggers and deployment settings, leading to an incorrect count of three distinct features.

Practice this question →
12
MCQmedium

Your company is deploying a web application on Cloud Run using a continuous deployment pipeline from Cloud Build. The application is built as a Docker container and pushed to Container Registry. The Cloud Run service is configured with the '--no-allow-unauthenticated' flag. You have set up Cloud Build triggers to build and deploy on commits to the main branch. The deployment works correctly for the first few commits, but after adding a new environment variable in the Cloud Build configuration file (cloudbuild.yaml), the deployment fails with an error that the Cloud Run service cannot be updated because the new revision fails health checks. The application code has not changed. What is the most likely cause?

A.The Cloud Build service account does not have permission to update the Cloud Run service.
B.The new environment variable exceeds the maximum size limit for environment variables in Cloud Run.
C.The health check configuration in the Cloud Run service was overwritten by the new deployment.
D.The new environment variable causes the application to fail its startup or health check.
AnswerD

A misconfigured environment variable can cause the app to crash.

Why this answer

The application code has not changed, yet the deployment fails health checks immediately after adding a new environment variable. This indicates that the application is likely reading that variable at startup and crashing or failing its readiness probe due to an invalid value, missing dependency, or misconfiguration. Cloud Run requires the new revision to pass health checks (e.g., HTTP GET on the configured port) before it can serve traffic; if the variable causes the app to exit or hang, the revision is considered unhealthy and the update is rejected.

Exam trap

The PCD exam often tests the misconception that environment variables are harmless metadata and cannot cause deployment failures, when in fact they can break application startup logic or health check responses.

How to eliminate wrong answers

Option A is wrong because the Cloud Build service account already successfully deployed the first few revisions, so permissions are not the issue. Option B is wrong because Cloud Run environment variables have a total size limit of 64 KB for all variables combined, and a single new variable is extremely unlikely to exceed that. Option C is wrong because Cloud Run health check configuration (startup, liveness, readiness probes) is defined in the service YAML or via gcloud flags and is not overwritten by adding an environment variable in cloudbuild.yaml; the health check settings remain unchanged.

Practice this question →
13
Multi-Selecthard

Which THREE common issues cause deployment failures on App Engine? (Choose 3.)

Select 3 answers
A.Using a runtime version that is not available in the app's region.
B.Exceeding the maximum file size limit for application files.
C.Setting the app to scale to 0 instances.
D.Uploading a configuration file (e.g., cron.yaml) with invalid syntax.
E.Creating a resource with backend type set to 'backend' instead of 'frontend'.
AnswersA, B, D

Some runtimes may not be available everywhere.

Why this answer

App Engine requires that the runtime version specified in your app.yaml is available in the region where the application is deployed. If you select a runtime version that has been deprecated or is not yet rolled out to that region, the deployment will fail with an error indicating the runtime is unavailable. This is a common issue when using newer runtime versions that are only available in certain regions.

Exam trap

A common misconception is that App Engine Standard cannot scale to zero instances. In reality, App Engine Standard supports automatic scaling with min_instances set to 0, allowing instances to scale down to zero when there is no traffic. The flexible environment, however, requires at least one instance.

This question tests the understanding that scaling to zero instances is a valid configuration in App Engine Standard, so it is not a common cause of deployment failure.

Practice this question →
14
MCQeasy

You are setting up Cloud Build to automatically deploy a container to Cloud Run when code is pushed to the main branch of a GitHub repository. What is the minimal configuration required?

A.Create a Cloud Build trigger connected to GitHub, and include a cloudbuild.yaml with steps to build and deploy.
B.Set up GitHub Actions to push images to Container Registry and then use Cloud Run.
C.Create a Cloud Build trigger without a build config file, using the inline builder.
D.Use Artifact Registry to store images and then manually trigger deployment.
AnswerA

Correct because Cloud Build triggers can be configured to automatically execute a build pipeline when code is pushed to a GitHub repository, and a cloudbuild.yaml file defines the steps to build and deploy.

Why this answer

Cloud Build triggers can be configured to automatically execute a build pipeline when code is pushed to a GitHub repository. The minimal configuration requires a trigger connected to GitHub and a cloudbuild.yaml file that defines the steps to build the container image and deploy it to Cloud Run using the `gcloud run deploy` command or the `cloudrun` builder. This setup provides a fully automated CI/CD pipeline without additional services.

Exam trap

The trap here is that candidates may think an inline builder (Option C) is simpler than a cloudbuild.yaml file, but the exam expects the standard, minimal, and documented approach of using a build config file for clarity and maintainability.

How to eliminate wrong answers

Option B is wrong because it introduces GitHub Actions as an intermediary, which is not minimal; Cloud Build can directly integrate with GitHub to trigger builds without requiring GitHub Actions. Option C is wrong because while an inline builder can be used, the question asks for the minimal configuration to automatically deploy to Cloud Run, and a cloudbuild.yaml file is the standard and most straightforward way to define build and deploy steps; omitting it would require more complex inline configuration. Option D is wrong because manually triggering deployment defeats the purpose of automation when code is pushed to the main branch; the requirement is for automatic deployment, not manual intervention.

Practice this question →
15
Multi-Selectmedium

Which TWO security best practices should be implemented when using Cloud Build to deploy applications? (Choose 2.)

Select 2 answers
A.Add SSH keys to Cloud Build for private Git repos.
B.Use Cloud KMS to encrypt sensitive environment variables.
C.Use container image tags instead of digests in build configs.
D.Store secrets in Cloud Build's default substitution variables.
E.Restrict Cloud Build trigger creation to specific IAM roles.
AnswersB, E

Encrypted variables are decrypted at build time.

Why this answer

Cloud Build does not automatically encrypt environment variables stored in build config files or the console. Using Cloud KMS allows you to encrypt sensitive data like API keys or passwords, then decrypt them at build time via the `gcloud kms decrypt` step, ensuring secrets are never stored in plaintext.

Exam trap

A common pitfall for this question is believing that SSH keys (option A) or container image tags (option C) are security best practices for Cloud Build. SSH keys should be avoided in favor of Cloud Source Repositories or other secure Git integrations. Tags are mutable, making them insecure; digests provide immutability.

Additionally, storing secrets in default substitution variables (option D) is insecure because they are not encrypted. The correct best practices are using Cloud KMS for encrypting sensitive environment variables (B) and restricting trigger creation to specific IAM roles (E).

Practice this question →
16
MCQeasy

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?

A.The application is running on a different port than the one specified in the environment variable PORT.
B.The node_modules folder was not uploaded because it is in the .gcloudignore file.
C.The package.json file is missing the express dependency.
D.The request exceeds the 60-second timeout.
AnswerB

If node_modules is ignored, App Engine will install dependencies during deployment, but if there is a lockfile issue or missing package.json fields, it may fail. However, the error indicates express is not installed, so the build process may not have run correctly, possibly due to .gcloudignore preventing upload of a needed file.

Why this answer

The error 'Cannot find module express' indicates that the Express module is not available to the application. In App Engine Standard Environment, dependencies are automatically installed based on package.json during deployment. However, if the node_modules folder is present in the project directory and is excluded via .gcloudignore, the automatic installation may be skipped or overridden, leading to missing modules.

The most likely cause is that node_modules is listed in .gcloudignore, so it wasn't uploaded and the automatic install didn't run correctly. Option B correctly identifies this issue.

Practice this question →
17
Multi-Selectmedium

Which TWO best practices should be followed when deploying a containerized application to Cloud Run for production?

Select 2 answers
A.Use a minimal base image with only necessary dependencies.
B.Set min-instances to 0 to save costs when idle.
C.Set max-instances to unlimited to handle traffic spikes.
D.Configure CPU to be always allocated to reduce latency.
E.Always use the latest public image from Docker Hub for dependencies.
AnswersA, D

Minimal images reduce attack surface and improve start time.

Why this answer

Using a minimal base image (e.g., distroless or Alpine-based) reduces the attack surface, decreases image size, and speeds up cold starts. Cloud Run pulls the container image for each new instance, so a smaller image directly reduces startup latency and improves scaling responsiveness. This aligns with Google's best practices for production deployments on Cloud Run.

Exam trap

A common misconception is that setting min-instances to 0 is always cost-effective, but in production, the trade-off between cost and latency often leads to setting min-instances to at least 1 to avoid cold starts.

Practice this question →
18
MCQeasy

A developer runs the command above. What is the effect of the --promote flag in this deployment?

A.It creates a new default service version with split traffic.
B.It promotes the previous version to receive traffic.
C.It causes the new version (v2) to receive 100% of traffic after deployment.
D.It enables automatic scaling for the new version.
AnswerC

Correct: --promote directs all traffic to the newly deployed version.

Why this answer

The --promote flag in a Google Cloud App Engine deployment command (gcloud app deploy --promote) causes the newly deployed version (v2) to immediately receive 100% of traffic, effectively making it the default serving version. This is the standard behavior unless the --no-promote flag is explicitly used to keep traffic on the previous version.

Exam trap

A common misconception is that the --promote flag affects the previous version or creates traffic splits. In Google Cloud App Engine, the --promote flag causes the newly deployed version to receive 100% of traffic, making it the default serving version. Using --no-promote keeps traffic on the previous version.

How to eliminate wrong answers

Option A is wrong because --promote does not create a new default service version with split traffic; it sets the new version as the sole default, receiving all traffic, not a split. Option B is wrong because --promote promotes the new version (v2) to receive traffic, not the previous version; the previous version is demoted. Option D is wrong because --promote has no effect on automatic scaling; scaling configuration is set separately via app.yaml or deployment parameters, not by this flag.

Practice this question →
19
MCQmedium

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?

A.The /tmp partition is using a small temporary disk that is separate from the persistent disk.
B.The instance's RAM is insufficient, causing swap to fill the disk.
C.The startup script is not cleaning up temporary files.
D.The Cloud Storage bucket quota is exceeded.
AnswerA

Often /tmp is a tmpfs with limited capacity; creating too many temporary files fills it.

Why this answer

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.

Practice this question →
20
MCQhard

A company deploys a stateful application on GKE using a StatefulSet with PersistentVolumeClaims (PVCs). After a node failure, the pod is rescheduled to another node but the PVC remains in 'Pending' state. What is the most likely reason?

A.The PVC is bound to a PV that is still attached to the failed node.
B.The StorageClass has reclaimPolicy: Delete so the PV was deleted.
C.The PV's claimRef still points to the old PVC UID and is in Released state.
D.The StatefulSet's pod management policy prevents reattachment.
AnswerC

By default, PV has retain policy; claimRef must be removed to reuse.

Why this answer

When a StatefulSet pod is rescheduled after a node failure, the original PersistentVolume (PV) may remain in a 'Released' state if its claimRef still points to the old PersistentVolumeClaim (PVC) UID. The PV cannot be re-bound to the new PVC (which has a different UID) until the claimRef is cleared, causing the PVC to remain 'Pending'. This is a known behavior in Kubernetes where PVs are not automatically recycled for reuse with a new PVC UID.

Exam trap

The key trap is that the PV's claimRef prevents re-binding until it is cleared, leading to a 'Pending' PVC state. This is a known behavior in GKE and Kubernetes, where PVs are not automatically recycled for reuse with a new PVC UID.

How to eliminate wrong answers

Option A is wrong because if the PV were still attached to the failed node, the PVC would typically show a 'Lost' or 'Failed' status, not 'Pending'; the PV attachment is a separate concern from the PVC binding state. Option B is wrong because reclaimPolicy: Delete would delete the PV only after the PVC is deleted, not while the PVC still exists; the PVC being 'Pending' indicates the PV is still present but not bindable. Option D is wrong because StatefulSet's pod management policy (e.g., OrderedReady or Parallel) affects pod creation/deletion order, not the ability to reattach a PVC to a PV; the PVC binding issue is independent of the pod management policy.

Practice this question →
21
Multi-Selectmedium

A developer is deploying a Python web application to App Engine Flexible Environment. The application requires a specific third-party binary that is not pre-installed on the runtime image. Which two steps should the developer take to ensure the binary is available? (Choose two.)

Select 2 answers
A.Configure a VM-level startup script in the Google Cloud Console.
B.Specify the binary as a dependency in the requirements.txt file.
C.Include the binary in the application's Git repository and reference it in the app.yaml.
D.Use a startup script in the app.yaml to install the binary.
E.Add the binary installation commands to a Dockerfile and use a custom runtime.
AnswersD, E

Startup scripts in app.yaml can run commands to install binaries.

Why this answer

App Engine Flexible Environment supports a `startup_script` field in `app.yaml` that runs shell commands during instance initialization, allowing installation of third-party binaries. Option E is correct because using a custom runtime with a Dockerfile gives full control over the base image and dependencies, enabling the developer to install any required binary via `RUN` commands.

Exam trap

The trap here is that candidates confuse App Engine Flexible Environment's `startup_script` with Compute Engine's VM-level startup scripts, or assume that `requirements.txt` can handle system dependencies, when in fact it only manages Python packages.

Practice this question →
22
MCQeasy

A developer wants to deploy a Cloud Function that connects to a Cloud SQL database. What is the simplest way to securely inject database credentials?

A.Store credentials in the Cloud Function code as environment variables.
B.Use Cloud Key Management Service to encrypt credentials and pass them via HTTP headers.
C.Use Secret Manager to store and access the database password.
D.Embed credentials in the database connection string in the source code.
AnswerC

Secret Manager provides secure storage and access control for secrets.

Why this answer

Secret Manager provides a secure, centralized service for storing sensitive data like database passwords, and the Cloud Function can access the secret at runtime via the Secret Manager API or by mounting it as a volume. This avoids hardcoding credentials in code or environment variables, which can be exposed in logs or source control. It is the simplest and most secure approach recommended by Google Cloud for injecting database credentials into Cloud Functions.

Exam trap

The trap here is that candidates often confuse environment variables (Option A) as a secure method because they are not in source code, but the exam tests the understanding that environment variables in serverless environments can still be exposed through logs or the console, whereas Secret Manager provides dedicated encryption and access control.

How to eliminate wrong answers

Option A is wrong because storing credentials as environment variables in Cloud Function code is not secure; environment variables can be exposed in logs, error messages, or through the Cloud Functions UI, and they do not provide encryption at rest or access control. Option B is wrong because using Cloud KMS to encrypt credentials and passing them via HTTP headers is unnecessarily complex and insecure; HTTP headers are visible in transit unless TLS is used (which is standard), but the decryption key management adds overhead, and this approach does not integrate natively with Cloud Functions' runtime. Option D is wrong because embedding credentials in the database connection string in the source code is a security risk; it exposes secrets in version control, build artifacts, and logs, violating the principle of least privilege and making rotation difficult.

Practice this question →
23
Multi-Selecthard

A company is deploying a microservices architecture on Google Cloud using Cloud Run. They need to ensure that services can communicate securely with each other and with other Google Cloud services, such as Cloud Storage and Secret Manager. Which three steps should they take? (Choose three.)

Select 3 answers
A.Enable Cloud Service Mesh for sidecar proxy injection.
B.Configure Cloud Run services to use internal load balancing.
C.Use Cloud Run's direct VPC egress to access resources in a VPC network.
D.Use service accounts with least privilege permissions for each service.
E.Enable VPC Connector for each Cloud Run service.
AnswersC, D, E

Direct VPC egress allows Cloud Run services to send traffic to VPC networks.

Why this answer

To securely communicate with other Google Cloud services like Cloud Storage and Secret Manager, Cloud Run services can use direct VPC egress to route traffic through your VPC. Additionally, to access resources in a VPC, you can use a VPC connector. Using service accounts with least privilege ensures secure access control.

These three steps together provide secure communication.

Exam trap

The trap in this question is that candidates may believe only one method (direct VPC egress or VPC connector) is correct, but on Google Cloud both are valid options for achieving secure communication with VPC resources. Additionally, candidates might mistakenly think that sidecar proxies (Cloud Service Mesh) or internal load balancing are required for secure communication between Cloud Run services and other Google Cloud services.

Practice this question →
24
MCQeasy

During a rolling update, the new pods are failing to start because they require more memory than available on nodes. What is the most likely cause?

A.The maxSurge value is too low.
B.The resource requests and limits are misconfigured.
C.The replicas count is too high.
D.The strategy type is wrong.
AnswerB

The requests are too high for the available node memory, causing the new pods to fail to schedule.

Why this answer

The most likely cause of pods failing to start due to insufficient memory is misconfigured resource requests and limits. If the memory request (spec.containers[].resources.requests.memory) is set too high, the scheduler cannot find a node with enough allocatable memory, leaving pods in a Pending state. Similarly, if the limit is set too low, the pod may be OOMKilled after starting, but the question specifically states 'failing to start,' pointing to a scheduling failure due to requests exceeding node capacity.

Exam trap

A common pitfall in Kubernetes rolling updates is confusing resource requests (used for scheduling) with limits (used for enforcement). Candidates often attribute the failure to a high replicas count or an insufficient maxSurge value, but the actual issue is that the pod's memory request exceeds the available capacity on any node in the cluster.

How to eliminate wrong answers

Option A is wrong because maxSurge controls how many extra pods can be created above the desired replicas during a rolling update; a low maxSurge might slow the rollout but does not cause pods to fail starting due to memory constraints. Option C is wrong because the replicas count being too high would affect the total number of pods, but the issue is per-pod memory requirements, not the count; the scheduler would still attempt to place each pod individually. Option D is wrong because the strategy type (RollingUpdate vs.

Recreate) affects how pods are replaced, not the resource requirements of the new pods; a wrong strategy type would not cause memory-related startup failures.

Practice this question →
25
MCQhard

A developer deployed the Kubernetes Deployment shown. The application takes about 45 seconds to fully initialize and respond on the /healthz endpoint. What problem will occur with this configuration?

A.The readiness probe will never succeed, and the pod will be removed from service.
B.The deployment will not create any pods because of a syntax error.
C.The liveness probe will start too early and cause the pod to be restarted before it becomes ready.
D.The pod will be marked ready immediately because the readiness probe uses the same endpoint as liveness.
AnswerC

Correct: Liveness probe at 30s will fail, and after three failures the pod restarts, preventing it from ever becoming ready.

Why this answer

The liveness probe has an initialDelaySeconds of 30 seconds, which is less than the application's initialization time of 45 seconds. Therefore, the liveness probe will start checking the /healthz endpoint at 30 seconds, fail, and Kubernetes will restart the pod before it becomes ready. The readiness probe does not prevent the liveness probe from running and causing restarts.

Exam trap

Google Cloud often tests the distinction between liveness and readiness probes in GKE. The trap here is that candidates assume both probes behave the same way or that a failing readiness probe prevents the liveness probe from running, when in fact liveness probes operate independently and can restart the pod before readiness succeeds.

How to eliminate wrong answers

Option A is wrong because the readiness probe will eventually succeed after the 45-second initialization period, as it uses the same /healthz endpoint; the problem is not that it never succeeds, but that the liveness probe restarts the pod first. Option B is wrong because there is no syntax error in the Deployment manifest; the configuration is syntactically valid, and pods will be created. Option D is wrong because the pod will not be marked ready immediately; the readiness probe must succeed before the pod is considered ready, and it takes 45 seconds to succeed, so the pod will remain in a not-ready state until then.

Practice this question →
26
MCQhard

You are deploying a stateful application to GKE. The deployment fails with an error: 'pods failed to fit in any node due to insufficient CPU'. The cluster has 3 nodes with 4 vCPUs each. The deployment requests 2 vCPUs per pod with 5 replicas. What is the most likely issue?

A.The cluster autoscaler is not enabled.
B.The deployment does not specify resource limits.
C.Other workloads or system components are consuming CPU resources.
D.The nodes have taints that prevent pod scheduling.
AnswerC

Reserved CPU for system daemons reduces available capacity.

Why this answer

The cluster has 3 nodes × 4 vCPUs = 12 vCPUs total capacity. The deployment requests 5 pods × 2 vCPUs = 10 vCPUs, which is within the total capacity. However, the error indicates that the pods cannot be scheduled due to insufficient CPU.

This is most likely because other workloads (e.g., system components, DaemonSets, or other deployments) are consuming CPU on the nodes, reducing the available CPU below what is required. Option A is incorrect because the cluster autoscaler would only add nodes if there is insufficient total capacity, but here the capacity exists but is consumed. Option B is incorrect because missing resource limits would not cause CPU insufficiency; it would allow pods to consume more but not prevent scheduling.

Option D is incorrect because the error explicitly mentions insufficient CPU, not taints or tolerations. Therefore, option C is the most likely cause.

Practice this question →
27
MCQmedium

A developer needs to deploy a Python application to App Engine flexible environment. The application requires a specific version of a system package (libssl-dev) that is not included in the default runtime image. How should the developer install this package?

A.Use a custom runtime that already includes the package.
B.Specify the package in the app.yaml file under the 'libraries' section.
C.Create a Dockerfile that uses the base runtime image and runs apt-get install.
D.Add the package name to the requirements.txt file.
AnswerC

A Dockerfile allows customizing the runtime, including system packages.

Why this answer

The App Engine flexible environment runs your application in a Docker container based on a Google-provided runtime image. To install system packages like libssl-dev that are not included in the default image, you must customize the container by creating a Dockerfile that starts FROM the base runtime image and then runs apt-get install. This is the standard method for adding OS-level dependencies in the flexible environment.

Exam trap

The trap here is that candidates confuse the 'libraries' section in app.yaml (which is for Python packages) with system package installation, or mistakenly think requirements.txt can handle OS-level dependencies, leading them to pick options B or D instead of the correct Dockerfile approach.

How to eliminate wrong answers

Option A is wrong because using a custom runtime that already includes the package is an overly complex and unnecessary approach; the flexible environment already supports custom Dockerfiles, so you can simply extend the base runtime image rather than building a completely separate runtime. Option B is wrong because the 'libraries' section in app.yaml is used to specify Python libraries (e.g., Flask, Django) that are installed via pip, not system packages like libssl-dev which require apt-get. Option D is wrong because requirements.txt is for Python package dependencies installed via pip, not for system-level packages that must be installed via the operating system's package manager.

Practice this question →
28
MCQeasy

A startup wants to deploy a Python web application with low traffic and minimal operational overhead. They need to automatically scale down to zero when not in use. Which compute option should they choose?

A.App Engine Standard Environment.
B.Compute Engine with managed instance group and autoscaling.
C.Google Kubernetes Engine with cluster autoscaling.
D.Cloud Run.
AnswerA, D

App Engine Standard can scale to zero when not in use and supports Python, meeting all the startup's needs with minimal overhead.

Why this answer

Both App Engine Standard Environment and Cloud Run satisfy the requirements of low traffic, minimal operational overhead, and scaling to zero. App Engine Standard can scale to zero when no requests are incoming and supports Python, making it a valid choice. Cloud Run also scales to zero automatically and is fully managed, but for a simple Python web app, App Engine Standard offers even less configuration.

Therefore, both options are correct.

Exam trap

A common pitfall is thinking that App Engine Standard cannot scale to zero, but it actually can. Cloud Run is also valid, but both are correct for this scenario.

How to eliminate wrong answers

Option A is wrong because App Engine Standard Environment, while serverless, does not support scaling to zero instances; it always keeps at least one instance warm to handle traffic, which incurs ongoing costs. Option B is wrong because Compute Engine with managed instance groups and autoscaling can scale down, but the minimum number of instances is typically 1 (or more for high availability), and it cannot scale to zero instances, plus it requires managing virtual machines. Option C is wrong because Google Kubernetes Engine with cluster autoscaling can scale down nodes, but the cluster itself requires at least one node to run the control plane and system pods, and it cannot scale to zero nodes, leading to higher operational overhead and cost.

Practice this question →
29
MCQhard

A developer is deploying an application on Compute Engine and needs to automatically apply security patches without downtime. The application runs behind a TCP load balancer. What is the best deployment strategy?

A.Use a canary deployment with a separate instance group.
B.Stop all instances, apply patches, then restart them.
C.Use a managed instance group with autohealing.
D.Use a rolling update on the instance group.
AnswerD

Rolling update gradually replaces instances with new ones that have patches, minimizing downtime while behind a load balancer.

Why this answer

A rolling update on a managed instance group allows the developer to update instances incrementally, applying security patches without downtime. The TCP load balancer automatically distributes traffic only to healthy instances, so as each instance is updated and passes health checks, traffic is seamlessly redirected away from instances being patched.

Exam trap

The PCD exam often tests the distinction between reactive mechanisms like autohealing and proactive strategies like rolling updates, leading candidates to mistakenly choose autohealing for patching when it only handles failure recovery, not scheduled maintenance.

How to eliminate wrong answers

Option A is wrong because a canary deployment with a separate instance group is typically used for testing new application versions with a small subset of traffic, not for applying security patches across all instances; it introduces unnecessary complexity and does not guarantee all instances are patched. Option B is wrong because stopping all instances simultaneously causes downtime, as the TCP load balancer would have no healthy instances to serve traffic during the patch window. Option C is wrong because autohealing only replaces instances that fail health checks due to crashes or corruption, it does not proactively apply security patches; it reacts to failures rather than preventing them.

Practice this question →
30
MCQmedium

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?

A.The health check is misconfigured, causing the instance to be considered unhealthy.
B.The app requires an environment variable that is not set.
C.The container startup time exceeds the 10-minute timeout.
D.The Dockerfile has a syntax error that prevents the container from building.
AnswerC

App Engine flexible environment has a 10-minute startup timeout; if the container takes longer, it fails with this error.

Why this answer

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.

Exam trap

The PCD exam often tests the distinction between container startup failures (timeout) and runtime failures (health check, missing env vars), so candidates mistakenly attribute the 'context deadline exceeded' error to health check misconfiguration or missing environment variables.

How to eliminate wrong answers

Option A is wrong because a misconfigured health check would cause the instance to be marked unhealthy after startup, not prevent the container from starting; the error 'context deadline exceeded' occurs before health checks are evaluated. Option B is wrong because a missing environment variable would cause the application to fail at runtime (e.g., crash loop), not produce a container startup timeout error; the container would still start and then fail. Option D is wrong because a Dockerfile syntax error would prevent the container from building entirely, resulting in a build failure error, not a startup timeout; the error message specifically references container startup, not build.

Practice this question →
31
MCQmedium

A company is deploying a containerized application on Google Kubernetes Engine (GKE). The deployment uses a Service of type LoadBalancer. After creating the Service, the external IP remains pending for several minutes. The team has verified that the cluster has sufficient node capacity and that the pod is running. What is the most likely cause?

A.The Service is using an incorrect port mapping.
B.The pod's readiness probe is failing.
C.The project's quota for external IP addresses has been exhausted.
D.The cluster is using a regional cluster type.
AnswerC

Exhausted quota is a common cause for pending external IPs.

Why this answer

When a Service of type LoadBalancer is created in GKE, it provisions an external IP address from the project's quota. If the quota for external IP addresses is exhausted, the IP assignment remains pending until additional quota is requested or released. The cluster having sufficient node capacity and the pod running confirms that the issue is not resource-related but rather a cloud-level quota limitation.

Exam trap

A common misconception when a GKE LoadBalancer's external IP is pending is that it's due to cluster resource issues (node capacity or pod readiness), but it is often a Google Cloud project quota limitation for external IP addresses.

How to eliminate wrong answers

Option A is wrong because incorrect port mapping would cause connectivity issues (e.g., timeouts or connection refused) but would not prevent the external IP from being assigned; the LoadBalancer controller would still allocate an IP. Option B is wrong because a failing readiness probe would cause the pod to be removed from the Service's endpoints, but the external IP assignment is handled by the cloud provider's load balancer controller independently of pod readiness; the IP would still be provisioned. Option D is wrong because regional clusters are the default and recommended type for GKE; they do not affect the ability to assign external IPs, and zonal clusters also support LoadBalancer Services without such delays.

Practice this question →
32
MCQmedium

Refer to the exhibit. A Cloud Build pipeline that deploys a Cloud Run service fails with the above error. The Cloud Build service account has the roles/run.admin role at the project level. What is the most likely cause?

A.The service account used by Cloud Build does not have the Cloud Run Invoker role.
B.The Cloud Run service was deleted manually before the pipeline ran.
C.The Cloud Run API is not enabled in the project.
D.The region specified in the deploy step does not have Cloud Run enabled.
AnswerC

Correct. The API must be enabled for any Cloud Run operations to succeed.

Why this answer

The error message indicates that Cloud Run is not available, which typically occurs when the Cloud Run API has not been enabled in the project. Without the API enabled, any attempt to deploy a Cloud Run service via Cloud Build will fail, regardless of the service account's IAM roles. Enabling the API is a prerequisite for using Cloud Run resources.

Exam trap

The PCD exam often tests the distinction between IAM permissions (roles) and API enablement, trapping candidates who assume that granting a role automatically enables the underlying service API.

How to eliminate wrong answers

Option A is wrong because the Cloud Run Invoker role (roles/run.invoker) is only required for invoking (accessing) a deployed Cloud Run service, not for deploying it; the deploy operation requires roles/run.admin, which the service account already has. Option B is wrong because if the Cloud Run service was deleted manually, the pipeline would fail with a 'not found' error (HTTP 404), not with an error indicating that Cloud Run is not available or the API is disabled. Option D is wrong because Cloud Run is a global service; while regions can be restricted by organization policies, the error message shown in the exhibit does not mention region-specific unavailability, and the default behavior is that Cloud Run is available in all supported regions once the API is enabled.

Practice this question →
33
MCQmedium

A company deploys a web app on Cloud Run and configures a custom domain mapping with a managed SSL certificate. After mapping, the domain returns 404 errors. The Cloud Run service is accessible via its default URL. What is the most likely issue?

A.The SSL certificate is not yet provisioned.
B.The Cloud Run service does not have the correct IAM permissions.
C.The DNS CNAME record is not configured correctly.
D.The domain mapping is pointing to a different Cloud Run service or region.
AnswerD

Domain mapping must match the exact service name and region.

Why this answer

The most likely issue is that the custom domain mapping is pointing to a different Cloud Run service or region. When a custom domain is mapped to Cloud Run, the DNS CNAME must point to the domain mapping's resolved target (e.g., `ghs.googlehosted.com`), not to the default Cloud Run URL. If the mapping points to a different service or region, the request reaches Cloud Run but the service cannot handle it, resulting in a 404 error from the Cloud Run frontend.

The default URL works because it bypasses the custom domain mapping and routes directly to the correct service.

Exam trap

Google often tests the distinction between DNS resolution failures (which prevent reaching the server) and HTTP-level errors (which indicate the server received the request but cannot fulfill it), leading candidates to incorrectly blame DNS when the actual issue is a misconfigured domain mapping.

How to eliminate wrong answers

Option A is wrong because a managed SSL certificate not yet provisioned would cause an SSL/TLS error (e.g., certificate not trusted or connection refused), not a 404 HTTP status code. Option B is wrong because IAM permissions control access to the Cloud Run service itself (e.g., who can invoke it), not the routing of custom domain requests; a 404 indicates the request reached Cloud Run but no matching service was found. Option C is wrong because an incorrectly configured DNS CNAME record would prevent the domain from resolving to Cloud Run at all, resulting in a DNS resolution failure or a timeout, not an HTTP 404 from the Cloud Run platform.

Practice this question →
34
MCQhard

An organization runs a stateful application on GKE that uses PersistentVolumes. They want to perform a rolling update of the application without disrupting the underlying persistent data. What should they use?

A.A ReplicaSet with a headless service.
B.A StatefulSet with a PersistentVolumeClaim template.
C.A DaemonSet with a PodDisruptionBudget.
D.A Deployment with a PersistentVolumeClaim template.
AnswerB

StatefulSet ensures each pod gets its own PVC and updates gracefully, preserving data.

Why this answer

A StatefulSet is the correct choice because it is designed for stateful applications that require stable, unique network identifiers and persistent storage. By including a PersistentVolumeClaim template in the StatefulSet spec, each Pod gets its own dedicated PersistentVolume that persists across rescheduling and rolling updates, ensuring data is not disrupted.

Exam trap

The PCD exam often tests the misconception that a Deployment with a PersistentVolumeClaim template can handle stateful workloads, but the trap is that Deployments treat all Pods as interchangeable and would force all Pods to share the same PVC, causing data loss or corruption during updates.

How to eliminate wrong answers

Option A is wrong because a ReplicaSet with a headless service provides stable network identities but does not manage persistent storage; it is typically used with Deployments for stateless apps. Option C is wrong because a DaemonSet ensures one Pod per node and is intended for node-level services like logging or monitoring, not for managing persistent storage with rolling updates. Option D is wrong because a Deployment with a PersistentVolumeClaim template would cause all Pods to share the same PersistentVolumeClaim, leading to data corruption or conflicts during rolling updates, as Deployments are designed for stateless workloads.

Practice this question →
35
Multi-Selecthard

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.)

Select 2 answers
A.Use Horizontal Pod Autoscaler to automatically adjust the number of pods based on CPU utilization.
B.Enable liveness probes to automatically restart pods that become unresponsive.
C.Configure pod disruption budgets to limit the number of pods that can be unavailable simultaneously.
D.Set readiness probes to ensure that pods are only considered ready when they can serve traffic.
E.Enable node auto-repair to automatically replace unhealthy nodes.
AnswersC, D

Correct: Pod disruption budgets help maintain availability during voluntary disruptions like rolling updates.

Why this answer

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.

Exam trap

The PCD exam often tests the distinction between liveness and readiness probes, and candidates mistakenly choose liveness probes (Option B) for availability during updates, but readiness probes are the correct choice for controlling traffic flow during rolling updates.

Practice this question →
36
Multi-Selectmedium

Which TWO of the following are best practices when deploying applications on Google Kubernetes Engine (GKE)?

Select 2 answers
A.Store sensitive configuration data in environment variables.
B.Skip liveness and readiness probes for stateless applications.
C.Use pod anti-affinity to spread pods across nodes.
D.Define resource requests and limits for all containers.
E.Use the default Compute Engine service account for pods.
AnswersC, D

Improves availability by distributing replicas.

Why this answer

Pod anti-affinity ensures pods are scheduled across different nodes, improving fault tolerance and high availability. This is a best practice for stateless applications to avoid a single point of failure during node failures. Option D is correct because defining resource requests and limits allows the Kubernetes scheduler to make informed placement decisions and prevents resource starvation, ensuring predictable application performance.

Exam trap

Google Cloud often tests the misconception that liveness and readiness probes are optional for stateless workloads, but in GKE they are critical for self-healing and traffic management, even for stateless applications.

Practice this question →
37
MCQmedium

You need to deploy a critical update to a production service on GKE with zero downtime. Which deployment strategy should you use?

A.Recreate strategy
B.Blue/green deployment using a Kubernetes Service and label selector
C.Canary deployment with 10% traffic
D.Rolling update with maxSurge=25%, maxUnavailable=25%
AnswerB

Switches traffic after all new pods are healthy.

Why this answer

Blue/green deployment creates two identical environments (blue and green) and switches traffic atomically by updating the Kubernetes Service's label selector to point to the new version. This ensures zero downtime because the old version remains fully serving until the new version is verified, and traffic cutover is instantaneous with no overlapping broken requests.

Exam trap

A common pitfall on the Google PCD exam is assuming that a rolling update with maxUnavailable=0% guarantees zero downtime, but the given parameters (maxUnavailable=25%) allow some pods to be terminated before new ones are ready, risking downtime. Blue/green deployment with a Service label switch provides atomic traffic cutover with no downtime.

How to eliminate wrong answers

Option A is wrong because the Recreate strategy terminates all existing pods before creating new ones, causing downtime during the scale-down and scale-up phases. Option C is wrong because a canary deployment with 10% traffic intentionally routes a small percentage of users to the new version, which is not a zero-downtime strategy for a critical update—it is used for gradual validation and risk reduction, not immediate full cutover. Option D is wrong because a rolling update with maxSurge=25% and maxUnavailable=25% allows up to 25% of pods to be unavailable during the update, which violates the zero-downtime requirement for a critical production service.

Practice this question →
38
MCQeasy

A team is deploying a microservice on Cloud Run that requires environment variables with sensitive information, such as database passwords. What is the recommended way to provide these secrets?

A.Inject them directly in the Cloud Run YAML configuration.
B.Embed them in the container image as environment variables.
C.Store them in a Cloud Storage bucket and mount as a volume.
D.Use Secret Manager to store the secrets and refer to them in the Cloud Run service.
AnswerD

Secret Manager securely stores secrets and integrates with Cloud Run.

Why this answer

Secret Manager is Google Cloud's dedicated service for securely storing and managing sensitive data like API keys and database passwords. Cloud Run natively integrates with Secret Manager, allowing you to reference secret versions by name in your service configuration without exposing the secret value in plaintext. This approach ensures secrets are encrypted at rest and in transit, and access can be tightly controlled via IAM permissions.

Exam trap

The trap here is that candidates may confuse Cloud Storage with a volume mount capability in Cloud Run, or mistakenly think embedding secrets in the container image is acceptable because it 'works' in local development, ignoring the security and compliance implications in a production environment.

How to eliminate wrong answers

Option A is wrong because injecting secrets directly in the Cloud Run YAML configuration would expose them in plaintext in the deployment manifest and revision history, violating security best practices. Option B is wrong because embedding secrets in the container image as environment variables makes them accessible to anyone with image pull access and persists them in the image layers, which is insecure and difficult to rotate. Option C is wrong because Cloud Storage buckets do not natively support mounting as a volume in Cloud Run; Cloud Run supports mounting volumes from Filestore or Secret Manager, but not Cloud Storage, and storing secrets in a bucket without encryption key management or IAM fine-grained access control is not a recommended pattern for secrets.

Practice this question →
39
MCQeasy

A developer wants to deploy a containerized application to Google Kubernetes Engine (GKE) and ensure that new pods are automatically created if an existing pod fails. Which Kubernetes resource should be used?

A.Job
B.DaemonSet
C.Deployment
D.StatefulSet
AnswerC

Correct: A Deployment manages ReplicaSets and ensures the desired number of pods are running.

Why this answer

A Deployment is the correct Kubernetes resource for ensuring declarative updates and self-healing for stateless applications. It manages a ReplicaSet, which maintains the desired number of pod replicas; if a pod fails, the ReplicaSet controller automatically creates a replacement pod to match the desired state.

Exam trap

The trap here is that candidates often confuse Deployments with StatefulSets, assuming stateful applications always need StatefulSets, but the question explicitly describes a stateless containerized application that only needs automatic pod replacement, making Deployment the simplest and correct choice.

How to eliminate wrong answers

Option A is wrong because a Job is designed for batch or one-time tasks that run to completion, not for continuously running applications that need automatic pod replacement on failure. Option B is wrong because a DaemonSet ensures that exactly one pod runs on each node (or a subset of nodes), which is used for node-level services like logging or monitoring, not for maintaining a desired replica count across the cluster. Option D is wrong because a StatefulSet is used for stateful applications that require stable, unique network identifiers and persistent storage; while it also supports self-healing, it introduces ordering and identity guarantees that are unnecessary and overly complex for a simple stateless application that just needs automatic pod replacement.

Practice this question →
40
Multi-Selecteasy

A company deploys a containerized application to Cloud Run using Cloud Build. They want to implement a rolling update strategy with zero downtime. Which two actions should they take? (Choose two.)

Select 2 answers
A.Gradually shift traffic to the new revision using the gcloud run services update-traffic command.
B.Create a new Cloud Run service for the new revision.
C.Deploy the new revision with the --no-traffic flag.
D.Set the min-instances attribute to 1 to keep at least one instance running.
E.Use the gcloud run deploy command with the --concurrency flag.
AnswersA, C

Correct. Traffic shifting allows incremental rollout and monitoring.

Why this answer

The `gcloud run services update-traffic` command allows you to gradually shift traffic from the current revision to a new revision, enabling a rolling update with zero downtime. This command supports percentage-based traffic splitting, which ensures that the new revision is incrementally exposed to users while the old revision remains active, thus maintaining service availability throughout the deployment.

Exam trap

The PCD exam often tests the misconception that `min-instances` or `--concurrency` flags are involved in traffic management or rolling updates, when in fact they only control instance lifecycle and concurrency limits, not traffic routing.

Practice this question →
41
MCQeasy

A company is migrating a monolithic Java application to Cloud Run. The application takes 10 minutes to start. What is the best deployment approach?

A.Migrate to App Engine Flexible Environment.
B.Use a custom runtime with a cold start optimization.
C.Optimize the Java application to start within 10 minutes and use startup CPU boost.
D.Increase the memory limit to 4 GB.
AnswerC

Cloud Run allows up to 10 minutes for startup; CPU boost helps.

Why this answer

Cloud Run allows a maximum container startup time of 10 minutes (600 seconds) by default, and the startup CPU boost feature temporarily allocates additional CPU during startup to accelerate initialization. By optimizing the application to start within this limit and enabling startup CPU boost, the company can directly address the cold start issue without changing the deployment platform or architecture.

Exam trap

The PCD exam often tests the misconception that increasing memory or changing platforms can fix startup time issues, when the real solution is to optimize the application startup within the platform's constraints and use built-in features like startup CPU boost.

How to eliminate wrong answers

Option A is wrong because migrating to App Engine Flexible Environment does not solve the startup time problem; it simply moves the monolithic app to another platform that also has its own startup constraints and does not inherently improve cold start performance. Option B is wrong because using a custom runtime with cold start optimization is not a standard Cloud Run feature; Cloud Run uses container images and does not offer a 'custom runtime' concept for cold start — the optimization must happen within the container itself. Option D is wrong because increasing the memory limit to 4 GB does not reduce startup time; memory allocation affects runtime performance but does not accelerate the initialization phase, which is CPU-bound.

Practice this question →
42
Drag & Dropmedium

Drag and drop the steps to deploy a containerized application to Google Kubernetes Engine (GKE) in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Deploying to GKE requires creating a cluster, authenticating, then applying manifests and exposing the service.

Practice this question →
43
Multi-Selectmedium

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

Select 3 answers
A.Avoid writing to the local filesystem for data that must persist across requests.
B.Set a maximum request timeout of 10 minutes to avoid cold starts.
C.Hardcode port 8080 in the container.
D.Design the application to be stateless, storing session data externally (e.g., Firestore).
E.Use Cloud Run's built-in autoscaling to handle traffic bursts.
AnswersA, D, E

Local filesystem is ephemeral; use external storage for persistent data.

Why this answer

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.

Exam trap

A common trap on the Google Professional Cloud Developer exam is the belief that setting a maximum request timeout to 10 minutes can avoid cold starts in Cloud Run. In reality, cold starts are related to instance lifecycle and can only be mitigated by configuring min instances or using traffic shaping, not by changing the request timeout.

Practice this question →
44
MCQeasy

A team wants to deploy infrastructure as code on Google Cloud. They need a declarative language that supports modularity and state management. Which tool should they choose?

A.Cloud Deployment Manager.
B.Cloud Shell.
C.Terraform.
D.gcloud commands.
AnswerC

Correct. Terraform is a declarative IaC tool with modularity and state management.

Why this answer

Terraform is the correct choice because it is a declarative infrastructure-as-code tool that supports modularity through reusable modules and state management via state files (local or remote backends like Cloud Storage). It allows teams to define Google Cloud resources in HashiCorp Configuration Language (HCL) and track resource changes over time, enabling safe, incremental updates.

Exam trap

Google often tests the distinction between declarative and imperative tools, and the trap here is that candidates may confuse Cloud Deployment Manager’s declarative templates with Terraform’s superior state management and modularity, or mistakenly think Cloud Shell or gcloud commands are suitable for infrastructure-as-code workflows.

How to eliminate wrong answers

Option A is wrong because Cloud Deployment Manager uses a declarative template syntax (YAML or Python) but lacks built-in state management; it relies on Google Cloud's live state, which can lead to drift detection issues and does not support the same level of modularity as Terraform. Option B is wrong because Cloud Shell is a browser-based command-line environment, not an infrastructure-as-code tool; it provides a terminal for running commands but does not offer declarative language, modularity, or state management. Option D is wrong because gcloud commands are imperative, not declarative; they execute individual API calls without state tracking or modular reuse, making them unsuitable for managing infrastructure as code with desired-state reconciliation.

Practice this question →
45
MCQhard

Your Cloud Run service experiences high latency during traffic spikes. You need to reduce p95 latency without over-provisioning. Which action should you take?

A.Set max-instances to a low number to ensure consistent resources.
B.Reduce the max-concurrency per container to 1.
C.Disable CPU throttling to always allocate CPU.
D.Set min-instances to at least 5 for consistent baseline capacity.
AnswerD

Eliminates cold start latency for baseline traffic.

Why this answer

Setting min-instances to at least 5 ensures that a baseline number of container instances are always warm and ready to handle incoming requests. This eliminates cold starts and reduces latency during traffic spikes because new requests can be immediately served by pre-warmed instances, rather than waiting for new containers to spin up. This approach directly reduces p95 latency without over-provisioning, as you only pay for the baseline instances when they are idle.

Exam trap

The PCD exam often tests the misconception that reducing concurrency or capping instances improves latency, when in fact the correct approach is to pre-warm instances using min-instances to avoid cold starts during traffic spikes.

How to eliminate wrong answers

Option A is wrong because setting max-instances to a low number artificially caps the service's ability to scale out during traffic spikes, which can cause request queuing and increased latency, not reduction. Option B is wrong because reducing max-concurrency per container to 1 severely limits throughput, forcing Cloud Run to create many more container instances to handle the same load, which increases latency due to cold starts and resource contention. Option C is wrong because disabling CPU throttling is not a supported configuration in Cloud Run; the platform manages CPU allocation automatically, and this option would not address the root cause of latency during spikes.

Practice this question →
46
MCQhard

You are deploying a Python Cloud Function using the Google Cloud CLI. The deployment fails with 'ERROR: (gcloud.functions.deploy) ResponseError: status=[404], code=[OK], message=[The function ... does not exist]' but the function already exists. What is the most likely cause?

A.The function was already deployed with the same name, causing a conflict.
B.The gcloud config's region does not match the region where the function was deployed.
C.The Python runtime version is not supported in that region.
D.The Cloud Functions API is not enabled.
AnswerB

The default region might be unset or different.

Why this answer

The 404 error indicates the deployment command cannot locate the function in the specified region. When you deploy a Cloud Function using the gcloud CLI, the command uses the default region set in your gcloud configuration (or the --region flag). If the function was originally deployed in a different region, the CLI will look for it in the wrong region and fail with a 404, even though the function exists elsewhere.

This is the most common cause of this specific error message.

Exam trap

A common mistake is assuming a 404 error always means the resource does not exist. In Google Cloud Functions, if the region in your gcloud config does not match the region where the function was deployed, the CLI will return a 404 even though the function exists elsewhere.

How to eliminate wrong answers

Option A is wrong because deploying a function with the same name does not cause a 404 error; it would trigger an update or a conflict error (e.g., 409 Conflict) if the function already exists in the same region. Option C is wrong because an unsupported Python runtime version would produce a different error, such as 'Runtime version not supported' or a 400 Bad Request, not a 404. Option D is wrong because if the Cloud Functions API were not enabled, the error would be a 403 Forbidden or a message about the API not being enabled, not a 404 indicating the function resource is not found.

Practice this question →
47
Multi-Selecteasy

A developer is deploying a Node.js application to App Engine flexible environment. They need to install custom dependencies and run startup scripts. Which two configuration elements should they define in the app.yaml? (Choose two.)

Select 2 answers
A.entrypoint
B.runtime
C.env_variables
D.manual_scaling
E.network
AnswersA, B

Specifies the command to start the application.

Why this answer

A is correct because the `entrypoint` element in app.yaml for App Engine flexible environment specifies the command to run your application, allowing you to execute custom startup scripts and install dependencies before the main process starts. This is essential for Node.js apps that require custom build steps or runtime initialization beyond the default `npm start`.

Exam trap

The PCD exam often tests the misconception that `env_variables` or `manual_scaling` can handle startup scripts, but only `entrypoint` (and `runtime` to define the base environment) directly control the command executed at container startup.

Practice this question →
48
MCQmedium

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?

A.The cluster has a network policy that blocks incoming traffic.
B.The Deployment's containerPort is set to 8080, but the Service's port is set to 80 and targetPort is not specified.
C.The Service is missing the externalTrafficPolicy: Local setting.
D.The Service's targetPort is set to 80 instead of 8080.
AnswerB

Without targetPort, the Service forwards to the same port number, causing mismatch.

Why this answer

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 the team verified that no network policies are in place, and firewall rules allow traffic on port 80.

Option C is incorrect because externalTrafficPolicy: Local affects client IP preservation, not basic connectivity. Option D is incorrect because the team did not explicitly set targetPort; it defaults to 80. If it were set to 80, that would also cause the timeout, but the issue is the default behavior.

Practice this question →
49
Matchingmedium

Match each Cloud CDN feature to its benefit.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Remove outdated content from edge caches

Authorize temporary access to private content

Serve content from any HTTP(S) server

Define how to cache different variations of content

Store content closer to users for low latency

Why these pairings

Cloud CDN features like caching, SSL/TLS termination, and compression each provide distinct benefits. Caching reduces latency, SSL/TLS termination improves security, and compression reduces bandwidth. Distractors often mix up these benefits.

Practice this question →
50
MCQhard

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?

A.Add a RUN chmod 777 /tmp command in the Dockerfile before the entrypoint.
B.Increase the memory limit of the Cloud Run service.
C.Change the base image to one that includes Java 11 and ensures the /tmp directory is writable.
D.Use a Cloud Storage FUSE mount for temporary storage.
AnswerC

A proper base image with the correct filesystem permissions resolves the issue.

Why this answer

The most common cause of write permission errors in Cloud Run is using a base image that does not have a writable /tmp directory or has the wrong filesystem permissions. Official base images like gcr.io/distroless/java or OpenJDK images are configured with a writable /tmp. Option A is incorrect because running chmod inside the Dockerfile may not fix the underlying issue if the filesystem is read-only or if the user doesn't have sufficient privileges; plus, Cloud Run may enforce security policies that prevent such operations.

Option B is incorrect because memory limits do not affect filesystem write permissions; they relate to memory allocation. Option D is incorrect because Cloud Storage FUSE is an overcomplication; the issue is simply the base image's /tmp configuration.

Practice this question →
51
MCQhard

A company is deploying a microservices architecture on GKE. They need to expose a set of related microservices under a single external IP address with path-based routing. Which Kubernetes resource should they use?

A.Service of type NodePort
B.NetworkPolicy
C.Service of type LoadBalancer
D.Ingress resource
AnswerD

Ingress provides path-based routing to multiple Services under one IP.

Why this answer

An Ingress resource is the correct choice because it provides HTTP/HTTPS layer-7 routing to expose multiple services under a single external IP address, using path-based or host-based rules. This directly meets the requirement of exposing a set of related microservices with path-based routing on GKE, whereas a Service of type LoadBalancer would create a separate external IP per service.

Exam trap

The trap here is that candidates often confuse a Service of type LoadBalancer with the ability to do path-based routing, but LoadBalancer only provides layer-4 TCP/UDP load balancing with a single external IP per service, not layer-7 path-based routing.

How to eliminate wrong answers

Option A is wrong because a Service of type NodePort exposes each service on a high-port on every node's IP, requiring clients to know the node IP and port, and does not provide a single external IP or path-based routing. Option B is wrong because a NetworkPolicy is a firewall rule that controls ingress and egress traffic between pods, not a mechanism for exposing services externally or routing traffic. Option C is wrong because a Service of type LoadBalancer provisions a separate external load balancer (and thus a separate external IP) for each service, failing the requirement to expose multiple services under a single IP with path-based routing.

Practice this question →
52
MCQmedium

You are deploying a Cassandra database on GKE. Which resource type should you use to ensure stable network identities and persistent storage per pod?

A.Job with persistent disk
B.Deployment with persistent volume claims
C.StatefulSet with volumeClaimTemplates
D.DaemonSet with hostPath volumes
AnswerC

Provides stable identities and persistent storage.

Why this answer

StatefulSet is the correct resource because it provides stable, unique network identities (via headless Service and ordinal pod names) and persistent storage per pod through volumeClaimTemplates, which dynamically create PersistentVolumeClaims for each replica. This is essential for Cassandra, which requires stable node identities and dedicated storage to maintain cluster state and data consistency.

Exam trap

The PCD exam often tests the misconception that Deployments can handle stateful workloads by attaching PersistentVolumeClaims, but the trap is that Deployments lack stable network identities and per-pod storage binding, which are required for databases like Cassandra to maintain cluster membership and data integrity.

How to eliminate wrong answers

Option A is wrong because a Job is designed for batch processing tasks that run to completion, not for long-running stateful applications like Cassandra, and it does not provide stable network identities or persistent storage per pod. Option B is wrong because a Deployment provides replicas with ephemeral identities (random pod names) and shared PersistentVolumeClaims, which cannot guarantee stable network identities or dedicated storage per pod, leading to data conflicts and cluster instability for Cassandra. Option D is wrong because a DaemonSet runs one pod per node, which does not provide stable per-pod identities or dedicated persistent storage; hostPath volumes tie data to a specific node, causing data loss if the pod is rescheduled to a different node, and they lack the dynamic provisioning needed for Cassandra.

Practice this question →
53
MCQmedium

A developer deploys a service on Cloud Run with a concurrency setting of 1. The service makes external API calls. Under heavy load, the service starts returning 503 errors. What is the most likely cause?

A.The container image is too large.
B.The Cloud Run service is hitting the maximum number of requests per second limit.
C.The API endpoint rate limits the requests.
D.Instance concurrency is too low causing request queuing and timeout.
AnswerD

Low concurrency forces many instances, potentially hitting max instances and causing 503s.

Why this answer

With concurrency set to 1, each Cloud Run instance can handle only one request at a time. Under heavy load, new requests must wait for an available instance, and if the queue wait time exceeds the request timeout (default 5 minutes, max 60 minutes), the requests are dropped with a 503 HTTP status. This is the most direct cause of the 503 errors, as the service cannot scale fast enough or the queue depth exceeds limits.

Exam trap

A common misconception is that 503 errors are always caused by external API rate limits or downstream dependencies. However, with Google Cloud Run, a low concurrency setting can cause request queuing and timeouts, leading to 503 errors from the service itself.

How to eliminate wrong answers

Option A is wrong because container image size affects cold start latency but does not directly cause 503 errors under load; large images may increase startup time but not request queuing. Option B is wrong because Cloud Run does not have a hard 'maximum requests per second' limit; it scales instances based on concurrency and CPU utilization, and 503s from request rate limits are not a native Cloud Run behavior. Option C is wrong because the external API rate limiting would cause errors from that API (e.g., 429 or 503 from the API), not from the Cloud Run service itself; the question states the service returns 503, implying the issue is within the Cloud Run deployment.

Practice this question →
54
MCQmedium

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?

A.The application is hardcoded to listen on port 8080 but the Cloud Run environment variable PORT may override it to a different value.
B.The application is trying to bind to a privileged port.
C.The Cloud Run service is configured with container port 443 by default.
D.The container does not have a proper HEALTHCHECK instruction.
AnswerA

Cloud Run sets the PORT variable; the app must read it.

Why this answer

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.

Practice this question →
55
MCQmedium

A company uses Cloud Build for CI/CD. They need to deploy a containerized app to Cloud Run automatically on every push to the main branch. Which Cloud Build configuration step is necessary?

A.Add a step to build the container with Dockerfile.
B.Add a step to run 'gcloud run deploy' command.
C.Add a step to push the image to Artifact Registry only.
D.Add a step to run unit tests.
AnswerB

This step performs the deployment to Cloud Run.

Why this answer

Cloud Build requires an explicit step to run the `gcloud run deploy` command in order to trigger a deployment to Cloud Run. While Cloud Build can build and push images, it does not automatically deploy to Cloud Run unless a deploy step is included in the build configuration. This step uses the built image (from Artifact Registry) and deploys it as a new revision to the specified Cloud Run service.

Exam trap

The PCD exam often tests the misconception that pushing an image to a registry automatically triggers a deployment, but in Cloud Build, each deployment must be explicitly commanded via a deploy step like `gcloud run deploy`.

How to eliminate wrong answers

Option A is wrong because building the container with a Dockerfile is necessary for creating the image, but it is not the step that deploys the app to Cloud Run; deployment requires an explicit deploy command. Option C is wrong because pushing the image to Artifact Registry only stores the image; it does not trigger a deployment to Cloud Run, which requires a separate deploy step. Option D is wrong because running unit tests is a quality assurance step that is optional and does not directly cause a deployment to Cloud Run.

Practice this question →
56
MCQeasy

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?

A.Create a Cloud Load Balancer with the bucket as backend and update DNS.
B.Add a DNS A record pointing to the load balancer IP instead of a CNAME.
C.Enable Cloud CDN on the bucket.
D.Set the bucket's default object ACL to public read.
AnswerA

A Cloud Load Balancer provides SSL termination and a static IP for custom domains.

Why this answer

To serve a static website hosted on Cloud Storage with a custom domain over HTTPS, you must configure an external HTTP(S) load balancer with the bucket as the backend. The load balancer handles SSL termination and provides a static IP address or hostname. You then update your DNS to point the custom domain to the load balancer's IP (using an A record) or to the load balancer's hostname.

Option B is incorrect because a DNS A record pointing directly to a load balancer IP still requires the load balancer; the CNAME is not the issue. Option C is incorrect because Cloud CDN alone does not enable HTTPS for a custom domain; it requires a load balancer or other origin. Option D is incorrect because making objects publicly readable does not provide HTTPS support; the bucket's static website feature only supports HTTP.

Practice this question →
57
MCQhard

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?

A.Configure the function to retry on failure and set a maximum retry count.
B.Increase the Cloud Function timeout to 60 minutes.
C.Set the Pub/Sub subscription acknowledgment deadline to 10 minutes and implement a push endpoint that acknowledges after processing.
D.Use Cloud Tasks instead of Pub/Sub for asynchronous invocation.
AnswerC

Extending the ack deadline prevents the message from being redelivered before processing completes.

Why this answer

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.

Exam trap

The PCD exam often tests the misconception that increasing the Cloud Function timeout alone solves Pub/Sub push subscription issues, but the trap here is that the Pub/Sub subscription's acknowledgment deadline is independent of the function timeout and must be configured separately to prevent premature redelivery.

How to eliminate wrong answers

Option A is wrong because configuring retry on failure with a maximum retry count does not address the root cause of the timeout; it only retries the same failing invocation, which will still exceed the 9-minute limit and continue to fail. Option B is wrong because increasing the Cloud Function timeout to 60 minutes does not change the Pub/Sub push subscription's acknowledgment deadline (default 10 seconds), so the subscription will still consider the message as undelivered and redeliver it, causing duplicate processing and potential 'Deadline Exceeded' errors. Option D is wrong because Cloud Tasks is an alternative service for asynchronous invocation, but it does not solve the specific issue of Pub/Sub's acknowledgment deadline; the developer would still need to configure timeouts and retries appropriately, and the question explicitly asks for handling long-running messages without losing them within the Pub/Sub context.

Practice this question →
58
MCQeasy

Refer to the exhibit. A developer is deploying a container to Cloud Run and receives the error shown. What is the most likely cause?

A.The container's health check is failing because the startup command is incorrect.
B.The PORT environment variable is not set correctly in the Cloud Run service configuration.
C.The container image does not exist in the specified registry.
D.The container is trying to listen on a privileged port (e.g., 80) instead of the expected port 8080.
AnswerD

Correct: The 'Permission denied' error when binding to port 8080 is misleading; the application likely attempts to bind to a lower port (like 80) that requires root, but Cloud Run runs as non-root.

Why this answer

Cloud Run requires containers to listen on the port specified by the PORT environment variable, which defaults to 8080. The error indicates the container is trying to bind to port 80, a privileged port, which is not allowed by the Cloud Run runtime sandbox. This mismatch causes the container to fail health checks and deployment.

Exam trap

The PCD exam often tests the misconception that the error is due to a missing image or incorrect health check, when in fact the container is failing to bind to the correct port because it ignores the PORT environment variable.

How to eliminate wrong answers

Option A is wrong because the error message explicitly states 'listen tcp :80: bind: permission denied', not a startup command failure; the command may be correct but the port is wrong. Option B is wrong because the PORT environment variable is set correctly by Cloud Run (default 8080), but the container is ignoring it and trying to use port 80 instead. Option C is wrong because the error is about port binding, not image retrieval; if the image were missing, the error would be 'Image not found' or 'Unauthorized'.

Practice this question →
59
MCQmedium

A team uses Cloud Build to automatically deploy a Cloud Function on push to a repository. The build fails intermittently with 'PERMISSION_DENIED' when executing gcloud functions deploy. What is the most likely cause?

A.The region specified in the build configuration does not match the function's region.
B.The build configuration file has a syntax error.
C.The Cloud Source Repository does not have the correct triggers.
D.The Cloud Build service account lacks the necessary IAM permissions on the Cloud Functions API.
AnswerD

Cloud Build requires roles/cloudfunctions.developer to deploy functions.

Why this answer

The intermittent 'PERMISSION_DENIED' error when Cloud Build runs `gcloud functions deploy` indicates that the Cloud Build service account does not have the required IAM roles (e.g., Cloud Functions Developer or Cloud Functions Admin) on the Cloud Functions API. Cloud Build uses its default compute engine service account (or a user-specified service account) to execute build steps; if this account lacks the `cloudfunctions.functions.create` or `cloudfunctions.functions.update` permission, the deployment will fail, and the intermittent nature may be due to eventual consistency or race conditions in IAM propagation.

Exam trap

Candidates often confuse build trigger configuration issues with runtime permission errors, leading them to incorrectly select options related to trigger misconfiguration when the error occurs during the deployment step itself. The intermittent 'PERMISSION_DENIED' points to IAM permissions for the Cloud Build service account on the Cloud Functions API.

How to eliminate wrong answers

Option A is wrong because a region mismatch would cause a different error (e.g., 'INVALID_ARGUMENT' or 'NOT_FOUND'), not a 'PERMISSION_DENIED' error, and the error would be consistent, not intermittent. Option B is wrong because a syntax error in the build configuration file would cause the build to fail at the parsing stage with a YAML or JSON parse error, not with a 'PERMISSION_DENIED' error during the `gcloud functions deploy` step. Option C is wrong because Cloud Source Repository triggers are responsible for initiating the build, not for the permissions required during the deployment step; incorrect triggers would prevent the build from starting at all, not cause an intermittent permission error during execution.

Practice this question →
60
Matchingmedium

Match each IAM role to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Can create and run Cloud Build builds

Can invoke Cloud Run services

Can list and read objects in a bucket

Can access secret versions

Can invoke Cloud Functions

Why these pairings

IAM basic roles include Viewer (read-only), Editor (read/write without IAM management), and Owner (full control). The distractors swap these definitions.

Practice this question →
61
MCQmedium

A developer is deploying a Cloud Run service that needs to access a Cloud SQL instance. The service is deployed with the --no-allow-unauthenticated flag. What is the recommended way to grant the service access to the database?

A.Grant the Cloud SQL Client role to the Cloud Run service's runtime service account.
B.Create a service account key and store it in Secret Manager, then mount it as a volume.
C.Use the default Compute Engine service account and grant it the Cloud SQL Client role.
D.Enable the Cloud SQL Admin API and use Application Default Credentials from the Cloud Run service.
AnswerA

This directly grants the necessary permission via IAM.

Why this answer

The recommended way to grant a Cloud Run service access to a Cloud SQL instance is to grant the Cloud SQL Client role (roles/cloudsql.client) to the Cloud Run service's runtime service account. This role provides the necessary permissions (cloudsql.instances.connect and cloudsql.instances.get) to establish a secure connection via the Cloud SQL Auth Proxy or the Cloud SQL connector library. Using the runtime service account follows the principle of least privilege and avoids managing long-lived credentials.

Exam trap

The PCD exam often tests the misconception that you need to use a service account key or the default Compute Engine service account, when in fact Cloud Run's runtime service account is the correct identity to grant the Cloud SQL Client role to, avoiding the need for managing keys or using a shared default account.

How to eliminate wrong answers

Option B is wrong because creating a service account key and storing it in Secret Manager introduces a long-lived credential that must be rotated and managed, which is less secure and more complex than using the runtime service account's built-in identity. Option C is wrong because the default Compute Engine service account is not automatically associated with Cloud Run services; Cloud Run uses its own runtime service account, and using the Compute Engine default would violate least privilege and may not have the correct permissions. Option D is wrong because enabling the Cloud SQL Admin API alone does not grant the necessary connect permissions; the Cloud SQL Client role must be explicitly assigned to the service account, and Application Default Credentials (ADC) will only work if the underlying service account has the correct IAM role.

Practice this question →
62
MCQmedium

An application running on Compute Engine instances behind a Cloud Load Balancer experiences intermittent 502 errors. The health checks pass but sometimes requests time out. What is the most likely cause?

A.The load balancer is misconfigured with wrong backend type.
B.The backend instances are running out of memory.
C.The SSL certificate has expired.
D.The connection draining timeout is too short.
AnswerD

Short connection draining timeout causes in-flight requests to be terminated, leading to 502 errors.

Why this answer

A connection draining timeout that is too short can cause the load balancer to close connections prematurely while backend instances are still processing requests. This results in intermittent 502 errors and timeouts, even though health checks pass, as the instances are healthy but connections are being terminated before responses are sent.

Exam trap

A common mistake is to assume that 502 errors always indicate backend health issues, but in Google Cloud Load Balancing, 502 errors often stem from connection draining or timeout settings, not health check failures. Health checks passing does not guarantee that connections are not being terminated prematurely.

How to eliminate wrong answers

Option A is wrong because a misconfigured backend type (e.g., instance group vs. network endpoint group) would typically cause persistent health check failures or complete routing failure, not intermittent 502 errors with passing health checks. Option B is wrong because running out of memory would likely cause the instance to become unresponsive or crash, leading to health check failures, not intermittent timeouts with passing health checks. Option C is wrong because an expired SSL certificate would cause TLS handshake failures and client-side errors (e.g., SSL_ERROR_BAD_CERT_DOMAIN), not backend timeout-related 502 errors from the load balancer.

Practice this question →
63
Drag & Dropmedium

Drag and drop the steps to set up a Firestore database in native mode in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Firestore native mode is selected during database creation, then data can be added.

Practice this question →
64
MCQmedium

A developer is troubleshooting a deployment on Cloud Run. The service fails with 'Container failed to start' error. The container image is built from a Dockerfile that uses CMD ['npm', 'start']. What is the most likely cause?

A.The Dockerfile uses CMD instead of ENTRYPOINT.
B.The container image is too large and exceeds the memory limit.
C.The application does not listen on the port specified by the PORT environment variable.
D.The Cloud Run service does not have permission to pull the image from Container Registry.
AnswerC

Cloud Run expects the container to listen on the port defined by the PORT env var (default 8080). If the app listens on another port, it fails.

Why this answer

Cloud Run requires the containerized application to listen on the port specified by the PORT environment variable (default 8080). If the application is hardcoded to listen on a different port (e.g., 3000) or does not read the PORT variable, Cloud Run's health checks and routing will fail, resulting in a 'Container failed to start' error. The CMD instruction is correct for starting npm, but the application must bind to the correct port.

Exam trap

The PCD exam often tests the misconception that CMD vs ENTRYPOINT is the root cause of container startup failures, when in reality the PORT environment variable mismatch is a far more frequent issue on Cloud Run.

How to eliminate wrong answers

Option A is wrong because both CMD and ENTRYPOINT can be used to start a container; Cloud Run does not require ENTRYPOINT over CMD, and this is not a common cause of startup failures. Option B is wrong because Cloud Run has a memory limit (e.g., 2 GiB default) but a large image size does not directly cause a 'Container failed to start' error; the error occurs during runtime, not during image pull or memory allocation. Option D is wrong because if Cloud Run lacked permission to pull the image, the error would be 'Permission denied' or 'Image pull failed', not 'Container failed to start', which indicates the container started but then failed.

Practice this question →
65
MCQhard

A developer runs the above command to build and push a container image to Container Registry, but receives the error shown. The developer has the 'Cloud Build Editor' role on the project. What is the most likely cause of the error?

A.The Cloud Storage bucket for storing build artifacts does not exist.
B.The developer's user account has been revoked access to the project.
C.The Cloud Build service account has not been enabled or does not have permission to act on behalf of the user.
D.The developer does not have the 'cloudbuild.builds.create' permission because the Cloud Build Editor role does not include it.
AnswerC

The Cloud Build service account needs to be enabled and have appropriate roles.

Why this answer

The error occurs because the Cloud Build service account (typically the Compute Engine default service account or a user-specified service account) lacks the necessary permissions to push the container image to Container Registry. Even though the developer has the 'Cloud Build Editor' role, Cloud Build itself needs a service account with appropriate IAM roles (e.g., Storage Object Admin) to write to the registry. The error is not about the developer's direct permissions but about the service account that Cloud Build uses to execute the build and push.

Exam trap

The PCD exam often tests the distinction between user-level permissions and service account permissions; the trap here is that candidates assume the user's role (Cloud Build Editor) is sufficient for the entire build process, ignoring that Cloud Build acts on behalf of a service account that requires separate IAM roles.

How to eliminate wrong answers

Option A is wrong because Cloud Build automatically creates the default Cloud Storage bucket (e.g., [PROJECT_ID]_cloudbuild) if it does not exist, and the error message would be different (e.g., 'bucket not found') if that were the issue. Option B is wrong because if the developer's user account had been revoked, they would not be able to run the command at all, and the error would likely be an authentication or authorization failure (e.g., 403 or 401), not a service account permission error. Option D is wrong because the 'Cloud Build Editor' role does include the 'cloudbuild.builds.create' permission; that is a core permission of the role, so the developer can submit builds.

Practice this question →
66
MCQeasy

A developer wants to deploy a Compute Engine instance using Terraform. They want to run a startup script to install software. How should they provide the script?

A.Use the metadata block with key 'startup-script' and the script content as value.
B.Use a cloud-init configuration file passed via user-data metadata.
C.Use the user-data metadata key with the script content.
D.Use the gcloud compute instances create command with --metadata-from-file flag.
AnswerA

This is the standard way to provide startup scripts in Terraform for GCP.

Why this answer

Terraform's `google_compute_instance` resource supports a `metadata` block where you can set the key `startup-script` with the script content as the value. When the Compute Engine instance boots, the `google-guest-agent` reads this metadata key and executes the script as the root user, which is the standard method for running startup scripts on Linux instances without additional configuration.

Exam trap

The trap here is that candidates confuse `user-data` (used by cloud-init) with `startup-script` (used by the Google Guest Agent), assuming any metadata key named 'user-data' will run a script, when in fact it requires cloud-init to be present and configured.

How to eliminate wrong answers

Option B is wrong because `cloud-init` is a separate tool that requires a specific `#cloud-config` format in the `user-data` metadata key; while it can install software, it is not the standard Terraform approach for a simple startup script and adds unnecessary complexity. Option C is wrong because the `user-data` metadata key is used by `cloud-init` (or `cloudbase-init` on Windows) to pass configuration files, not by the default `google-guest-agent`; using `user-data` with raw script content will not execute it unless `cloud-init` is installed and configured. Option D is wrong because the question explicitly asks how to provide the script using Terraform, not the `gcloud` CLI; `gcloud compute instances create --metadata-from-file` is a command-line tool, not a Terraform configuration.

Practice this question →
67
Multi-Selecthard

Which THREE are valid methods for authenticating a user or service when deploying a Cloud Function via the Google Cloud SDK? (Choose 3)

Select 3 answers
A.Using an API key
B.Using a user account with 'gcloud auth login'
C.Using an OAuth 2.0 client ID
D.Using an access token obtained from the Google Cloud Console
E.Using a service account key file with 'gcloud auth activate-service-account'
AnswersB, D, E

Valid: User accounts can authenticate via OAuth 2.0.

Why this answer

'gcloud auth login' authenticates a user account via OAuth 2.0, which is a valid method for deploying Cloud Functions. The Google Cloud SDK uses the user's credentials to authorize API calls, including deployments, making this a standard authentication approach for interactive or user-driven workflows.

Exam trap

The PCD exam often tests the distinction between authentication methods that are valid for SDK commands versus those meant for other contexts, such as API keys for simple API access or OAuth client IDs for application flows, leading candidates to mistakenly select them as valid for gcloud deployments.

Practice this question →
68
Multi-Selectmedium

Which TWO strategies can be used to reduce cold start latency in Cloud Run? (Choose 2)

Select 2 answers
A.Increase the maximum number of concurrent requests per instance.
B.Deploy the Cloud Run service in a region closer to the users.
C.Set a minimum number of instances (min-instances) to keep instances warm.
D.Allocate more memory to the container (up to 4GiB).
E.Use a VPC connector to access resources in a VPC network.
AnswersC, D

Correct: min-instances ensures at least that many instances are always ready, eliminating cold starts.

Why this answer

Setting a minimum number of instances (min-instances) ensures that a specified number of container instances are always running and ready to serve requests, eliminating the cold start latency that occurs when an instance must be started from scratch. This pre-warming strategy directly reduces the time users wait for the first request to be processed.

Exam trap

The PCD exam often tests the distinction between reducing network latency (region proximity) and reducing cold start latency (instance pre-warming), causing candidates to mistakenly select a region closer to users as a solution for cold start.

Practice this question →
69
MCQeasy

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?

A.Blue/green deployment
B.Recreate update
C.Canary deployment
D.Rolling update
AnswerD

Rolling update replaces pods incrementally, maintaining availability.

Why this answer

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.

Exam trap

The PCD exam often tests the distinction between built-in Kubernetes strategies (rolling update, recreate) and external deployment patterns (blue/green, canary) that require additional configuration or tools, leading candidates to overcomplicate the answer for a simple stateless workload.

How to eliminate wrong answers

Option A is wrong because blue/green deployment requires maintaining two separate environments (blue and green) and switching traffic via a Service or Ingress, which is more complex and resource-intensive than needed for a simple stateless application with 5 replicas; it is not a native Kubernetes Deployment strategy. Option B is wrong because the Recreate update strategy terminates all existing Pods before creating new ones, causing downtime during the update, which violates the zero-downtime requirement. Option C is wrong because canary deployment is a release pattern that routes a small percentage of traffic to the new version for testing, but it is not a built-in Deployment strategy in Kubernetes; it requires additional tooling like Istio or Flagger and is typically used for risk mitigation, not for achieving zero downtime in a simple stateless app.

Practice this question →
70
MCQmedium

A developer runs the above command and receives the error. What is the most likely cause?

A.The image tag format is incorrect.
B.The cloudbuild.yaml file is not present in the current directory.
C.The Dockerfile is missing from the repository.
D.The cloudbuild.yaml file has a syntax error, such as incorrect indentation.
AnswerD

The error message directly indicates a YAML parsing issue.

Why this answer

The error is most likely due to a syntax error in the cloudbuild.yaml file, such as incorrect indentation. Cloud Build uses YAML for configuration, and YAML is sensitive to indentation; a missing space or incorrect alignment can cause the build to fail with a parsing error. The command `gcloud builds submit` reads the cloudbuild.yaml file from the current directory, and if the YAML is malformed, the submission will fail before any Docker or build steps are executed.

Exam trap

The PCD exam often tests the distinction between configuration file syntax errors and missing file errors, so the trap here is that candidates assume a missing Dockerfile or cloudbuild.yaml is the problem, when the error message specifically points to a YAML parsing issue.

How to eliminate wrong answers

Option A is wrong because the image tag format is not the issue; the command `gcloud builds submit` does not require a specific image tag in the command itself unless explicitly passed via `--tag`, and the error is about the build configuration, not the tag. Option B is wrong because the error message would explicitly state that the file is missing (e.g., 'File not found'), not a syntax error; the command looks for cloudbuild.yaml in the current directory by default, and if it were absent, the error would be different. Option C is wrong because a missing Dockerfile would cause a build step failure later in the process, not a syntax error during the submission of the cloudbuild.yaml file; the error occurs before any Docker build is attempted.

Practice this question →
71
MCQeasy

A developer needs to deploy a Cloud Run service from a container image in Artifact Registry. What IAM role should be granted to the Cloud Run service account?

A.roles/storage.objectViewer
B.roles/cloudbuild.builds.builder
C.roles/artifactregistry.reader
D.roles/run.invoker
AnswerC

Required to read container images from Artifact Registry.

Why this answer

The Cloud Run service account needs permission to read the container image from Artifact Registry during deployment. The `roles/artifactregistry.reader` role grants the `artifactregistry.repositories.downloadArtifacts` permission, which is required to pull the image. Without this role, the deployment fails with an access denied error.

Exam trap

The PCD exam often tests the distinction between roles that grant access to the container image (Artifact Registry reader) versus roles that grant access to the running service (Cloud Run invoker), causing candidates to confuse deployment-time permissions with runtime permissions.

How to eliminate wrong answers

Option A is wrong because `roles/storage.objectViewer` grants read access to Cloud Storage buckets, not Artifact Registry repositories; Cloud Run does not pull container images from Cloud Storage. Option B is wrong because `roles/cloudbuild.builds.builder` is used for Cloud Build service accounts to execute builds, not for Cloud Run service accounts to pull images from Artifact Registry. Option D is wrong because `roles/run.invoker` only allows invoking the Cloud Run service (i.e., sending HTTP requests), not reading container images from Artifact Registry.

Practice this question →
72
MCQmedium

A company deploys a containerized web application to Cloud Run. The application needs to access a Cloud SQL instance but fails with a connection timeout. The VPC connector is configured and attached to the Cloud Run service. What is the most likely cause?

A.Cloud SQL instance does not have a public IP address.
B.The VPC connector is not configured to route to the Cloud SQL private IP range.
C.The application is not using the Cloud SQL Auth Proxy.
D.The VPC firewall rules block traffic to Cloud SQL.
AnswerB

The VPC connector must have appropriate routes to the Cloud SQL private IP range.

Why this answer

The VPC connector is attached to the Cloud Run service, but for it to route traffic to the Cloud SQL private IP address, the connector must be configured with a subnet that has a route to the Cloud SQL private IP range (e.g., 10.0.0.0/8 or a specific allocated range). Without this route, packets destined for the Cloud SQL instance's private IP are dropped, causing a connection timeout. The VPC connector itself does not automatically know how to reach Cloud SQL; the subnet must be peered or have appropriate routes.

Exam trap

The trap here is that candidates often assume a VPC connector alone is sufficient for private IP connectivity, but they overlook the requirement for proper routing from the connector's subnet to the Cloud SQL private IP range.

How to eliminate wrong answers

Option A is wrong because Cloud SQL instances with only a private IP address are reachable from Cloud Run via a VPC connector; a public IP is not required. Option C is wrong because the Cloud SQL Auth Proxy is not mandatory for private IP connections; it is only needed for public IP connections or to enforce IAM-based authentication. Option D is wrong because VPC firewall rules are not the primary cause here—firewall rules are evaluated after routing, and the timeout indicates a routing failure, not a firewall block.

Practice this question →
73
MCQmedium

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?

A.Redeploy the old version manually if the new version fails
B.Rolling update with a readiness probe
C.Blue/green deployment with health checks and a managed instance group
D.Canary deployment with a small percentage of traffic
AnswerC

Blue/green allows keeping the old version (blue) serving while the new version (green) is tested; if health checks fail, traffic remains on blue.

Why this answer

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.

Exam trap

The PCD exam often tests the distinction between deployment strategies by making candidates confuse 'rolling update with readiness probe' (which still risks partial downtime during rollback) with 'blue/green deployment' (which isolates the new version entirely until health checks pass).

How to eliminate wrong answers

Option A is wrong because manually redeploying the old version defeats the purpose of automation and introduces significant downtime during the manual rollback process. Option B is wrong because a rolling update with a readiness probe gradually replaces instances, which can still cause partial downtime if the new version fails health checks across multiple instances, and rollback requires additional pipeline steps. Option D is wrong because a canary deployment routes a small percentage of traffic to the new version, which can still cause service degradation for that subset of users if the new version fails, and it does not guarantee that the old VM continues serving all traffic seamlessly.

Practice this question →
74
Multi-Selecteasy

Which TWO statements about Cloud Run for Anthos are correct? (Choose 2)

Select 2 answers
A.Cloud Run for Anthos allows users to autoscale their containerized applications without worrying about underlying GKE nodes.
B.Cloud Run for Anthos is a multi-region service by default.
C.Cloud Run for Anthos supports only HTTP requests, not gRPC.
D.Cloud Run for Anthos runs on GKE clusters and uses Knative Serving.
E.Cloud Run for Anthos requires you to bring your own load balancer.
AnswersA, D

Correct: The service handles scaling of the containers, though nodes need separate management.

Why this answer

Cloud Run for Anthos leverages the Knative Serving autoscaler to automatically scale container instances up or down based on incoming request traffic, including scaling to zero when idle. This autoscaling operates at the pod level within the GKE cluster, abstracting away the underlying node management from the user.

Exam trap

The PCD exam often tests the misconception that Cloud Run for Anthos is a fully managed serverless service like Cloud Run on Google Cloud, when in fact it requires a GKE cluster and provides more control over the underlying infrastructure, including support for gRPC and custom load balancing.

Practice this question →
75
MCQhard

A developer is deploying a microservice on GKE that needs to be accessible only from within the same VPC network. The microservice must have a stable, internal IP address that does not change when pods are updated. Which options should be used?

A.Use a Service of type NodePort with a static reservation.
B.Use a Service of type ClusterIP with a static IP.
C.Use a Service of type LoadBalancer with the annotation 'cloud.google.com/load-balancer-type: Internal'.
D.Use a Service of type ExternalName pointing to the pods' internal IPs.
AnswerC

This creates an internal TCP/UDP load balancer with a stable internal IP.

Why this answer

Deploying a Service of type LoadBalancer with the annotation 'cloud.google.com/load-balancer-type: Internal' creates an internal TCP/UDP load balancer within the VPC network. This provides a stable, internal IP address that persists across pod updates, as the load balancer's IP is independent of the underlying pods and is managed by Google Cloud's networking layer.

Exam trap

The PCD exam often tests the misconception that ClusterIP provides a static IP, but in GKE, ClusterIP is ephemeral unless explicitly reserved via a custom IP range, whereas the internal LoadBalancer type guarantees a stable, reserved IP within the VPC.

How to eliminate wrong answers

Option A is wrong because a NodePort service exposes the microservice on a static port on each node's IP, but the node IPs are ephemeral and not guaranteed to be stable within the VPC; also, NodePort does not provide a dedicated internal IP address. Option B is wrong because a ClusterIP service assigns a stable internal IP, but this IP is not static by default and can change if the service is deleted and recreated; ClusterIP also does not support static IP reservation without additional configuration (e.g., using a custom IP range), and it is not designed for external access patterns. Option D is wrong because an ExternalName service maps to an external DNS name (e.g., a CNAME record) and cannot point to pods' internal IPs; it is used for external service discovery, not for providing a stable internal IP within the VPC.

Practice this question →
Page 1 of 2 · 88 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Deploying Apps questions.

Start 20-question session