CCNA Building Testing Apps Questions — Page 2 of 2

Multi-Selecthard

A company has a multi-module repository. They want to build only the modules that have changes. Which two features can they combine to achieve this? (Choose 2)

Select 2 answers

A.Cloud Build queue

B.Build scripts that detect changes

C.Cloud Build substitutions

D.Cloud Build triggers with filepath filters

E.Cloud Source Repositories mirror

AnswersB, D

A build step can run a script (e.g., `git diff`) to identify changed modules and conditionally execute subsequent steps.

Why this answer

Build scripts can be written to compare the current commit hash against the previous build's commit hash, or use git diff to detect which files have changed, and then conditionally execute build steps only for the affected modules. This approach gives fine-grained control over the build process and can be integrated into any CI/CD pipeline.

Exam trap

The PCD exam often tests the distinction between features that trigger builds (like triggers with filepath filters) and features that manage build execution or configuration (like substitutions or queues), leading candidates to mistakenly select options that sound related but do not actually detect changes.

Practice this question →

MCQhard

A team is using Cloud Build to build a Go application. They want to cache Go module dependencies across builds to speed up builds. Which configuration should they add to cloudbuild.yaml?

A.Use a custom builder that pre-installs dependencies

B.Set up a bucket for caching and use substitutions

C.Use a Kaniko cache with a remote repository

D.Use Cloud Build's built-in caching feature by specifying a volume

AnswerB

Correct. You can use a Cloud Storage bucket as a persistent cache. By setting up a bucket and using substitution variables in cloudbuild.yaml, you can script steps to download the cached Go module directory before the build and upload it after. This speeds up builds by reusing previously downloaded modules.

Why this answer

Cloud Build volumes share data across steps within a single build, but they do not persist across separate builds. To cache Go module dependencies across builds, you must use an external storage service such as Cloud Storage. A common pattern is to set up a Cloud Storage bucket for caching and use substitution variables in cloudbuild.yaml to reference the bucket.

Steps can be added to download the cache before building and upload after building, using tools like gsutil.

Exam trap

The PCD exam often tests the understanding that Cloud Build volumes are ephemeral within a build, while persistent cross-build caching requires external storage like Cloud Storage. Candidates may mistakenly select volume-based caching or confuse Kaniko's image layer caching with application dependency caching.

How to eliminate wrong answers

Option A is wrong because using a custom builder that pre-installs dependencies does not leverage Cloud Build's native caching mechanism; it only shifts the dependency installation to a custom image, which still requires rebuilding the image for each dependency change and does not persist the cache across separate builds. Option B is wrong because setting up a bucket for caching and using substitutions is not a built-in Cloud Build feature for caching dependencies; while Cloud Storage can be used for artifact storage, it requires manual scripting to upload/download the cache and does not integrate with Cloud Build's volume-based caching. Option C is wrong because Kaniko cache with a remote repository is designed for caching container image layers, not for caching Go module dependencies; Kaniko is a tool for building container images, and its cache stores intermediate layers, not application-level dependency caches like Go modules.

Practice this question →

Multi-Selectmedium

Which TWO statements are true about Cloud Functions? (Choose two.)

Select 2 answers

A.Cloud Functions automatically scale based on the number of incoming events

B.Cloud Functions require you to provide a container image from Container Registry

C.Cloud Functions are stateless by design

D.Cloud Functions can only be triggered by HTTP requests

E.Cloud Functions have a maximum execution timeout of 9 minutes for all runtimes

AnswersA, C

Cloud Functions scale out to handle multiple events concurrently.

Why this answer

Cloud Functions automatically scale horizontally based on the number of incoming events, such as HTTP requests or Pub/Sub messages. The platform handles this scaling transparently, spinning up new function instances as needed to handle concurrent invocations, and scaling down to zero when idle. This is a key serverless characteristic that eliminates the need for manual capacity planning.

Exam trap

The PCD exam often tests the misconception that Cloud Functions are limited to HTTP triggers or that the 9-minute timeout applies to all runtimes and trigger types, when in fact event-driven functions have a significantly longer timeout and multiple trigger options exist.

Practice this question →

MCQmedium

A team is deploying a containerized application to Cloud Run. The application needs to process large files (up to 500 MB) uploaded by users. Which storage approach should they use to avoid Cloud Run's request size limit?

A.Upload files directly to Cloud Run

B.Mount a Cloud Filestore volume

C.Use Cloud Functions as a proxy for uploads

D.Use signed URLs to upload to Cloud Storage

AnswerD

Signed URLs enable direct client-to-Cloud Storage uploads, bypassing Cloud Run's request size limit.

Why this answer

Cloud Run has a default request size limit of 32 MB, which is far below the 500 MB files the application needs to process. Using signed URLs allows users to upload files directly to Cloud Storage, bypassing Cloud Run entirely. This approach avoids the request size limit and offloads the storage and retrieval of large files to a scalable, managed service.

Exam trap

The PCD exam often tests the misconception that Cloud Run can handle large request payloads by scaling, but the actual trap is that Cloud Run's request size is hard-limited to 32 MB, and candidates may overlook the need to offload uploads to a dedicated storage service like Cloud Storage.

How to eliminate wrong answers

Option A is wrong because Cloud Run enforces a 32 MB request size limit (configurable up to 32 MB), so uploading files directly to the container would fail for files up to 500 MB. Option B is wrong because Cloud Filestore is a network file system for GCE and GKE, not supported as a mounted volume in Cloud Run; Cloud Run only supports mounting Cloud Storage buckets via FUSE or NFS-like volumes. Option C is wrong because Cloud Functions also has a request size limit (10 MB for HTTP triggers), so using it as a proxy would still be constrained and adds unnecessary latency and complexity without solving the size limitation.

Practice this question →

MCQeasy

A company runs a web application on Google Kubernetes Engine (GKE) that uses Cloud SQL for its database. The application is deployed via Cloud Build and uses a custom container image stored in Artifact Registry. Recently, the development team noticed that new deployments are failing with a 'CrashLoopBackOff' error in the pod logs. The logs indicate that the application cannot connect to the Cloud SQL instance. The application uses the Cloud SQL Proxy sidecar container to connect. The Cloud SQL Proxy configuration has not changed recently. The GKE cluster is in region us-central1, and the Cloud SQL instance is in us-central1 as well. The team verified that the Cloud SQL instance is running and accepting connections from authorized networks. They also confirmed that the service account used by the pod has the 'Cloud SQL Client' role. The application has been running stable for months until a recent GKE cluster upgrade. The deployment YAML uses environment variables for database connection. The Cloud SQL Proxy is deployed as a sidecar container with command: '/cloud_sql_proxy -instances=<instance-connection-name>=tcp:5432'. The pod logs show the proxy attempting to connect but timing out. The network team confirms that there are no firewall rules blocking the connection. The Cloud SQL instance has an authorized network entry for the GKE cluster's nodes' IP range. What is the most likely cause of the connection failure?

A.The Cloud SQL Proxy container is using an outdated version that is incompatible with the current Cloud SQL API.

B.The application is using a wrong database password in the connection string.

C.The pod's namespace does not have the Cloud SQL Proxy configuration correctly set up.

D.The Cloud SQL instance is configured with a private IP and the GKE cluster is VPC-native but the Cloud SQL Proxy is configured to connect via public IP.

AnswerD

The proxy defaults to public IP; with a private IP instance and no public IP, connection times out.

Why this answer

