Building and testing applications practice questions

Configure mutual TLS (mTLS) between services using Cloud Endpoints.

Why wrong: Cloud Run does not support mTLS natively; IAM-based authentication is preferred.

Deploy a sidecar proxy on each Cloud Run service to handle TLS termination.

Why wrong: Cloud Run does not support sidecar proxies; it uses built-in IAM authentication.

Assign a service account to each service and use its private key to sign requests.

Why wrong: Service account keys are not used for signing requests in Cloud Run; IAM tokens are used.

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

Why wrong: Committing node_modules is not best practice and increases repository size.

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

Why wrong: Step-level caching does not persist across separate builds.

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

Why wrong: This approach works but is less flexible and requires maintaining the base image.

Docker container with a custom entrypoint.

Why wrong: This is possible but not the recommended or simplest approach.

gcloud functions call command.

Why wrong: This command invokes a deployed function, not local testing.

Cloud Code for VS Code or IntelliJ.

Why wrong: Cloud Code uses Functions Framework internally but is an IDE extension, not the core tool.

Implement rate limiting in the backend code and enforce it via Cloud Endpoints.

Why wrong: Cloud Endpoints does not provide mechanisms to enforce rate limiting based on user identity.

Configure Cloud Armor with a rule to block requests from users exceeding a threshold.

Why wrong: Cloud Armor works at the IP level, not per user ID.

Use Cloud CDN with a cache key based on the user ID.

Why wrong: Cloud CDN caches content, it does not rate limit requests.

Load testing to simulate production traffic.

Why wrong: Load testing focuses on performance, not functional interaction validation.

Unit testing with mocked dependencies.

Why wrong: Unit tests test individual components, not service interactions.

End-to-end testing in a staging environment.

Why wrong: End-to-end tests require a deployed environment; the team wants to avoid full cluster deployment.

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

Why wrong: Cloud Run supports HTTP/2 (gRPC).

The container must listen on port 8080 by default.

Why wrong: The container must listen on the port defined by the PORT environment variable, which is 8080 by default but can be changed.

The container must run as root user.

Why wrong: Cloud Run recommends running as non-root for security.

Push the container image to Container Registry.

Why wrong: Container Registry is deprecated; Artifact Registry is the recommended service.

Mirror the GitHub repository to Cloud Source Repositories.

Why wrong: Cloud Build can connect directly to GitHub; mirroring is not required.

Increase the Pub/Sub subscription acknowledgment deadline

Why wrong: This affects message redelivery but not the Cloud Run request timeout.

Enable CPU always allocation for the Cloud Run service

Why wrong: This prevents CPU throttling but does not change the request timeout.

Add retry logic with exponential backoff for Firestore operations

Why wrong: Retry logic helps with transient failures but not with timeouts caused by long operations.

Cloud Functions

Why wrong: Cloud Functions can be triggered by events but is not a CI/CD service.

Cloud Deploy

Why wrong: Cloud Deploy handles delivery, not build triggering.

App Engine

Why wrong: App Engine is for hosting applications, not for CI/CD pipelines.

Modify the startup script to recover state from a snapshot

Why wrong: Snapshots are for persistent disks, not local SSDs; also recovery from snapshot is not real-time.

Configure the managed instance group as stateful to preserve local SSD data

Why wrong: Stateful MIGs preserve instance name and disks but local SSDs are still ephemeral.

Use a regular (non-preemptible) VM instead of preemptible

Why wrong: This avoids preemption but increases cost; the question asks for best practice with preemptible VMs.

Store user credentials in a configuration file

Why wrong: User credentials are not intended for applications and pose a security risk.

Use an API key for Cloud Storage

Why wrong: API keys are less secure and not recommended for server-to-server communication.

Generate an access token and embed it in the code

Why wrong: Hardcoding tokens is insecure; tokens also expire and need rotation.

Deploy the application on Compute Engine with Windows Server

Why wrong: This is a possible alternative but not the recommended approach for Cloud Run; the question asks for deploying to Cloud Run.

Use Cloud Run for Anthos on a Windows node pool

Why wrong: Cloud Run for Anthos also requires Linux containers.

Use a Windows base image and deploy to Cloud Run

Why wrong: Cloud Run only supports Linux containers.

Use API keys to authenticate end users

Why wrong: API keys are for project identification, not user authentication.

Deploy Cloud Endpoints as a sidecar container in the same Cloud Run instance

Why wrong: Cloud Endpoints is deployed as a separate service, not as a sidecar.

Configure Cloud Armor rules to enforce rate limiting before requests reach Endpoints

Why wrong: Cloud Armor is a separate service; Endpoints handles rate limiting via the OpenAPI spec.

Use the Cloud Run emulator to run the service locally

Why wrong: There is no Cloud Run emulator; you deploy to Cloud Run for end-to-end tests.

Use the Firestore emulator to simulate Firestore operations

Why wrong: Emulators are for unit tests; end-to-end tests should use real services.

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

Why wrong: That would allow any authenticated user; best practice is to grant only specific service accounts.

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

Why wrong: It blocks unauthenticated requests; authenticated requests are allowed if IAM permits.

The container image was built without proper authentication headers

Why wrong: Authentication headers are handled by the client, not the container.

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

Why wrong: It already has that role as shown in the exhibit.

The Cloud Source Repository does not have the build trigger enabled

Why wrong: The trigger is separate; the error is during build, not trigger.

The build config file is missing the 'source' field

Why wrong: The error is about permissions, not configuration.

Compute Engine

Why wrong: Compute Engine provides virtual machines, not pipeline orchestration.

Cloud Run

Why wrong: Cloud Run is a compute platform for running containers, not a CI/CD pipeline service.

Cloud Functions

Why wrong: Cloud Functions is for event-driven compute, not for CI/CD pipelines.

Use Cloud Build's built-in test runner that automatically fails the build on test failure.

Why wrong: Cloud Build does not have a built-in test runner; it relies on the exit code of the command.

Create a custom builder that runs tests and emits a non-zero exit code on failure.

Why wrong: While a custom builder could work, it's overkill; standard images already return exit codes.

Add a pre-build step that checks test results and triggers a build failure if needed.

Why wrong: Pre-build steps run before the main build; test results are not available at that point.

Enable Cloud CDN to cache the images at edge locations.

Why wrong: Cloud CDN caches content but is intended for content delivery, not for reducing small read overhead in a backend application.

Rewrite the objects to use a different storage class.

Why wrong: Storage class affects cost and availability, not read latency for small requests.

Mount the Cloud Storage bucket using Cloud Storage FUSE and read files from the local filesystem.

Why wrong: Cloud Storage FUSE may increase latency for random reads and is not designed for high-throughput scenarios.

Set the 'max-instances' parameter to limit the number of instances handling requests.

Why wrong: max-instances controls concurrency, not traffic splitting.

Use the 'gcloud run deploy' command with '--tag' to assign a tag to the new revision, then direct test traffic to that tag.

Why wrong: Tags are used for internal testing without routing production traffic, but they don't support percentage-based traffic splitting.

Deploy the new revision with the same revision name as the old one to overwrite it, then roll back if issues occur.

Why wrong: This does a full replacement, not a canary or gradual rollout.