PCD Building and testing applications Practice Test 8 — 15 Questions

Question 1

A team uses GitHub for source control. They want to automatically trigger Cloud Build builds on pull request creation. Which two actions are required? (Choose two.)

Accepted Answer

Install the Cloud Build GitHub app in the repository. Option A is correct because connecting a GitHub repository to Cloud Build requires installing the Cloud Build GitHub app (from the GitHub Marketplace) on the repository, which grants Cloud Build the webhook and OAuth permissions needed to receive repository events. Option B is correct because the trigger must be configured with the 'pull_request' event so Cloud Build fires when a pull request is created or updated, matching the team's requirement. Option C is wrong because Cloud Build's GitHub integration is handled by the GitHub app's automatic webhooks, not by manually configuring a webhook to send push events. Option D is wrong because mirroring GitHub into Cloud Source Repositories is unnecessary and would not by itself trigger builds on pull request creation. Option E is wrong because 'push' events and a 'pull-request/*' branch filter do not correspond to pull request creation; the correct event is 'pull_request'.

Answer

Configure a webhook in GitHub to send push events to Cloud Build

Answer

Use Cloud Source Repositories as a mirror of GitHub

Answer

In the Cloud Build trigger, set the event to 'push' and branch filter to 'pull-request/*'

Question 2

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

Accepted Answer

Write unit tests that mock external services. Option A is correct because unit tests that mock external services (e.g., using libraries like sinon or unittest.mock) isolate the function's business logic from network dependencies such as Firestore, Pub/Sub, or third-party APIs, making tests fast, deterministic, and reliable. Option B is correct because the Cloud Functions Framework lets developers run the function locally in the same runtime environment, enabling rapid iteration and catching runtime errors before deployment. Option C is correct because integration tests using the Cloud Functions Emulator or a dedicated test project validate the function's behavior against real or emulated Google Cloud services, verifying triggers, IAM, and event payloads without affecting production. Option D is not appropriate because deploying to production for integration testing risks breaking live users and pollutes production data; testing should occur in isolated environments. Option E is not a testing practice for reliability—Cloud Scheduler invoking the function frequently performs load or smoke testing, which measures performance and availability but does not validate correctness, error handling, or edge cases.

Answer

Deploy the function to production for integration testing

Answer

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

Question 3

A company wants to deploy a containerized application to Cloud Run. Which two approaches are supported? (Choose two.)

Accepted Answer

Use gcloud beta run deploy with --source flag to build and deploy from source. Option A is correct because Cloud Run supports source-based deployments via the `gcloud beta run deploy --source` flag, which uses Cloud Build (with buildpacks) to automatically build the container image from source code and deploy it to Cloud Run. Option E is correct because the standard container-based workflow is to build the image locally with Docker, push it to a registry such as Artifact Registry (or Container Registry), and then deploy it using `gcloud run deploy --image` referencing that image. Option B is incorrect because Cloud Functions is a separate serverless product for functions, not a mechanism for packaging and deploying containers to Cloud Run. Option C is incorrect because the Cloud Run console does not accept a Dockerfile for server-side building; builds from source are done via gcloud/Cloud Build, not by uploading a Dockerfile to the console. Option D is incorrect because deploying to Kubernetes Engine (GKE) and then migrating is not a supported Cloud Run deployment approach; Cloud Run deploys containers directly from a registry or source.

Answer

Use Cloud Functions to package the container as a function

Answer

Upload a Dockerfile to Cloud Run console and let it build

Answer

Use Kubernetes Engine to deploy the container and then migrate to Cloud Run

Question 4

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?

Accepted Answer

The Cloud Build service account does not have Artifact Registry Writer role. 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.

Answer

The image tag 'latest' is invalid

Answer

The Docker registry URL is incorrect

Answer

The project ID 'my-project' is misspelled

Question 5

A developer runs the above command and receives a successful deployment. However, the service is not accessible from the internet. The service is intended to be public. What should the developer check next?

Accepted Answer

The service IAM policy to ensure allUsers has Cloud Run Invoker role. Cloud Run services are private by default; even after a successful deployment, the service will not be accessible from the internet unless the IAM policy explicitly grants the `roles/run.invoker` role to `allUsers`. Without this permission, any HTTP request from outside the project will be denied with a 403 Forbidden error, regardless of the service's health or region.

Answer

The region us-central1 is not available

Answer

The Cloud Run service has a custom domain mapped

Answer

The container image is healthy

Question 6

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?

Accepted Answer

Functions Framework. 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.

Answer

Cloud Scheduler

Answer

Cloud Build

Answer

Cloud Shell

Question 7

A developer wants to quickly test changes to a containerized web application that will run on Cloud Run, without building and deploying a new container. Which approach should they use?

Accepted Answer

Run locally with Docker. Running the container locally with Docker lets the developer iterate on code and rebuild the image on their workstation without pushing to a registry or creating a new Cloud Run revision, giving the fastest feedback loop. Cloud Run's local development workflow (e.g., docker run with the same port and environment variables) mirrors the runtime environment closely enough for quick testing. This avoids the build-and-deploy cycle entirely.

Answer

Deploy to a staging Cloud Run service

Answer

Use traffic splitting to test a new revision

Answer

Use Cloud Run for Anthos

Question 8

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

Accepted Answer

Use Secret Manager. 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.

Answer

Store in source code

Answer

Use Cloud KMS

Answer

Use runtime environment variables

Question 9

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?

Accepted Answer

Build triggers with filepath filters. 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.

Answer

Use a custom builder image

Answer

Build triggers with branch filters

Answer

Use Cloud Build substitutions

Question 10

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?

Accepted Answer

Set up a bucket for caching and use substitutions. 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.

Answer

Use a custom builder that pre-installs dependencies

Answer

Use a Kaniko cache with a remote repository

Answer

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

Question 11

A developer is building a containerized application on Cloud Run. They want to test the application locally before deploying. Which two tools should they use? (Choose 2)

Accepted Answer

Docker Desktop. Docker Desktop allows running the container locally. Cloud Code (for VS Code or IntelliJ) provides integrated debugging, local emulation, and one-click deployment to Cloud Run. Cloud Build is for CI/CD, not local testing. Functions Framework is for Cloud Functions, not Cloud Run. Cloud Run for Anthos is for hybrid environments.

Answer

Functions Framework

Answer

Cloud Build

Answer

Cloud Run for Anthos

Question 12

A team is implementing a CI/CD pipeline for a Cloud Function using Cloud Build. Which three steps should they include in their cloudbuild.yaml? (Choose 3)

Accepted Answer

Static code analysis. Static code analysis (A) is correct because it helps identify code quality issues, security vulnerabilities, and adherence to coding standards early in the pipeline, which is a best practice for Cloud Functions. Running unit tests (C) is essential to validate function logic before deployment. Deploying the function (B) is the final step that pushes the validated code to Cloud Functions, making it a required step in the CI/CD pipeline.

Answer

Build a container image

Answer

Manual approval step

Question 13

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)

Accepted Answer

Build scripts that detect changes. Option B (Build scripts that detect changes) is correct because a custom build script can inspect the Git diff or commit history (e.g., using git diff --name-only against the previous commit) to determine which module directories were modified and then conditionally invoke the build only for those modules. Option D (Cloud Build triggers with filepath filters) is correct because Cloud Build triggers support an includedFiles (or ignoredFiles) filter that uses glob patterns to fire a build only when files matching specific module paths change, so each module can have its own trigger scoped to its directory. Together, the filepath-filtered trigger ensures the build only starts when relevant files change, and the change-detection script further narrows the actual build steps to the affected modules. Option A (Cloud Build queue) is not correct because the queue only manages concurrent build execution and ordering, not selective module building. Option C (Cloud Build substitutions) is not correct because substitutions merely inject variable values into build configs and cannot by themselves detect which modules changed. Option E (Cloud Source Repositories mirror) is not correct because mirroring synchronizes repositories and does not provide change detection or conditional build logic.

Answer

Cloud Build queue

Answer

Cloud Build substitutions

Answer

Cloud Source Repositories mirror

Question 14

A team is developing a REST API on Cloud Run. They need to ensure that only authenticated requests from their corporate domain (example.com) are allowed. Which configuration should they use?

Accepted Answer

Set the Cloud Run service to require authentication and allow only the domain 'example.com' in the IAM policy. Cloud Run's IAM integration allows you to require authentication (via the `--no-allow-unauthenticated` flag) and then use IAM conditions to restrict access to principals from a specific domain (e.g., `request.auth.claims.email` ends with `@example.com`). This ensures only authenticated requests from the corporate domain are permitted, leveraging Google Cloud's identity-aware proxy (IAP) capabilities without additional infrastructure.

Answer

Implement custom authentication using Firestore to validate user tokens

Answer

Use Cloud Endpoints with an API key that is shared only with corporate users

Answer

Use Cloud Armor to deny traffic except from the corporate IP range

Question 15

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?

Accepted Answer

The pipeline is using at-least-once mode and bundles are being retried, but the insertId is not being reused across retry attempts. 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.

Answer

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

Answer

You have set .withOutputParallelization() to false

Answer

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