The Cloud SQL Proxy sidecar is configured to connect via public IP (using the instance connection name without the `-private-ip` flag), but the Cloud SQL instance is configured with a private IP. Since the GKE cluster is VPC-native, the pod can reach the private IP within the VPC, but the proxy is attempting a public IP connection, which fails because the instance's authorized networks only include the GKE nodes' IP range (public IPs of nodes), not the pod's private IP range. The recent GKE cluster upgrade may have changed the node's public IP or networking configuration, exacerbating the mismatch.

Exam trap

The PCD exam often tests the distinction between public and private IP connectivity for Cloud SQL Proxy, where candidates assume the proxy automatically uses the correct IP based on the instance configuration, but it requires an explicit flag to use private IP.

How to eliminate wrong answers

Option A is wrong because the Cloud SQL Proxy version compatibility with the Cloud SQL API is not a common cause of timeout errors; the proxy uses the same SQL protocol and API version regardless of minor version changes. Option B is wrong because the error is a connection timeout, not an authentication failure; a wrong password would result in an 'access denied' error, not a timeout. Option C is wrong because the Cloud SQL Proxy configuration is defined in the pod spec, not at the namespace level; the proxy's command-line arguments are set in the container definition, and the namespace does not affect proxy connectivity.

Practice this question →

MCQhard

A company has a monorepo with multiple services. They want to only build and test the services that have changed in a given commit. Which Cloud Build feature should they use?

A.Build triggers with filepath filters

B.Use a custom builder image

C.Build triggers with branch filters

D.Use Cloud Build substitutions

AnswerA

Filepath filters (included_files/ignored_files) limit the trigger to specific paths, enabling per-service builds.

Why this answer

Cloud Build triggers with filepath filters allow you to specify glob patterns that match changed files in a commit. When a commit includes changes only to files matching the filter, the trigger runs; otherwise, it is skipped. This enables selective building and testing of only the services that have changed in a monorepo, avoiding unnecessary builds for unaffected services.

Exam trap

Google often tests the distinction between filepath filters (which conditionally trigger builds based on changed files) and branch filters (which trigger builds based on branch names), leading candidates to mistakenly choose branch filters when the requirement is to build only changed services.

How to eliminate wrong answers

Option B is wrong because a custom builder image customizes the build environment (e.g., pre-installed tools) but does not provide any mechanism to conditionally trigger builds based on which files changed. Option C is wrong because branch filters trigger builds on specific branches (e.g., main or feature branches) regardless of which files changed, so they cannot restrict builds to only changed services. Option D is wrong because Cloud Build substitutions are user-defined variables that can be passed into build steps, but they do not control trigger conditions or filter builds based on file changes.

Practice this question →

MCQeasy

A developer wants to run integration tests against a Cloud Spanner emulator in a local development environment. What is the best way to set up the emulator?

A.Use a mock library instead of an emulator.

B.Use the Cloud Spanner API directly without an emulator.

C.Run the Cloud Spanner emulator Docker container and set the SPANNER_EMULATOR_HOST environment variable.

D.Install the emulator using `gcloud emulators spanner start`.

AnswerC

Docker ensures a consistent environment and easy setup.

Why this answer

The Cloud Spanner emulator is distributed as a Docker container, and the recommended way to run it locally is to start that container and set the `SPANNER_EMULATOR_HOST` environment variable (e.g., `localhost:9010`) so that the Spanner client library redirects all API calls to the emulator instead of the production service. This provides a fully functional, in-memory Spanner instance for integration testing without incurring costs or requiring network access to GCP.

Exam trap

The Google PCD exam often tests the distinction between `gcloud emulators` commands that exist (Datastore, Firestore, Pub/Sub, Bigtable) and those that do not (Spanner), leading candidates to incorrectly assume `gcloud emulators spanner start` is valid when the correct approach is to run the Docker container and set the environment variable.

How to eliminate wrong answers

Option A is wrong because using a mock library (e.g., mocking the Spanner client) would test only the mock's behavior, not the actual Spanner API interactions, and would miss integration issues like schema validation, transaction semantics, or query syntax errors that the emulator catches. Option B is wrong because calling the Cloud Spanner API directly without an emulator would require a live GCP project, incur costs, and introduce network latency and authentication overhead, which defeats the purpose of a local, isolated development environment. Option D is wrong because `gcloud emulators spanner start` is not a valid command; the `gcloud emulators` subcommand supports Datastore, Firestore, Pub/Sub, and Bigtable, but not Spanner — Spanner's emulator is only available as a Docker image.

Practice this question →

Multi-Selecteasy

Which TWO statements about building container images for Google Cloud Run are correct? (Choose TWO.)

Select 2 answers

A.The container must use HTTP/1.1; HTTP/2 is not supported.

B.The container must respond to health checks on the same port as the main application.

C.The container must be stateless and not rely on local file system persistence.

D.The container must listen on port 8080 by default.

E.The container must run as root user.

AnswersB, C

Health checks are sent to the container's port; the app must respond with 200 OK.

Why this answer

Cloud Run requires the container to respond to health checks (e.g., HTTP GET /health) on the same port as the main application. Cloud Run uses the same port for both user requests and health check probes; if the health check fails, the container is restarted. This ensures the container is always ready to serve traffic.

Exam trap

The PCD exam often tests the misconception that Cloud Run mandates port 8080 or requires HTTP/1.1, but the actual requirement is that the container must respond to health checks on the same port as the main application and must be stateless.

Practice this question →

MCQhard

A company uses Cloud Build to build Docker images and push them to Artifact Registry. They want to ensure that only images built from a specific Cloud Build trigger are deployed to production. Which combination of steps should they implement?

A.Configure IAM roles to restrict push access to Artifact Registry

B.Configure Binary Authorization with a policy requiring attestation from Cloud Build

C.Use Cloud Deploy with a manual approval gate

D.Use Cloud Build's built-in approval mechanism

AnswerB

Binary Authorization can enforce that only images with a valid attestation from Cloud Build are deployed.

Why this answer

Binary Authorization enforces deployment-time policies that require images to have a valid attestation from an approved authority. By configuring Cloud Build to create an attestation for images built from the specific trigger, and setting a Binary Authorization policy that requires that attestation, only those attested images can be deployed to production. This directly ensures that only images from that trigger are used.

Exam trap

The trap here is that candidates often confuse IAM-based access control (Option A) with deployment-time policy enforcement, failing to realize that IAM cannot distinguish images built from different triggers once they are in the registry.

How to eliminate wrong answers

Option A is wrong because IAM roles control who can push to Artifact Registry, not which specific images (e.g., from a particular trigger) are allowed to be deployed; it cannot enforce a policy based on the build source. Option C is wrong because Cloud Deploy with a manual approval gate adds a human review step but does not cryptographically verify that the image originated from a specific Cloud Build trigger; it relies on manual judgment, not automated attestation. Option D is wrong because Cloud Build's built-in approval mechanism only controls whether a build proceeds, not whether the resulting image is allowed to be deployed; it does not provide deployment-time enforcement.

Practice this question →

MCQmedium

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

A.Increase the concurrency setting to 200 to allow each instance to handle more requests simultaneously, reducing queuing.

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

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

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

AnswerA

Higher concurrency fully utilizes instance capacity.

Why this answer

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

Exam trap

The trap here is that candidates assume low CPU usage means the application is not busy, when in fact the bottleneck is I/O wait from the database call, and increasing concurrency allows the instance to handle more work during those I/O waits.

How to eliminate wrong answers

Option B is wrong because migrating to GKE adds operational complexity and is unnecessary; Cloud Run already scales automatically and the issue is concurrency, not scaling logic. Option C is wrong because increasing CPU limits does not speed up the database call itself—the bottleneck is the external database latency, not local CPU processing. Option D is wrong because increasing the minimum instances to 50 would waste resources and increase cost; the current minimum of 5 is sufficient since CPU usage is low, and the real problem is that each instance is underutilized due to low concurrency.

