PCD Building and testing applications Practice Test 4 — 15 Questions

Question 1

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 2

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 locally with Docker allows rapid iteration without the overhead of building and pushing to a registry and redeploying. Staging deployment is slower. Traffic splitting is for production traffic management. Cloud Run for Anthos is for hybrid deployments.

Answer

Deploy to a staging Cloud Run service

Answer

Use traffic splitting to test a new revision

Answer

Use Cloud Run for Anthos

Question 3

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. Option C is correct because 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 4

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?

Accepted Answer

Use Cloud Build substitutions. 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.

Answer

Copy the steps into each service's cloudbuild.yaml

Answer

Create a custom builder image with the steps

Answer

Use Cloud Build triggers with a common config file

Question 5

A team is setting up a CI/CD pipeline for a Node.js App Engine application using Cloud Build. The source code is in Cloud Source Repositories. What must be configured to automatically run unit tests before deployment?

Accepted Answer

Add a cloudbuild.yaml file with a test step. Option C is correct because Cloud Build uses a cloudbuild.yaml file to define build steps, and adding a test step ensures unit tests run automatically before deployment. Without this configuration, Cloud Build will not execute tests; it only runs the steps explicitly defined in the build configuration file.

Answer

Enable Cloud Build triggers on the repository

Answer

Use the App Engine deployment wizard

Answer

Use a Dockerfile to run tests

Question 6

During a Cloud Build run, a developer sees the error: "Step #0: error: failed to fetch metadata: connection refused". The build is trying to access a private Docker registry in a different project. What is the most likely cause?

Accepted Answer

The build environment cannot reach the registry due to network restrictions. The error message indicates a network connectivity issue, not authentication. The most common cause is that the build environment cannot reach the registry due to VPC Service Controls, firewall rules, or the registry being in a different network. Authentication errors typically show "denied" or "unauthorized".

Answer

The registry does not exist

Answer

The build service account lacks IAM permissions to the registry

Answer

The build is using a public pool with no access to internal networks

Question 7

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 support filepath filters (also called 'included files' and 'ignored files'), which allow the trigger to fire only when changes occur in specific paths. This is ideal for monorepos. Branch filters are for branches, not files. Substitutions are variables, not filtering. Custom builders don't provide this logic.

Answer

Use a custom builder image

Answer

Build triggers with branch filters

Answer

Use Cloud Build substitutions

Question 8

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?

Accepted Answer

Use the Functions Framework with a simulated production event. 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.

Answer

Use Cloud Build to run tests before deployment

Answer

Run all tests in Cloud Shell

Answer

Deploy to a staging Cloud Function and run tests against it

Question 9

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

Use Cloud Build's built-in caching feature by specifying a volume. Cloud Build provides a built-in caching feature that allows you to persist directories across build steps by specifying a volume in the `cloudbuild.yaml` configuration. By mounting a volume (e.g., `/go/pkg/mod`) and using the `cache` option, the Go module cache is retained between builds, significantly reducing dependency download time. This approach is native to Cloud Build and requires no external services or custom builders.

Answer

Use a custom builder that pre-installs dependencies

Answer

Set up a bucket for caching and use substitutions

Answer

Use a Kaniko cache with a remote repository

Question 10

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 11

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 12

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 is correct because 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.

Answer

Cloud Build queue

Answer

Cloud Build substitutions

Answer

Cloud Source Repositories mirror

Question 13

Refer to the exhibit. A developer uses the above cloudbuild.yaml for a Cloud Run service. The trigger is set to run on pushes to the main branch. After a push, the build succeeds but the deployment fails with a permission error. What is the most likely issue?

Accepted Answer

The Cloud Build service account lacks permission to deploy to Cloud Run. The Cloud Build service account (typically the default compute engine service account or a user-specified service account) does not have the required IAM roles (e.g., roles/run.admin or roles/run.invoker) to deploy to Cloud Run. Even though the build step succeeds, the deployment step fails because the service account lacks the `run.services.create` or `run.services.update` permission for the target Cloud Run service.

Answer

The region 'us-central1' is incorrect

Answer

The container image tag ${SHORT_SHA} is invalid

Answer

The Cloud Run service name 'my-service' is misspelled

Question 14

Refer to the exhibit. A developer runs the above command to deploy a Cloud Function triggered by Pub/Sub. The function fails to execute when a message is published. The logs show: "Function execution took 60001 ms, finished with status: 'timeout'". What should the developer do?

Accepted Answer

Check the function code for long-running operations. The timeout error indicates the Cloud Function is exceeding its maximum execution duration. The default timeout for Cloud Functions is 60 seconds, and the logs confirm the function ran for 60001 ms before being forcibly terminated. The most likely cause is that the function code contains long-running operations (e.g., synchronous HTTP calls, database queries, or heavy computation) that do not complete within the allotted time. Therefore, the developer should inspect and optimize the function code to reduce execution time, such as by using asynchronous processing or breaking the work into smaller chunks.

Answer

Change the trigger to HTTP

Answer

Reduce the number of function instances

Answer

Increase the function timeout to 9 minutes

Question 15

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?

Accepted Answer

The server.js file is missing from the build context. 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.

Answer

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

Answer

The CMD instruction is incorrectly formatted

Answer

The EXPOSE 8080 instruction is unnecessary and may cause conflicts