Practice this question →

MCQeasy

Refer to the exhibit. The Cloud Build fails with an error that the image name is invalid. What is the most likely cause?

A.The push step should be after the deploy step.

B.The substitution variable $MY_PROJECT is not a valid substitution because it is not prefixed with underscore.

C.The Docker build step fails because the Dockerfile is missing.

D.The image name contains uppercase letters that are not allowed.

AnswerB

User-defined substitutions must start with underscore; $MY_PROJECT is not valid.

Why this answer

In Cloud Build, user-defined substitution variables must be prefixed with an underscore. The variable `$MY_PROJECT` lacks the required underscore prefix, making it invalid. This causes the image name to be malformed, leading to the 'invalid image name' error.

Exam trap

Google Cloud Build often tests the subtle distinction between default substitutions (like `$PROJECT_ID`) and user-defined substitutions (which require an underscore prefix), leading candidates to assume all variables follow the same syntax.

How to eliminate wrong answers

Option A is wrong because the push step must occur after the build step, not after the deploy step; the deploy step typically comes after the push. Option C is wrong because the error message specifically states the image name is invalid, not that the Dockerfile is missing; a missing Dockerfile would produce a different error. Option D is wrong because image names in Cloud Build can contain uppercase letters; the error is due to the substitution variable syntax, not the case of the characters.

Practice this question →

MCQmedium

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

A.Create an interleaved table for 'Status' values.

B.Create a secondary index on the 'Status' column.

C.Increase the number of nodes in the Spanner instance.

D.Use stale reads with a 15-second staleness.

AnswerB

A secondary index enables index scans on 'Status', drastically reducing read latency.

Why this answer

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

Exam trap

The PCD exam often tests the misconception that scaling nodes or using stale reads can fix query performance issues caused by missing indexes, but the correct solution is always to optimize the data access pattern with an appropriate index.

How to eliminate wrong answers

Option A is wrong because an interleaved table is designed to store child rows physically co-located with a parent row, which helps for hierarchical queries but does not help with filtering on a non-key column like 'Status'; it would increase storage costs without addressing the query pattern. Option C is wrong because increasing the number of nodes improves throughput and capacity but does not directly reduce latency for a specific query that requires scanning many rows; it is a costly scaling measure that does not fix the root cause. Option D is wrong because stale reads reduce latency by reading from replicas with slightly outdated data, but they do not eliminate the need to scan the entire table; the query still suffers from high latency due to the full scan, and staleness introduces data freshness trade-offs.

Practice this question →

MCQhard

A developer is debugging a Cloud Function that fails with a timeout. The function makes multiple synchronous external API calls. What is the best way to improve performance and avoid timeouts?

A.Increase the timeout of the Cloud Function to the maximum of 9 minutes.

B.Use Firestore transactions to batch API calls.

C.Use Pub/Sub to trigger another function for each API call.

D.Use Cloud Tasks to offload the API calls asynchronously.

AnswerD

Cloud Tasks allows the function to return quickly and processes requests later.

Why this answer

Cloud Tasks is the best choice because it allows you to offload synchronous external API calls to be executed asynchronously, decoupling the Cloud Function from the slow external services. This prevents the function from timing out while waiting for responses, and Cloud Tasks handles retries and scheduling automatically, improving overall reliability and performance.

Exam trap

The PCD exam often tests the misconception that increasing timeout or using Pub/Sub is the correct solution for synchronous blocking operations, but the key is to use a dedicated task queue service like Cloud Tasks that provides asynchronous execution with built-in retry and decoupling.

How to eliminate wrong answers

Option A is wrong because simply increasing the timeout to the maximum of 9 minutes does not address the root cause—the function is still blocking on synchronous API calls, which could still exceed even the maximum timeout and waste resources. Option B is wrong because Firestore transactions are designed for atomic database operations, not for batching external API calls; they cannot make HTTP requests or improve the performance of external API calls. Option C is wrong because using Pub/Sub to trigger another function for each API call introduces unnecessary complexity and latency; Pub/Sub is a message queue for event-driven architectures, not designed for offloading synchronous tasks with retry logic like Cloud Tasks.

Practice this question →

MCQmedium

A development team is implementing a CI/CD pipeline using Cloud Build. They need to ensure that sensitive data, such as API keys, are never exposed in build logs. What is the best practice?

A.Use Cloud Build's encrypted variables or Secret Manager to pass secrets at build time.

B.Store the API keys in a separate file in the source repository and reference it in the build.

C.Use custom substitutions with default values and rely on Cloud Build's encryption.

D.Store the API keys as plain text in cloudbuild.yaml and restrict access to the file.

AnswerA

Secrets can be passed at runtime and are not logged.

Why this answer

Cloud Build's encrypted variables and Secret Manager are designed to securely inject sensitive data like API keys at build time without exposing them in logs. Encrypted variables are stored in Cloud KMS and decrypted only during the build, while Secret Manager provides versioned secrets with fine-grained access control. This ensures secrets never appear in plaintext in the build configuration or output logs.

Exam trap

The PCD exam often tests the misconception that storing secrets in a separate file in the source repository or using file permissions is sufficient, when in fact any plaintext storage in version control or build configuration risks exposure in logs or repository history.

How to eliminate wrong answers

Option B is wrong because storing API keys in a separate file in the source repository still commits them to version control, which can be exposed via branch history, forks, or accidental public access. Option C is wrong because custom substitutions with default values are not inherently encrypted; they are plaintext in the build configuration and can appear in logs if not carefully managed, and Cloud Build does not automatically encrypt substitutions. Option D is wrong because storing API keys as plaintext in cloudbuild.yaml, even with restricted file access, leaves them visible in the build configuration and logs, and file permissions do not prevent exposure during build execution or in stored artifacts.

Practice this question →

Multi-Selecthard

A developer wants to ensure their Cloud Function is reliable. Which three testing practices should they follow? (Choose three.)

Select 3 answers

A.Write unit tests that mock external services

B.Use the Cloud Functions Framework to run the function locally

C.Write integration tests that use the Cloud Functions Emulator or a test project

D.Deploy the function to production for integration testing

E.Perform load testing using a Cloud Scheduler job that invokes the function frequently

AnswersA, B, C

Unit tests verify logic in isolation, increasing confidence in code correctness.

Why this answer

Unit tests should mock external services (like databases or APIs) to isolate the function's logic and avoid dependencies on live infrastructure. This ensures tests are fast, deterministic, and do not incur costs or side effects from actual service calls.

Exam trap

The PCD exam often tests the distinction between deployment strategies and testing practices, where candidates mistakenly treat production deployment or scheduler-based invocation as valid testing methods instead of using isolated, controlled environments.

Practice this question →

MCQeasy

A developer needs to ensure that environment variables containing secrets are securely passed to a Cloud Function during deployment. Which approach should they use?

A.Store in source code

B.Use Cloud KMS

C.Use Secret Manager

D.Use runtime environment variables

AnswerC

Secret Manager provides secure storage, versioning, and fine-grained access control, and is the best practice for secrets.

Why this answer

Secret Manager is the recommended Google Cloud service for securely storing and accessing secrets such as API keys, passwords, and certificates. It provides encryption at rest and in transit, fine-grained IAM access control, and versioning, allowing the Cloud Function to reference secrets by name at deployment time without exposing them in source code or configuration files.

Exam trap

The trap here is that candidates confuse Cloud KMS (a key encryption service) with Secret Manager (a secret storage service), or assume runtime environment variables are secure because they are not in source code, ignoring that they are stored in plain text in the deployment metadata.

How to eliminate wrong answers

Option A is wrong because storing secrets in source code exposes them in version control systems, violates security best practices, and increases the risk of accidental exposure. Option B is wrong because Cloud KMS is a key management service for encryption keys, not a secret storage service; it does not provide native secret versioning or direct integration with Cloud Functions for secret injection. Option D is wrong because runtime environment variables are set in plain text in the function configuration and can be viewed by anyone with access to the Cloud Console or deployment logs, offering no encryption or access control for secrets.

Practice this question →

MCQhard

Refer to the exhibit. A developer deployed a Cloud Run service as shown. Authenticated requests from another service in the same project using a service account receive 403 Forbidden. What is the most likely cause?

A.The Cloud Run service requires the 'allAuthenticatedUsers' member to be added

B.The --no-allow-unauthenticated flag blocks all requests including authenticated ones

C.The service account used to authenticate is not granted the roles/run.invoker role on the Cloud Run service

D.The container image was built without proper authentication headers

AnswerC

The IAM policy must grant invoker role to the service account.

Why this answer

The Cloud Run service requires the IAM role `roles/run.invoker` on the service itself for any principal (including a service account) to invoke it. Since the service was deployed with `--no-allow-unauthenticated`, only explicitly granted principals can invoke it. The service account used for authentication lacks this role, causing the 403 Forbidden response.

Exam trap

The PCD exam often tests the misconception that `--no-allow-unauthenticated` blocks all requests, including authenticated ones, when in reality it only blocks unauthenticated requests and requires explicit IAM role assignment for authenticated principals.

How to eliminate wrong answers

Option A is wrong because adding `allAuthenticatedUsers` would allow any authenticated Google identity (including service accounts) to invoke the service, but the question states the service account is already authenticated yet receives 403, so the issue is not about allowing all authenticated users—it's about granting the specific invoker role to that service account. Option B is wrong because `--no-allow-unauthenticated` does not block authenticated requests; it only blocks unauthenticated requests. Authenticated requests are still processed but must be from a principal with the `roles/run.invoker` role.

Option D is wrong because authentication headers are not part of the container image; they are provided by the client at request time. The container image itself does not control IAM authorization.

Practice this question →

MCQmedium

A company uses Cloud Build to build and deploy a microservice. The build step that runs tests fails with a permission denied error when trying to access a private GitHub repository. The build configuration uses a default Cloud Build service account. The team has already added the GitHub repository as a trigger and provided credentials during trigger creation. However, the build step still fails. What is the most likely cause and solution?

A.Create a new service account with access to the secret containing the GitHub SSH key and use it in the build configuration.

B.Use Cloud Build's '--no-cache' flag to force a fresh clone.

C.Add a build step to run 'git config' to set user credentials.

D.Grant the Cloud Build service account the role 'Cloud Build Service Agent'.

AnswerA

Using a custom service account with IAM permissions to access the secret allows the build step to authenticate to GitHub.

Why this answer

Cloud Build uses the Cloud Build service account by default for executing build steps. To access private GitHub repositories, the build step must authenticate using the SSH key or access token stored in Secret Manager, and the Cloud Build service account needs permissions to read the secret. The error suggests the build step does not have the necessary authentication.

Using a custom service account with required permissions and retrieving the secret in the build step is the correct approach. The trigger credentials are only for triggering the build, not for build steps.

Practice this question →

MCQmedium

A team deploys a stateful application on GKE using StatefulSets. They need to test data persistence after pod rescheduling. Which test scenario best validates this?

A.Use a CronJob to regularly snapshot the data

B.Delete a pod and verify the new pod has the same data from PersistentVolumeClaim

C.Scale down the StatefulSet to 0 and scale up again, then check data

D.Delete the entire cluster and recreate it from backups

AnswerB

This directly tests the scenario of pod rescheduling and PVC data persistence.

Why this answer

Deleting a pod in a StatefulSet triggers Kubernetes to reschedule a new pod with the same identity and PersistentVolumeClaim (PVC). The PVC retains the data from the original pod, so verifying that the new pod has the same data directly confirms that the PersistentVolume (PV) is correctly bound and the data persists across pod rescheduling. This tests the core persistence guarantee of StatefulSets without altering the replica count or cluster state.

Exam trap

The PCD exam often tests the misconception that scaling down to 0 and up is equivalent to pod rescheduling, but the trap here is that scaling down releases PVCs (depending on the volumeClaimTemplate policy) and may not preserve data if the StatefulSet is configured with a non-default PVC retention policy, whereas deleting a single pod always reuses the same PVC.

How to eliminate wrong answers

Option A is wrong because using a CronJob to snapshot data tests backup mechanisms, not the inherent persistence of StatefulSet PVCs after pod rescheduling; it introduces an external process that could mask failures in PVC binding. Option C is wrong because scaling down to 0 and up again tests StatefulSet ordinal recreation and PVC reattachment, but it is a more disruptive test that may not isolate the specific behavior of pod rescheduling (e.g., node failure or manual deletion) and can trigger additional orchestration logic like headless service DNS updates. Option D is wrong because deleting the entire cluster and recreating from backups tests disaster recovery, not the immediate data persistence guarantee of StatefulSets after a pod is rescheduled within the same cluster.

Practice this question →

MCQeasy

A team deploys a containerized web application on Cloud Run. The deployment fails with error 'Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.' The container image runs fine locally on port 8080. The team has not set any environment variables in the Cloud Run service configuration. What is the most likely issue and solution?

A.Set the PORT environment variable to 8080 in the Cloud Run service configuration.

B.Configure a health check for the container.

C.Increase the container concurrency setting.

D.Set min instances to 1 to keep the container warm.

AnswerA

This ensures the container listens on the expected port. Cloud Run injects PORT but the container must use it.

Why this answer

Cloud Run expects the container to listen on the port specified by the PORT environment variable, which defaults to 8080. Since the team did not set any environment variables, Cloud Run assigns PORT=8080 automatically. The container runs fine locally on port 8080, but the error indicates it is not listening on the port defined by PORT.

The most likely issue is that the container is hardcoded to listen on port 8080 but does not respect the PORT environment variable, or the application is binding to a different interface (e.g., localhost) that Cloud Run cannot reach. Setting the PORT environment variable explicitly to 8080 in the Cloud Run service configuration ensures the container listens on the expected port.

Exam trap

The PCD exam often tests the misconception that the PORT environment variable is optional or that Cloud Run will automatically map a hardcoded port; the trap here is that candidates assume the container's hardcoded port 8080 will work without explicitly setting the PORT variable, but Cloud Run strictly requires the container to listen on the port specified by the PORT environment variable, which defaults to 8080 only if the container respects it.

How to eliminate wrong answers

Option B is wrong because configuring a health check does not resolve a port mismatch; health checks only verify that the container is responding after it starts, but they cannot fix a failure to bind to the correct port. Option C is wrong because increasing container concurrency affects how many requests the container can handle simultaneously, not which port it listens on. Option D is wrong because setting min instances to 1 keeps the container warm but does not address the port binding issue; the container would still fail to start if it does not listen on the correct port.

Practice this question →

MCQeasy

A developer is writing a Cloud Function that throws an exception when processing invalid input. They want to ensure the function returns an appropriate HTTP error response. What should they do?

A.Log the error and return a success response

B.Return a response with a status code and error message from the function

C.Use a global error handler in the function framework

D.Throw an exception and let the platform handle it automatically

AnswerB

This gives the client a clear error and allows custom status codes.

Why this answer

In Cloud Functions (and serverless platforms like Google Cloud Functions), the function code itself is responsible for constructing and returning an HTTP response, including setting the appropriate status code and error message. Throwing an exception alone does not automatically map to an HTTP error response; the platform will typically return a generic 500 error, which is not appropriate for invalid input (e.g., 400 Bad Request). By explicitly returning a response object with a status code (e.g., 400) and a descriptive error message, the developer ensures the client receives a meaningful and correct HTTP error response.

Exam trap

The PCD exam often tests the misconception that throwing an exception in a serverless function automatically results in a proper HTTP error response, when in reality the platform returns a generic 500 error, and the developer must explicitly return the response with the correct status code and message.

How to eliminate wrong answers

Option A is wrong because logging the error and returning a success response (e.g., 200 OK) violates HTTP semantics — the client would incorrectly believe the request succeeded, masking the invalid input issue. Option C is wrong because while some function frameworks (e.g., Express.js) support global error handlers, Cloud Functions (especially in a serverless context like Google Cloud Functions) do not have a built-in global error handler that automatically converts exceptions to structured HTTP responses; the developer must explicitly return the response. Option D is wrong because throwing an exception and letting the platform handle it automatically results in a generic 500 Internal Server Error response, which is not appropriate for invalid input (which should be a 4xx error) and does not provide a custom error message.

Practice this question →

MCQeasy

A developer is using Cloud Functions and wants to ensure that their testing environment mirrors production as closely as possible. Which approach should they take?

A.Use Cloud Build to run tests before deployment

B.Run all tests in Cloud Shell

C.Deploy to a staging Cloud Function and run tests against it

D.Use the Functions Framework with a simulated production event

AnswerD

The Functions Framework provides the same runtime and event format, enabling near-identical local testing.

Why this answer

The Functions Framework is a local emulator that allows developers to run Cloud Functions locally with the same invocation context and event triggers as in production. By using the Functions Framework with a simulated production event, you can test your function's behavior, including event data parsing and response handling, without deploying to any cloud environment, ensuring the testing environment mirrors production as closely as possible.

Exam trap

The PCD exam often tests the misconception that deploying to a staging environment is the best way to mirror production, but the Functions Framework provides a more accurate and efficient local simulation without the overhead of cloud deployment.

How to eliminate wrong answers

Option A is wrong because Cloud Build runs tests in a build pipeline environment that does not replicate the Cloud Functions runtime, event triggers, or execution context, so it cannot mirror production behavior. Option B is wrong because Cloud Shell provides a generic Linux environment without the Cloud Functions runtime or event simulation, and tests run there do not reflect production execution conditions. Option C is wrong because deploying to a staging Cloud Function introduces network latency, cold starts, and potential differences in resource quotas or IAM permissions compared to local testing, and it does not guarantee the same event simulation as the Functions Framework.

Practice this question →

MCQhard

A team uses Cloud Tasks to process orders asynchronously. Each order is enqueued after payment verification. Processing involves calling an external shipping API that occasionally returns 503 (Service Unavailable). The Cloud Tasks queue is configured with default retry parameters: max retries = 100, max retry duration = 1 hour. The team notices that some orders are never processed; they remain in the queue until the max retry duration expires and then are discarded. What is the most likely cause and solution?

A.Increase the max retry duration to 24 hours.

B.Set a custom retry deadline of 2 hours.

C.Use exponential backoff in the task handler instead of relying on Cloud Tasks.

D.Check the task queue rate limits and increase max dispatches per second.

AnswerA

A longer retry duration allows tasks to survive extended outages and eventually succeed.

Why this answer

The default Cloud Tasks retry parameters include a max retry duration of 1 hour. If an order repeatedly fails due to 503 errors from the external shipping API, the task will be retried up to 100 times within that hour. However, if the API remains unavailable for longer than the max retry duration, the task will be discarded even if the retry count hasn't been exhausted.

Increasing the max retry duration to 24 hours gives the external API more time to recover, ensuring that orders are not prematurely discarded.

Exam trap

The PCD exam often tests the distinction between retry count and retry duration — candidates mistakenly think increasing the number of retries or adjusting backoff will solve the problem, but the real issue is that the default max retry duration is too short to cover extended outages.

How to eliminate wrong answers

Option B is wrong because setting a custom retry deadline (e.g., 2 hours) does not address the root cause — the 1-hour max retry duration is too short; a 2-hour deadline would still be insufficient if the API is down for longer. Option C is wrong because implementing exponential backoff in the task handler is redundant; Cloud Tasks already supports exponential backoff by default, and the issue is the max retry duration, not the backoff strategy. Option D is wrong because increasing max dispatches per second would only increase the rate at which tasks are sent to the handler, but the problem is that tasks are being discarded after the max retry duration expires, not that they are being throttled.

Practice this question →

MCQmedium

Your team is building a Node.js application for Google App Engine Standard Environment. The application uses a custom runtime and must run background tasks. However, you notice that background tasks are being terminated after a few seconds. What is the most likely reason?

A.The application should use Cloud Tasks instead of background threads

B.The application is not configured with max_concurrent_requests set to 1

C.You are using an automatic scaling instance class that does not support background threads

D.App Engine Standard Environment does not support background threads; use App Engine Flexible or Cloud Run instead

AnswerD

The standard environment terminates any thread not serving a request.

Why this answer

In Google App Engine Standard Environment, background threads are not supported because the runtime can terminate idle instances or scale down to zero, killing any background tasks. The correct solution is to use App Engine Flexible Environment or Cloud Run, which support long-running background processes, or to offload tasks to a service like Cloud Tasks or Cloud Pub/Sub. Option D correctly identifies this fundamental limitation of the Standard Environment.

Exam trap

The PCD exam often tests the misconception that background threads can be enabled by adjusting scaling settings or instance classes, when in reality the Standard Environment's sandbox prohibits them entirely, and the correct answer is to switch to a different compute environment.

How to eliminate wrong answers

Option A is wrong because Cloud Tasks is a service for managing task queues and retries, but it does not solve the underlying issue of background thread termination in the Standard Environment; the application still cannot run background threads locally. Option B is wrong because max_concurrent_requests is a scaling setting that controls how many requests a single instance can handle concurrently, not a setting that enables or disables background threads. Option C is wrong because automatic scaling instance classes in App Engine Standard Environment do not support background threads regardless of the class; this is a platform-level restriction, not a scaling configuration issue.

Practice this question →

100

Multi-Selecteasy

Which TWO are benefits of using Cloud Build? (Choose two.)

Select 2 answers

A.It allows using custom build steps with community or private images

B.It offers a fully managed CI/CD platform for building, testing, and deploying

C.It only supports Java and Go runtimes

D.It requires a trigger to start any build

E.It provides a source code repository for version control

AnswersA, B

Custom build steps provide flexibility.

Why this answer

Cloud Build allows you to use custom build steps with community or private container images, enabling you to run arbitrary tools and scripts as part of your build pipeline. This flexibility means you are not limited to Google-provided build steps and can integrate any software that runs in a container.

Exam trap

The PCD exam often tests the misconception that Cloud Build is a full CI/CD platform with built-in version control, but it is actually a build service that relies on external repositories for source code management.

Practice this question →

101

MCQmedium

You are designing a CI/CD pipeline for a microservices application deployed on GKE. Your team requires that each service have independent release cycles and canary deployments. Which combination of Google Cloud services should you use?

A.Cloud Source Repositories, Cloud Build, and App Engine

B.Cloud Source Repositories, Cloud Build, and Cloud Run

C.Cloud Source Repositories, Cloud Build, and Cloud Deploy with GKE target

D.Cloud Source Repositories, Cloud Build, and Spinnaker

AnswerC

Cloud Deploy supports GKE and canary deployments.

Why this answer

Cloud Deploy provides native support for canary deployments and progressive delivery strategies to GKE targets, enabling independent release cycles per microservice. Cloud Source Repositories hosts the code, Cloud Build compiles and tests it, and Cloud Deploy manages the rollout with Skaffold-based pipelines, allowing fine-grained traffic splitting and automated promotion or rollback.

Exam trap

The trap here is that candidates may confuse Cloud Run's traffic splitting with full canary deployment orchestration, or assume App Engine's flexible environment can target GKE, when in fact Cloud Deploy is the only Google Cloud service designed specifically for progressive delivery to GKE targets.

How to eliminate wrong answers

Option A is wrong because App Engine is a fully managed platform that does not support GKE as a deployment target and lacks native canary deployment capabilities for microservices with independent release cycles. Option B is wrong because Cloud Run is a serverless container platform that does not target GKE clusters, and while it supports traffic splitting, it cannot orchestrate canary deployments across multiple microservices on GKE. Option D is wrong because Spinnaker is a third-party CD tool that requires significant operational overhead to integrate with GKE, and the question asks for a combination of Google Cloud services, not a third-party solution.

Practice this question →

102

MCQmedium

A company uses Cloud Build to build multiple microservices. They want to reuse a set of build steps across all services. What is the most maintainable approach?

A.Copy the steps into each service's cloudbuild.yaml

B.Use Cloud Build substitutions

C.Create a custom builder image with the steps

D.Use Cloud Build triggers with a common config file

AnswerB

Substitutions allow you to define a single build configuration with variables that change per service, promoting reuse.

Why this answer

Cloud Build substitutions allow you to define reusable variables in a central configuration, enabling you to parameterize build steps across multiple microservices without duplicating code. By referencing substitution variables (e.g., $_SERVICE_NAME) in a single cloudbuild.yaml, you can maintain one source of truth for common steps, making updates easier and reducing errors. This approach is more maintainable than copying steps because changes propagate automatically to all services.

Exam trap

The PCD exam often tests the misconception that a custom builder image is the best way to reuse build steps, but the trap is that a custom builder only encapsulates the runtime environment, not the step definitions themselves, whereas substitutions allow you to reuse the exact same step definitions across services with different parameters.

How to eliminate wrong answers

Option A is wrong because copying steps into each service's cloudbuild.yaml violates the DRY principle and creates maintenance overhead—any change must be manually replicated across all services, increasing the risk of inconsistencies. Option C is wrong because creating a custom builder image encapsulates the build tools but does not directly reuse the build step definitions; you would still need to invoke the builder in each service's config, and updating the steps requires rebuilding and redeploying the image, which is less flexible than using substitutions. Option D is wrong because Cloud Build triggers with a common config file still require each trigger to reference that file, but the config file itself cannot be dynamically parameterized per service without substitutions; triggers alone do not solve the reuse of steps across different services with varying parameters.

Practice this question →

103

MCQeasy

A developer is building a Cloud Function that processes Pub/Sub messages. They want to run the function locally with simulated events before deployment. Which tool should they use?

A.Cloud Scheduler

B.Functions Framework

C.Cloud Build

D.Cloud Shell

AnswerB

Functions Framework is the official local development tool for Cloud Functions, allowing you to run functions locally and send simulated Pub/Sub messages.

Why this answer

The Functions Framework is the correct tool because it provides a local development server that emulates the Cloud Functions runtime environment, allowing developers to invoke functions with simulated Pub/Sub events via HTTP requests. This enables testing and debugging of event-driven logic before deploying to production, without requiring actual Google Cloud infrastructure.

Exam trap

The trap here is that candidates may confuse Cloud Shell's built-in development environment with a dedicated local emulator, but Cloud Shell lacks the Functions Framework's ability to simulate specific event types like Pub/Sub messages.

How to eliminate wrong answers

Option A is wrong because Cloud Scheduler is a cron job service for scheduling recurring tasks, not a local development tool for simulating events. Option C is wrong because Cloud Build is a CI/CD service for building and deploying artifacts, not for local function testing with simulated events. Option D is wrong because Cloud Shell is a browser-based terminal environment with pre-installed tools, but it does not provide a local emulator for Cloud Functions; the Functions Framework must be installed and run separately.

Practice this question →

104

MCQmedium

A developer uses the above cloudbuild.yaml. The build fails with error: 'unauthorized: You don't have the permission to push to this repository.' What is the most likely cause?

A.The image tag 'latest' is invalid

B.The Docker registry URL is incorrect

C.The project ID 'my-project' is misspelled

D.The Cloud Build service account does not have Artifact Registry Writer role

AnswerD

The service account needs the Writer role to push images; without it, push is unauthorized.

Why this answer

The error 'unauthorized: You don't have the permission to push to this repository' indicates that the Cloud Build service account lacks the necessary IAM permissions to push the container image to Artifact Registry. By default, Cloud Build uses the default compute engine service account (PROJECT_NUMBER-compute@developer.gserviceaccount.com) or a user-specified service account, which must have the Artifact Registry Writer role (roles/artifactregistry.writer) to push images. Without this role, the push is denied regardless of the image tag, registry URL, or project ID spelling.

Exam trap

The PCD exam often tests the distinction between authentication/authorization errors and configuration errors (like invalid tags or URLs), so the trap here is that candidates may confuse a permission issue with a typo or invalid tag, especially when the error message says 'unauthorized' but the real root cause is missing IAM roles.

How to eliminate wrong answers

Option A is wrong because the 'latest' tag is a valid and commonly used tag; an invalid tag would cause a different error (e.g., 'invalid reference format'), not an authorization error. Option B is wrong because an incorrect Docker registry URL would result in a 'not found' or 'connection refused' error, not an 'unauthorized' permission error. Option C is wrong because a misspelled project ID would cause a 'project not found' or 'invalid project ID' error, not an authorization failure; the error message specifically mentions lack of permission, not an invalid project.

Practice this question →

105

MCQhard

A company is using Cloud Deploy to manage canary deployments to GKE. They want to automatically promote a release to the 'production' target if the canary deployment in the 'staging' target passes a set of automated smoke tests. What is the required configuration?

A.Create a Cloud Build trigger to redeploy on test success.

B.Define a deployment verifier in the pipeline that runs smoke tests and promotes on success.

C.Configure a manual approval gate between staging and production in the delivery pipeline.

D.Set the 'automaticPromotion' flag to true on the staging target.

AnswerB

Verifiers can automatically promote based on test results.

Why this answer

Cloud Deploy supports deployment verifiers, which are custom Cloud Build jobs that run as part of a rollout. By defining a verifier in the pipeline that executes automated smoke tests, the canary deployment in the staging target can be automatically promoted to production only if the verifier succeeds. This integrates testing directly into the delivery pipeline without manual intervention.

Exam trap

The trap here is that candidates confuse the 'automaticPromotion' flag with a test-gated promotion, not realizing that automatic promotion simply skips manual approval but does not add any verification step; a verifier is required to enforce test-based promotion.

How to eliminate wrong answers

Option A is wrong because a Cloud Build trigger is an external event-driven mechanism, not a native part of the Cloud Deploy pipeline; it would require separate orchestration and does not automatically tie into the rollout promotion logic. Option C is wrong because a manual approval gate requires human intervention, which contradicts the requirement for automatic promotion based on test success. Option D is wrong because the 'automaticPromotion' flag on a target controls whether the rollout automatically advances to the next target in the pipeline, but it does not incorporate smoke test verification; it would promote unconditionally without waiting for test results.

Practice this question →

106

MCQhard

You are a developer for an e-commerce platform running on Google Kubernetes Engine (GKE) with a Cloud SQL backend. The application uses Cloud Memorystore for Redis for session caching. During a flash sale, you notice that the application latency spikes and some users are unable to complete checkout. You suspect the Redis instance is overwhelmed. The Redis instance is currently a Standard tier instance with 5 GB of memory. You need to increase throughput without significant architectural changes. You have the following options: A) Use client-side caching to reduce load on the Redis instance. B) Switch to a Memorystore Standard tier instance with a higher capacity and enable scaling. C) Migrate to a Memorystore Basic tier instance with a larger memory size. D) Enable for Redis clustering on the existing instance to distribute load across shards. Which option should you choose?

A.Use client-side caching to reduce load on the Redis instance.

B.Switch to a Memorystore Standard tier instance with a higher capacity and enable scaling.

C.Migrate to a Memorystore Basic tier instance with a larger memory size.

D.Enable for Redis clustering on the existing instance to distribute load across shards.

AnswerB

Enabling clustering on an existing instance is not possible without creating a new clustered instance; this requires significant architectural changes.

Why this answer

Enabling scaling on a Memorystore Standard tier instance allows you to increase the instance's capacity and throughput without architectural changes. Scaling up the memory size increases the available CPU and network bandwidth, directly addressing the latency spike during the flash sale. This approach maintains the existing Redis configuration and requires no application code changes, unlike clustering or client-side caching.

Exam trap

The PCD exam often tests the misconception that Redis clustering is the only way to scale throughput, but in Memorystore, clustering requires a new instance and is not a simple enablement on an existing instance. Vertical scaling a Standard tier instance (option B) is the correct answer for immediate relief without architectural changes.

How to eliminate wrong answers

Option A is wrong because client-side caching reduces network round trips but does not increase the throughput of the Redis instance itself; the Redis instance remains the bottleneck under high load. Option C is wrong because migrating to a Basic tier instance removes replication and high availability, which is a significant architectural change and does not inherently increase throughput beyond what scaling the Standard tier provides. Option D is wrong because enabling Redis clustering on an existing instance is not supported in Memorystore; clustering requires creating a new cluster instance, which is a significant architectural change and not a simple scaling operation.

Practice this question →

107

MCQhard

A developer is designing a CI/CD pipeline for a Node.js application hosted on Cloud Run using Cloud Build. The pipeline should run unit tests, build the container, push to Artifact Registry, and deploy to Cloud Run. The developer wants to minimize build time by caching dependencies. What is the recommended approach?

A.Run npm install locally and commit the node_modules folder to the repository for faster builds.

B.Use Cloud Build's step-level caching by copying the node_modules from a previous build step.

C.Create a custom base image that includes all dependencies and reference it in the Dockerfile.

D.Use Cloud Build's built-in caching with a persistent volume to store node_modules between builds.

AnswerD

Cloud Build's volume caching allows dependency caching across builds.

Why this answer

Cloud Build supports built-in caching via persistent volumes (e.g., `/cache` or `/workspace`) that can store `node_modules` across builds. By configuring a cache volume in the `cloudbuild.yaml` and using `npm ci --prefer-offline`, the pipeline avoids re-downloading dependencies on every run, significantly reducing build time for Node.js applications on Cloud Run.

Exam trap

The PCD exam often tests the misconception that committing `node_modules` or using custom base images are efficient caching strategies, but the correct approach is to use Cloud Build's native persistent volume caching, which is purpose-built for this scenario.

How to eliminate wrong answers

Option A is wrong because committing `node_modules` to the repository bloats the repo, violates best practices (dependencies should be installed via `package.json`), and can cause platform-specific issues. Option B is wrong because Cloud Build does not support step-level caching by copying `node_modules` from a previous step; each step runs in a fresh container, so copying would require manual persistence and is not a recommended or built-in feature. Option C is wrong because creating a custom base image with all dependencies reduces flexibility (requires rebuilding the base image for any dependency change) and does not leverage Cloud Build's native caching mechanisms, often leading to longer overall build times.

Practice this question →

108

MCQeasy

A developer deployed a Cloud Function that is triggered by a Pub/Sub topic. The function processes messages and writes results to a BigQuery table. The developer notices that some messages are not being processed; they are visible in the Pub/Sub subscription but the function logs show no invocation for those messages. The function's code is correct and handles errors gracefully. What is the most likely cause and fix?

A.Increase the function timeout to 540 seconds.

B.Check that the Pub/Sub subscription push endpoint is set to the Cloud Function URL.

C.Increase the function memory to 2GB.

D.Enable retry on failure for the Pub/Sub subscription.

AnswerD

If the function fails without returning success, the message may be lost. Retry ensures it is reprocessed.

Why this answer

The Pub/Sub subscription has a default 'ack deadline' and if the Cloud Function does not acknowledge the message within that time (or if the function fails to process it and the subscription is not configured to retry), the message may be redelivered but eventually dropped. Enabling retry on failure ensures that messages that cause the function to fail (even if the code handles errors gracefully, the function might still return an error status) are retried until successfully processed.

Exam trap

The PCD exam often tests the misconception that increasing timeout or memory solves invocation issues, when the real problem is that the function is not being triggered due to missing retry configuration or ack deadline expiry.

How to eliminate wrong answers

Option A is wrong because increasing the function timeout to 540 seconds would not help if the function is never invoked for those messages; the issue is about invocation, not execution duration. Option B is wrong because Cloud Functions triggered by Pub/Sub use a push subscription, but the endpoint is automatically set by Google Cloud when you deploy the function with a Pub/Sub trigger; manually checking or setting it is unnecessary and not the cause of missing invocations. Option C is wrong because increasing memory does not affect whether the function is invoked; it only affects the resources available during execution, and the problem is that the function is not being called at all for those messages.

Practice this question →

109

MCQeasy

Refer to the exhibit. A developer is configuring Cloud Build to build a Docker image from a Cloud Source Repository. The build fails with a permission error. What is the most likely reason?

A.The service account lacks the roles/cloudbuild.builds.builder role

B.The service account is missing the roles/source.reader role to access the repository

C.The Cloud Source Repository does not have the build trigger enabled

D.The build config file is missing the 'source' field

AnswerB

Cloud Build needs source.reader to read the repository.

Why this answer

The build fails with a permission error because the Cloud Build service account does not have the `roles/source.reader` role on the Cloud Source Repository. Without this role, the service account cannot read the source code from the repository, which is required to trigger the build. The error is not about building permissions but about accessing the source.

Exam trap

The PCD exam often tests the distinction between build execution permissions (roles/cloudbuild.builds.builder) and source access permissions (roles/source.reader), leading candidates to incorrectly choose the builder role when the actual error is about reading the source repository.

How to eliminate wrong answers

Option A is wrong because the `roles/cloudbuild.builds.builder` role is required for executing builds, but the error here is a permission error related to accessing the source repository, not a lack of build execution permissions. Option C is wrong because a build trigger is not required for a manual build from a Cloud Source Repository; the build can be started directly via the API or gcloud command. Option D is wrong because the `source` field is not mandatory in a build config file; the source can be specified in the build trigger or API call, and its absence would cause a different error (e.g., 'source not specified'), not a permission error.

Practice this question →

110

Multi-Selecthard

Which THREE steps are required to set up a CI/CD pipeline for Cloud Run using Cloud Build and GitHub? (Choose THREE.)

Select 3 answers

A.Enable the Cloud Build, Cloud Run, and Artifact Registry APIs.

B.Grant the Cloud Build service account permission to deploy to Cloud Run.

C.Create a cloudbuild.yaml file in the repository root.

D.Push the container image to Container Registry.

E.Mirror the GitHub repository to Cloud Source Repositories.

AnswersA, B, C

These APIs must be enabled for the pipeline to work.

Why this answer

To set up a CI/CD pipeline for Cloud Run using Cloud Build and GitHub, three steps are required: (A) enable the Cloud Build, Cloud Run, and Artifact Registry APIs; (B) grant the Cloud Build service account permission to deploy to Cloud Run; and (C) create a cloudbuild.yaml file in the repository root. Option D is incorrect because Container Registry is deprecated and Cloud Run typically uses Artifact Registry. Mirroring the GitHub repository to Cloud Source Repositories (E) is optional, not required.

Practice this question →

111

MCQeasy

Refer to the exhibit. A developer writes the above Dockerfile for a Cloud Run service. The service fails to start. The logs indicate that the container exited immediately. What is the most likely cause?

A.The WORKDIR is set to a directory that doesn't exist

B.The server.js file is missing from the build context

C.The CMD instruction is incorrectly formatted

D.The EXPOSE 8080 instruction is unnecessary and may cause conflicts

AnswerB

If server.js is not copied into the image (e.g., it's in a different directory or excluded by .dockerignore), the container has no entrypoint and exits immediately.

Why this answer

The most likely cause is that the server.js file is missing from the build context. When the Dockerfile contains a COPY command (e.g., COPY . .) to copy application files, the server.js file must exist in the source directory from which the build is run. If it is absent, the container will have no entry point, and the CMD instruction (e.g., CMD ["node", "server.js"]) will fail because the file does not exist inside the image, causing the container to exit immediately.

Cloud Run requires the container to start a listening process; without server.js, no process runs.

Exam trap

The PCD exam often tests the misconception that a missing WORKDIR or an incorrect CMD format is the root cause, but the real issue is that the application file (server.js) is not copied into the image, leading to an immediate container exit.

How to eliminate wrong answers

Option A is wrong because the WORKDIR instruction creates the directory if it does not exist, so setting it to a non-existent directory does not cause a failure. Option C is wrong because the CMD instruction is correctly formatted as a JSON array (e.g., CMD ["node", "server.js"]), which is the proper exec form; an incorrectly formatted CMD would typically produce a syntax error during build, not a runtime exit. Option D is wrong because the EXPOSE 8080 instruction is purely documentation and does not cause conflicts; Cloud Run ignores EXPOSE and uses the PORT environment variable, so it is harmless.

Practice this question →

112

MCQhard

You are building a data pipeline using Cloud Dataflow (Apache Beam). The pipeline reads from Pub/Sub, performs aggregations, and writes to BigQuery. Occasionally, you see duplicates in the BigQuery output, even though the pipeline uses .withInsertId() in the BigQuery write transform. What could be causing these duplicates?

A.You are not using the exactly-once sink option for BigQuery

B.You have set .withOutputParallelization() to false

C.The pipeline is using at-least-once mode and bundles are being retried, but the insertId is not being reused across retry attempts

D.You need to enable Dataflow's built-in deduplication using the .withIdAttribute() in Pub/Sub read

AnswerC

If the insertId is generated per element per attempt, duplicates can occur on retry.

Why this answer

Cloud Dataflow (Apache Beam) operates in at-least-once mode by default, meaning bundles may be retried during processing. When a bundle is retried, the insertId set via .withInsertId() must be reused across retry attempts to enable BigQuery's deduplication. If the insertId is not reused (e.g., because it's generated per attempt or not properly propagated), BigQuery treats each write as a separate row, resulting in duplicates.

Exam trap

The PCD exam often tests the misconception that .withInsertId() alone guarantees exactly-once delivery, when in fact it requires the insertId to be stable across retries, and candidates may overlook the default at-least-once processing mode of Dataflow.

How to eliminate wrong answers

Option A is wrong because BigQuery's exactly-once sink is not a configurable option; BigQuery uses insertId-based deduplication for streaming inserts, and there is no separate 'exactly-once sink' toggle. Option B is wrong because .withOutputParallelization() controls whether output is parallelized across workers, not retry behavior or deduplication; setting it to false would not cause duplicates. Option D is wrong because .withIdAttribute() in Pub/Sub read is used to extract a unique message ID for deduplication within the pipeline, but the question specifically states duplicates appear in BigQuery output despite using .withInsertId(), indicating the issue is with insertId reuse across retries, not with Pub/Sub message deduplication.

Practice this question →

113

MCQeasy

A developer wants to run a single test suite across multiple environments (dev, staging, prod) using Cloud Build. What is the best practice?

A.Use Cloud Deploy to run tests in each environment.

B.Use separate branches for each environment.

C.Use a single Cloud Build trigger with substitutions to parameterize the environment.

D.Create separate Cloud Build triggers for each environment.

AnswerC

Substitutions allow dynamic values for environment-specific variables.

Why this answer

Cloud Build triggers support substitutions (e.g., `$_ENV`) that allow a single trigger to parameterize the environment variable, enabling the same test suite to run across dev, staging, and prod without duplicating configuration. This aligns with Infrastructure as Code (IaC) principles and reduces maintenance overhead.

Exam trap

The PCD exam often tests the misconception that separate triggers or branches are required for environment isolation, when in fact Cloud Build's substitution mechanism is the recommended approach for parameterizing a single pipeline across multiple environments.

How to eliminate wrong answers

Option A is wrong because Cloud Deploy is designed for continuous delivery (rolling out releases to target environments), not for running test suites; it does not execute Cloud Build steps or test commands. Option B is wrong because using separate branches for each environment violates Git-based best practices (e.g., GitFlow or trunk-based development) and introduces merge conflicts, drift, and manual overhead. Option D is wrong because creating separate triggers for each environment duplicates configuration, increases maintenance burden, and violates DRY (Don't Repeat Yourself) principles; substitutions achieve the same goal more efficiently.

Practice this question →

114

MCQmedium

A team uses Cloud Build to build and deploy a Node.js application to App Engine flexible environment. The build succeeds, but the deployment fails with 'ERROR: (gcloud.app.deploy) Error Response: [9] Application startup error!' The team checks logs and sees 'Error: Module not found: 'express''. What is the most likely cause?

A.The build step includes 'npm test' which fails.

B.The Node.js version specified in app.yaml is incompatible with the dependencies.

C.The app.yaml file is missing from the root of the repository.

D.The dependencies are not installed during the build step before deploying.

AnswerD

Dependencies must be installed (e.g., npm install) for the app to run.

Why this answer

The error 'Module not found: express' indicates that the Node.js dependencies (specifically the 'express' package) are not present in the deployed application. In Cloud Build, the build steps must explicitly install dependencies (e.g., via 'npm install') before the deploy step. If the build configuration does not include an 'npm install' step, the dependencies listed in package.json are not copied to the App Engine flexible environment, causing the startup error.

Exam trap

Google often tests the distinction between build-time and deployment-time errors, and the trap here is that candidates might confuse a missing app.yaml (a configuration error) with a missing dependency (a runtime error), or assume that npm install is automatically performed by Cloud Build when it is not.

How to eliminate wrong answers

Option A is wrong because 'npm test' failure would cause the build step to fail, not the deployment step; the error message specifically says the build succeeded but deployment failed. Option B is wrong because an incompatible Node.js version would typically cause a different error (e.g., syntax errors or runtime crashes), not a 'Module not found' error for a specific package. Option C is wrong because a missing app.yaml would cause a different error (e.g., 'ERROR: (gcloud.app.deploy) Could not find app.yaml') before the deployment even starts, not a startup error after deployment.

Practice this question →