Courseiva

CCNA Cicd Pipelines Questions

67 questions · Cicd Pipelines topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
Drag & Dropmedium

Arrange the steps to recover a Google Cloud SQL instance from a point-in-time backup.

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

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

Why this order

The correct sequence for recovering a Google Cloud SQL instance from a point-in-time backup is: first, identify the exact point-in-time to recover; second, clone the instance to that time; third, verify the cloned instance's data; fourth, promote the clone to become the primary instance; and fifth, update application connections to use the new primary. This order ensures a consistent and verifiable recovery process.

Practice this question →
2
MCQhard

A team implements canary deployments using Cloud Deploy and deploys to GKE. They want to automatically roll back if the canary release's error rate exceeds 5% within 10 minutes. Which approach should they use?

A.Deploy using Spinnaker on GKE with a canary pipeline that includes an automated rollback step.
B.Configure a Cloud Build step to monitor the canary and rollback if needed.
C.Use a GKE rolling update strategy within the deployment manifest.
D.Set up Cloud Deploy with a rollout strategy that uses Cloud Monitoring metrics to automatically rollback.
AnswerD

Cloud Deploy can use a 'canary' strategy with metrics-based promotion/rollback.

Why this answer

Cloud Deploy can leverage Cloud Monitoring metrics as part of a rollout strategy to automatically roll back a canary deployment when the error rate exceeds a defined threshold (e.g., 5% within 10 minutes). Options A is incorrect because Spinnaker is not native to GCP and does not integrate seamlessly with Cloud Deploy; also Spinnaker is not the recommended tool for this scenario. Option B is incorrect because Cloud Build is intended for building and testing artifacts, not for real-time monitoring and rollback of deployments.

Option C is incorrect because a rolling update strategy does not support canary deployments or metric-based automatic rollback; it simply replaces pods gradually.

Practice this question →
3
MCQmedium

A company uses Cloud Build to compile a Java application. The build takes 15 minutes due to dependency downloads. They want to cache the Maven dependencies to speed up subsequent builds. What is the best approach?

A.Use a Cloud Storage bucket to store the .m2 directory and restore it at the start of the build.
B.Use a Docker layer caching with a custom image that includes dependencies.
C.Use Cloud Build's built-in caching mechanism by specifying volumes.
D.Use Cloud Build's 'cache' configuration to persist directories.
AnswerC

Cloud Build's built-in caching via volumes is the best integrated solution for persisting directories like .m2 across builds.

Why this answer

Cloud Build supports volumes that can be used to cache directories between builds. Specifically, you can specify a volume for the Maven local repository (.m2) to persist across runs, speeding up builds by avoiding repeated downloads. Option A is possible but less integrated and requires manual restoration.

Option B is not ideal because layer caching depends on Docker image caching, not Maven dependencies. Option D is not a native Cloud Build feature; the correct approach is via volumes.

Practice this question →
4
MCQmedium

A Cloud Build pipeline uses the above cloudbuild.yaml. When triggered, the deploy step fails with: 'ERROR: (gcloud.run.deploy) PERMISSION_DENIED: Permission 'run.services.update' denied on resource.' The Cloud Build service account has the 'Cloud Run Admin' role. What is the most likely cause?

A.The substitution variable ${_ENV} is not properly passed to the nested build.
B.The nested 'gcloud builds submit' command runs with a different service account that does not have the Cloud Run Admin role.
C.The 'gcr.io/cloud-builders/gcloud' image does not support the 'gcloud run deploy' command.
D.The Cloud Build service account at the top level does not have the 'run.services.update' permission.
AnswerB

Nested builds use the default Cloud Build service account of the second build, which may lack permissions.

Why this answer

When a Cloud Build pipeline uses a nested `gcloud builds submit` command, the nested build runs under the default Compute Engine service account (or a user-specified service account) rather than the top-level Cloud Build service account. Even if the top-level service account has the Cloud Run Admin role, the nested build's service account may lack the `run.services.update` permission, causing the deploy step to fail with PERMISSION_DENIED.

Exam trap

Google Cloud often tests the misconception that all steps in a Cloud Build pipeline share the same service account, when in fact nested builds use a different service account by default, leading to unexpected permission errors.

How to eliminate wrong answers

Option A is wrong because the substitution variable ${_ENV} is a user-defined substitution that is passed to the top-level build; if it were missing, the error would be about an undefined variable or incorrect resource name, not a permission denied error. Option C is wrong because the `gcr.io/cloud-builders/gcloud` image fully supports `gcloud run deploy`; it is the official Google-maintained image for running gcloud commands in Cloud Build. Option D is wrong because the problem statement explicitly says the Cloud Build service account has the 'Cloud Run Admin' role, which includes the `run.services.update` permission; the error arises from a different service account used in the nested build.

Practice this question →
5
MCQeasy

Which GCP service is used to store build artifacts such as Docker images?

A.Cloud Storage
B.Both Container Registry and Artifact Registry
C.Container Registry
D.Artifact Registry
AnswerC, D

Container Registry is a deprecated GCP service that stores Docker images. It is still functional.

Why this answer

Both Container Registry (option C) and Artifact Registry (option D) are GCP services that can store Docker images. Artifact Registry is the recommended service, but Container Registry is still functional. Option A, Cloud Storage, is for object storage, not specifically for container images.

Option B lists both services but is not a specific service name, so it is not the correct answer.

Practice this question →
6
MCQeasy

During a Cloud Build execution, a step fails due to timeout. What is the first thing to check?

A.Check network connectivity
B.Check the build logs for errors
C.Increase machine type for the build
D.Increase the timeout in cloudbuild.yaml
AnswerB

Logs provide details on what caused the step to hang or fail.

Why this answer

When a Cloud Build step fails due to a timeout, the build logs are the first and most authoritative source of diagnostic information. They contain the exact error messages, exit codes, and step output that reveal why the step exceeded its timeout — for example, a hanging command, a missing dependency, or a resource contention issue. Checking logs before making any configuration changes ensures you address the root cause rather than treating symptoms.

Exam trap

Google Cloud often tests the misconception that a timeout is always a performance or configuration issue, leading candidates to jump to increasing resources or timeout values, when the correct first step is always to inspect the build logs for the actual error.

How to eliminate wrong answers

Option A is wrong because network connectivity issues typically manifest as connection refused or DNS resolution errors, not as a generic timeout; the logs would still show those errors, so checking logs first is still the correct step. Option C is wrong because increasing the machine type addresses performance bottlenecks but does not fix a timeout caused by an infinite loop, a stuck process, or a misconfigured command — the logs must be examined first to determine if the timeout is due to resource starvation. Option D is wrong because increasing the timeout in cloudbuild.yaml only masks the underlying problem; if a step is hanging indefinitely, a longer timeout will just delay the failure, and the logs must be checked to understand why the step is not completing within the original limit.

Practice this question →
7
Multi-Selecteasy

Which TWO options are valid methods to trigger a Cloud Build build when code is pushed to a Cloud Source Repository?

Select 2 answers
A.Use a Cloud Pub/Sub message sent to the Cloud Build topic to create a build.
B.Have Cloud Logging monitor the repository and create a build via a logs-based metric.
C.Set up a Cloud Pub/Sub subscription that forwards events to Cloud Build.
D.Configure a Cloud Build trigger with a push event and a branch filter.
E.Configure Cloud Scheduler to call the Cloud Build API periodically.
AnswersA, D

Cloud Build can be triggered by Pub/Sub messages via a trigger.

Why this answer

Options A and D are correct. Cloud Build triggers can be based on branch or tag push, and can also be triggered via Pub/Sub message. Option B is incorrect - Cloud Build does not directly listen to Cloud Pub/Sub subscriptions without a trigger.

Option C is incorrect - builds are not automatically triggered by Cloud Logging. Option E is incorrect - Cloud Scheduler cannot directly trigger a build without a Pub/Sub or HTTP intermediary.

Practice this question →
8
Multi-Selectmedium

Which THREE are benefits of migrating from Jenkins to Cloud Build?

Select 3 answers
A.No server maintenance
B.Support for any VCS
C.Pay per use
D.Built-in security scanning
E.Native Google Cloud integration
AnswersA, C, E

Cloud Build is serverless.

Why this answer

Cloud Build is a fully managed CI/CD service that runs on Google Cloud's infrastructure, eliminating the need for users to provision, configure, or maintain build servers. Unlike Jenkins, which requires ongoing administration of the Jenkins master and agent nodes, Cloud Build automatically scales resources and handles underlying server maintenance, including OS patches and hardware failures.

Exam trap

Google Cloud often tests the misconception that Cloud Build supports any VCS or includes built-in security scanning, when in reality it has specific VCS integrations and relies on external tools for security scanning.

Practice this question →
9
MCQhard

A team is implementing a CI/CD pipeline for a Kubernetes application. They want to use canary deployments with traffic splitting. Which tool or service is best suited for this?

A.Cloud Run
B.Cloud Build
C.Cloud Deploy with Skaffold
D.Anthos Config Management
AnswerC

Cloud Deploy provides native support for canary deployments and traffic splitting via Skaffold.

Why this answer

Cloud Deploy with Skaffold is best suited for canary deployments with traffic splitting because Cloud Deploy provides built-in support for progressive delivery strategies, including canary and blue-green deployments, and integrates with Skaffold to manage Kubernetes manifests and traffic routing via service mesh or ingress controllers. Skaffold handles the build and deploy stages, while Cloud Deploy orchestrates the rollout with automated traffic splitting and promotion/rollback logic, making it the only option that directly addresses the requirement.

Exam trap

The trap here is that candidates often confuse Cloud Build (a build tool) with a full deployment orchestrator, or assume Cloud Run can handle Kubernetes canary deployments, but Cloud Deploy with Skaffold is the only option that provides native, automated traffic splitting for Kubernetes applications.

How to eliminate wrong answers

Option A is wrong because Cloud Run is a serverless compute platform for stateless containers, not a CI/CD pipeline tool, and it does not support traffic splitting for canary deployments in the same way as Kubernetes-based progressive delivery. Option B is wrong because Cloud Build is a CI/CD build and test service that compiles source code and creates artifacts, but it lacks native support for orchestrating canary deployments or traffic splitting on Kubernetes. Option D is wrong because Anthos Config Management is a policy and configuration management tool for enforcing cluster state and GitOps workflows, not a deployment pipeline service that handles traffic splitting or canary rollouts.

Practice this question →
10
MCQhard

A company uses Cloud Build with a custom service account that has minimal permissions. The build needs to deploy to Cloud Run. After configuring the service account with roles/run.admin, the build fails with 'Permission denied' on gcloud run deploy. What is the most likely cause?

A.The build service account lacks roles/iam.serviceAccountUser on the Cloud Run runtime service account.
B.The Cloud Run service account is not set.
C.Cloud Build requires the roles/cloudbuild.serviceAgent role.
D.The build configuration file has syntax errors.
AnswerA

Cloud Build needs to impersonate the runtime service account; roles/iam.serviceAccountUser is required.

Why this answer

When a Cloud Build service account with only roles/run.admin attempts to deploy to Cloud Run, it must also have the iam.serviceAccountUser role on the Cloud Run runtime service account to impersonate it. Without this, gcloud run deploy fails with 'Permission denied'. Option B is incorrect because an unset Cloud Run service account would result in a different error, typically about an unspecified service account, not a permission denied.

Option C is incorrect because roles/cloudbuild.serviceAgent is not required for deploying to Cloud Run; it's a broader role. Option D is unlikely because syntax errors would produce a build configuration parsing error, not a runtime permission denied.

Practice this question →
11
MCQmedium

A fintech company deploys a critical payment service on GKE using Cloud Deploy with a canary deployment strategy. They want to automatically roll back if the canary release causes an increase in error rates over 1%. They have set up Cloud Monitoring to expose a custom metric 'error_rate' from the service. They want Cloud Deploy to evaluate this metric during the canary phase and roll back if the threshold is exceeded. What is the minimal configuration needed?

A.In the Skaffold configuration, define a 'verify' section with a 'stackdriverMetrics' verification job that queries the 'error_rate' metric and sets a threshold. In Cloud Deploy, ensure the rollout strategy is 'canary' and no manual approval is required.
B.Install the Cloud Operations agent on the GKE nodes and configure Cloud Deploy to read the 'error_rate' metric from Cloud Monitoring by default.
C.Set the Cloud Deploy pipeline's 'strategy' field to 'canary' and set 'autoRollback: true' on the release.
D.Create a Cloud Deploy rollout with multiple phases and add a 'stackdriverMetrics' job to the 'postDeploy' phase.
AnswerA

This configures automatic metric-based verification and rollback in the canary phase.

Why this answer

Cloud Deploy supports 'canaryDeployment' with phases and requires a verification job that queries Stackdriver metrics. Defining a 'stackdriverMetrics' verification job in the Skaffold configuration achieves this. Option B is incorrect because the rollout strategy 'strategy' is not a top-level field; it's part of the pipeline.

Option C is incorrect because Cloud Deploy does not inherently know the metrics; a verification job must be defined. Option D is incorrect because additional phases are not needed and don't enable metric evaluation.

Practice this question →
12
MCQhard

A team uses Spinnaker on GKE for deployment. They notice that deployments are taking too long because of manual judgment gates. They want to automatically approve deployments if the canary analysis passes predefined thresholds. What Spinnaker feature should they use?

A.Automated rollback
B.Policy engine with OPA
C.Pipeline expressions
D.Automated canary analysis
AnswerD

ACA with Kayenta automates canary evaluation based on metrics thresholds.

Why this answer

Spinnaker's Automated Canary Analysis (ACA) feature allows teams to define canary analysis thresholds and automatically promote or roll back deployments based on the analysis results, eliminating the need for manual judgment gates. This directly addresses the requirement to automatically approve deployments when predefined thresholds are met, without human intervention.

Exam trap

The trap here is that candidates may confuse the Policy Engine (OPA) with automated approval logic, but OPA is for policy enforcement (e.g., 'only deploy from master branch'), not for statistical canary analysis and automated promotion.

How to eliminate wrong answers

Option A is wrong because automated rollback is a reactive mechanism that reverts a deployment after a failure is detected, not a proactive feature to automatically approve deployments based on canary analysis. Option B is wrong because the Policy Engine with OPA (Open Policy Agent) is used for enforcing governance and compliance policies (e.g., restricting which accounts can deploy), not for automating canary analysis approvals. Option C is wrong because Pipeline Expressions are used for dynamic parameterization and conditional logic within pipeline stages, but they cannot perform the statistical analysis of canary metrics required for automated approval.

Practice this question →
13
MCQhard

A CI/CD pipeline must deploy to multiple environments (dev, staging, prod) with manual approval required before prod deployment. Which Google Cloud service is best for orchestrating this?

A.Spinnaker
B.Cloud Deploy with promotion
C.Jenkins on GKE
D.Cloud Build with manual steps
AnswerB

Cloud Deploy supports manual approvals and promotion across targets.

Why this answer

Cloud Deploy provides a delivery pipeline with sequential stages and manual approval gates, making it ideal for multi-environment deployments.

Practice this question →
14
Multi-Selecthard

A team uses Cloud Build with a cloudbuild.yaml that deploys to multiple environments. They want to ensure that the production deployment step only runs when the build is triggered by a tag matching 'v*.*.*'. Which TWO configurations achieve this? (Choose two.)

Select 2 answers
A.In the cloudbuild.yaml, use a 'waitFor' condition that only runs the production step when the substitution variable $TAG_NAME matches 'v*.*.*'.
B.Create a Cloud Build trigger with a tag filter '^v[0-9]+\.[0-9]+\.[0-9]+$' and use that trigger for production deployments.
C.In the cloudbuild.yaml, add a condition that checks if the branch name matches 'v*.*.*'.
D.Create a separate cloudbuild.yaml for production and use a branch filter '^main$' to trigger it.
E.Configure a manual approval step in Cloud Build that requires a production manager to approve before running the production deployment.
AnswersA, B

Conditional step execution based on tag substitution.

Why this answer

Cloud Build supports substitution variables like $TAG_NAME, which can be used in a 'waitFor' condition or as part of a step's entrypoint logic to gate execution. By checking if $TAG_NAME matches the glob pattern 'v*.*.*', the production deployment step will only run when the build is triggered by a matching tag, ensuring environment-specific control within a single cloudbuild.yaml.

Exam trap

Google Cloud often tests the distinction between branch-based and tag-based triggers, and candidates mistakenly apply branch filters (like '^main$') or branch-name checks when the requirement explicitly specifies tag-based triggers, leading them to select options C or D.

Practice this question →
15
MCQeasy

A build step needs to access a secret stored in Secret Manager. How should the secret be passed to the build step?

A.Use an environment variable with the secret directly in cloudbuild.yaml
B.Use gcloud command inside the build step to fetch the secret
C.Use a script to fetch the secret from an encrypted file
D.Use availableSecrets in cloudbuild.yaml
AnswerD

This is the secure method to access secrets in Cloud Build.

Why this answer

Cloud Build's availableSecrets field allows you to securely access secrets from Secret Manager and inject them as environment variables or volumes.

Practice this question →
16
MCQhard

A company uses Cloud Build with a private pool in a shared VPC to access on-premises resources. Several builds fail intermittently with 'failed to connect to backend' errors when trying to pull from a private npm registry hosted on-premises. The error occurs only during peak hours. What is the most likely cause?

A.The DNS resolution for the private npm registry is failing due to caching issues.
B.The private pool has insufficient worker count or is too small, causing connectivity timeouts.
C.The private pool's service account does not have the correct SSL certificates.
D.The Cloud NAT IP addresses have been blocked by the on-premises firewall.
AnswerB

Peak hours increase concurrent builds, exhausting pool capacity.

Why this answer

The intermittent 'failed to connect to backend' errors during peak hours point to resource exhaustion in the private pool. Private pools have a fixed number of workers; when all workers are busy, new builds must wait, and if the queue or connection timeout is exceeded, the build fails. This is a classic capacity issue, not a DNS, certificate, or firewall problem.

Exam trap

Google Cloud often tests the concept that intermittent failures during peak hours are caused by resource exhaustion (e.g., insufficient workers, concurrency limits) rather than configuration issues like DNS or firewall rules, which would cause consistent failures.

How to eliminate wrong answers

Option A is wrong because DNS caching issues would cause persistent failures, not just during peak hours, and Cloud Build uses the VPC's DNS resolution which is stable. Option C is wrong because SSL certificate issues would cause TLS handshake failures, not generic 'failed to connect' errors, and the service account does not manage certificates for outbound connections. Option D is wrong because if the on-premises firewall were blocking Cloud NAT IPs, the failures would be consistent, not intermittent and tied to peak hours.

Practice this question →
17
MCQeasy

A developer wants to trigger a Cloud Build execution whenever a pull request is created against the main branch in Cloud Source Repositories. Which Cloud Build trigger configuration should be used?

A.Event: pull request on branch ^main$
B.Event: push on branch ^main$
C.Event: push on tag
D.Event: manual invocation
AnswerA

Cloud Build triggers support pull request events with branch filtering.

Why this answer

Cloud Build triggers can be configured to respond to pull request events on a specific branch using the 'pull request' event type and the branch regex `^main$`. Option B is for push events on the main branch, not pull requests. Option C is for tags, not branches.

Option D is for manual invocation, which does not automatically trigger on pull requests.

Practice this question →
18
MCQmedium

A company is implementing CI/CD for a microservices application on Google Kubernetes Engine (GKE). The team wants to ensure that each service can be built and deployed independently without affecting other services. They also need to enforce that only successfully tested builds are deployed to production. Which CI/CD approach should they use?

A.Create separate Cloud Build triggers per microservice, each building a container image, and use Cloud Deploy to manage canary deployments to GKE with automated promotion after tests pass.
B.Use Cloud Build to build all services and deploy to Cloud Run, then use traffic splitting to promote new versions.
C.Create a single Cloud Build trigger that builds all services and deploys to a staging cluster, then manually promote to production.
D.Use Spinnaker with a single pipeline that builds all services, and configure manual judgment gates for production promotion.
AnswerA

This approach provides independent builds and automated promotion based on tests.

Why this answer

It uses separate Cloud Build triggers per microservice to enable independent builds, and Cloud Deploy with canary deployments and automated promotion after tests pass ensures that only successfully tested builds reach production. This approach aligns with the requirements of independent service deployment and gated promotion to production on GKE.

Exam trap

Google Cloud often tests the distinction between independent service pipelines versus monolithic pipelines, and the trap here is assuming that a single pipeline or manual gates can satisfy both independence and automated gating, leading candidates to choose options like C or D.

How to eliminate wrong answers

Option B is wrong because it deploys to Cloud Run instead of GKE, which does not meet the requirement of using GKE for the microservices application. Option C is wrong because a single Cloud Build trigger that builds all services violates the independence requirement, and manual promotion to production does not enforce automated gating based on test success. Option D is wrong because Spinnaker with a single pipeline that builds all services also violates independence, and manual judgment gates are not automated promotion after tests pass.

Practice this question →
19
MCQeasy

An organization wants to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and deploys to production only after a manual approval. They use Cloud Build and Cloud Deploy. What is the best way to configure this?

A.Configure a Cloud Deploy delivery pipeline with a staging target (automatic promotion) and a production target (require approval).
B.Create a single Cloud Build pipeline that deploys to both staging and production using conditional steps based on branch name.
C.Use Cloud Build to deploy to Cloud Run, and configure traffic splitting to gradually shift traffic from staging to production.
D.Use Cloud Build triggers with two separate build configs: one for staging (automatic), one for production (manual trigger).
AnswerA

Cloud Deploy supports automatic promotion to staging and manual approval to production.

Why this answer

Cloud Deploy natively supports delivery pipelines with multiple targets, where you can configure automatic promotion to staging and require manual approval for production. This aligns with the requirement for a CI/CD pipeline that deploys to staging on every push to main and to production only after manual approval, using Cloud Build for the build and Cloud Deploy for the deployment orchestration.

Exam trap

Google Cloud often tests the distinction between Cloud Build (build and test) and Cloud Deploy (deployment orchestration with approval gates), so the trap here is assuming Cloud Build alone can handle manual approvals or multi-environment promotion, when Cloud Deploy is the correct service for that workflow.

How to eliminate wrong answers

Option B is wrong because it suggests using a single Cloud Build pipeline with conditional steps based on branch name, but Cloud Build is a build and test service, not a deployment orchestrator; it lacks native support for manual approval gates and promotion between environments, which is a core requirement. Option C is wrong because it describes traffic splitting on Cloud Run, which is a canary deployment strategy, not a CI/CD pipeline with separate staging and production targets requiring manual approval; Cloud Deploy is the appropriate service for such multi-target pipelines. Option D is wrong because it proposes using two separate Cloud Build triggers with manual trigger for production, but Cloud Build triggers do not provide a built-in manual approval workflow; Cloud Deploy's delivery pipeline with approval targets is the designed solution for this pattern.

Practice this question →
20
Multi-Selecthard

Which THREE are best practices for securing a CI/CD pipeline on Google Cloud?

Select 3 answers
A.Use Secret Manager to securely pass credentials to build steps.
B.Enable Binary Authorization to enforce that only signed images are deployed.
C.Run builds on the publicly hosted pool for better scalability.
D.Store service account keys in the source repository for build steps to use.
E.Use Cloud Build private pools to isolate build execution.
AnswersA, B, E

Secret Manager integrates with Cloud Build for secure access.

Why this answer

Options A, B, and E are correct. Using Secret Manager (A) securely passes credentials without hardcoding or storing them in repos. Binary Authorization (B) ensures only signed, trusted container images are deployed, preventing tampering.

Cloud Build private pools (E) provide isolated, controlled build environments, reducing exposure. Option C is incorrect because public pools may be less secure and not recommended for sensitive workloads. Option D is incorrect because storing service account keys in source repos is a security risk.

Practice this question →
21
MCQeasy

A startup is building a CI/CD pipeline for their Cloud Run service. They use Cloud Build to build a Docker image, push it to Artifact Registry, and then deploy to Cloud Run with the 'gcloud run deploy' command in the build config. The initial deployment works, but subsequent builds fail at the deploy step with a permission error: 'Permission denied to deploy revision to Cloud Run service'. The Cloud Build service account has the Cloud Run Developer role. The developers can manually deploy from their workstations using their own accounts. What is the most likely cause?

A.The developers added the '--impersonate-service-account' flag inadvertently in the build config.
B.The Cloud Run API is not enabled in the project.
C.The Cloud Build service account lacks Artifact Registry read permissions to pull the image.
D.The Cloud Build service account needs the 'iam.serviceAccounts.actAs' permission on the Cloud Run runtime service account.
AnswerD

Cloud Deploy (and gcloud run deploy) requires the caller to have actAs permission on the identity being used by the Cloud Run service.

Why this answer

Cloud Run requires the service account to have the 'iam.serviceAccounts.actAs' permission on the runtime service account used by Cloud Run (the compute engine default service account or a custom one). The Cloud Run Developer role alone does not include this. Option A is incorrect because the error is permission-related, not API enablement.

Option B is incorrect because Artifact Registry permissions are for pushing images, not deploying. Option C is incorrect because Cloud Build uses its own service account, not user credentials.

Practice this question →
22
MCQmedium

A company is using Cloud Build to build a Go application. The build fails with an error 'no Go files in /workspace'. What is the most likely cause?

A.The repository has no Go files.
B.The build step is running in the wrong directory.
C.The Go module is not properly initialized.
D.Cloud Build is unable to clone the repository.
AnswerB

The error indicates no Go files found in /workspace, confirming a directory mismatch.

Why this answer

Cloud Build copies the repository contents to /workspace. If the Go source files are in a subdirectory, the build step might be pointing to the wrong directory.

Practice this question →
23
MCQeasy

A company runs a CI/CD pipeline using Cloud Build and Cloud Deploy for a web application. The pipeline builds a container image, pushes it to Artifact Registry, and then deploys it to a GKE cluster using Cloud Deploy. Recently, the deployment step started failing with the error: 'INVALID_ARGUMENT: The release contains one or more images that are not in the target project's Artifact Registry.' The container image is built in the same project as the target cluster. The Cloud Build service account has been granted the roles/cloudbuild.builds.builder and roles/artifactregistry.admin on the project. The DevOps engineer verified that the image exists in Artifact Registry and the path is correct. What should the DevOps engineer do to resolve the issue?

A.Reconfigure Cloud Build to store images in a different Artifact Registry repository.
B.Grant the Cloud Deploy service account the roles/artifactregistry.reader role on the project.
C.Ensure that the Cloud Deploy delivery pipeline references the correct image path, including the project ID and repository.
D.Change the Cloud Build service account to include the roles/clouddeploy.jobRunner role.
AnswerC

The most common cause is a misconfigured image reference in the delivery pipeline. Correcting the path resolves the error.

Why this answer

The error 'INVALID_ARGUMENT: The release contains one or more images that are not in the target project's Artifact Registry' indicates that the Cloud Deploy delivery pipeline is referencing an image path that does not match the actual location of the image. Even though the image exists in Artifact Registry and the path appears correct, Cloud Deploy validates the image reference (including project ID, repository name, and image tag) against the target project's registry. The engineer must ensure the delivery pipeline YAML or configuration explicitly specifies the correct full image path, including the project ID and repository, so that Cloud Deploy can resolve and verify the image during release creation.

Exam trap

The trap here is that candidates assume the error is a permissions issue (leading them to grant roles to service accounts) when it is actually a configuration mismatch in the image path referenced by the Cloud Deploy delivery pipeline.

How to eliminate wrong answers

Option A is wrong because storing images in a different repository does not address the root cause—the mismatch between the image path referenced in the Cloud Deploy pipeline and the actual image location; it would only shift the problem to another repository. Option B is wrong because the Cloud Deploy service account does not need roles/artifactregistry.reader; Cloud Deploy uses the Cloud Build service account or the user's credentials to read images, and the error is about path resolution, not permissions. Option D is wrong because the roles/clouddeploy.jobRunner role is for executing deployment jobs, not for resolving image references; the issue is a configuration mismatch in the delivery pipeline, not a missing role on the Cloud Build service account.

Practice this question →
24
Matchingmedium

Match each Google Cloud deployment strategy to its description.

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

Concepts
Matches

Two identical environments; switch traffic

Gradually replace instances with new version

Route small traffic percentage to new version

Compare two versions based on user metrics

New version receives mirrored traffic without impact

Why these pairings

Blue/green uses two environments, canary uses a small user subset, rolling updates gradually. Swapping definitions is a common distractor.

Practice this question →
25
MCQeasy

A DevOps team wants to automate the deployment of a containerized application to multiple GKE clusters across different regions. They are using Cloud Build to build the container and Cloud Deploy for deployment. Which Cloud Deploy resource should they configure to define the deployment order and target clusters?

A.Cloud Build trigger with a multi-cluster deployment step.
B.A rollout object with target clusters specified.
C.A delivery pipeline with multiple targets defined.
D.A Cloud Deploy release configuration.
AnswerC

Delivery pipeline specifies targets and promotion order.

Why this answer

A delivery pipeline in Cloud Deploy defines the deployment order and target clusters, allowing you to specify a sequence of targets (e.g., dev, staging, prod) across different GKE clusters. Option A is incorrect because a Cloud Build trigger initiates builds but does not define deployment order or targets. Option B is incorrect because a rollout object targets a single target, not multiple.

Option D is incorrect because a release configuration represents a specific version of an application, not the deployment pipeline.

Practice this question →
26
MCQeasy

A team is using Cloud Build to build a Docker image and push to Artifact Registry. After each build, they want to automatically trigger a deployment to Cloud Run. What is the best way to achieve this?

A.Use Cloud Build builder to deploy to Cloud Run in the same pipeline.
B.Use Cloud Deploy to manage the rollout.
C.Configure a Cloud Run trigger on Artifact Registry push.
D.Use Cloud Scheduler to periodically check for new images and deploy.
AnswerC

Cloud Run triggers can automatically deploy new images pushed to Artifact Registry.

Why this answer

Cloud Run natively supports continuous deployment from Artifact Registry: when a new image is pushed to the registry, Cloud Run can automatically deploy the latest image without requiring an external pipeline or scheduler. This is the simplest and most direct approach, as it eliminates the need for additional CI/CD orchestration while ensuring deployments happen immediately after each successful build.

Exam trap

The trap here is that candidates often over-engineer the solution by choosing Cloud Deploy (Option B) because it is a dedicated deployment tool, but the question specifically asks for the 'best way' to trigger a deployment after a single build, where Cloud Run's built-in continuous deployment is simpler and more direct.

How to eliminate wrong answers

Option A is wrong because using a Cloud Build builder to deploy to Cloud Run in the same pipeline couples the build and deployment steps, which violates the principle of separation of concerns and makes it harder to manage rollbacks or approvals; it also requires the Cloud Build service account to have deployment permissions, increasing security risk. Option B is wrong because Cloud Deploy is designed for multi-target, progressive delivery (e.g., canary, blue/green) and adds unnecessary complexity for a simple single-service deployment triggered by a single image push. Option D is wrong because Cloud Scheduler polling for new images introduces latency (up to the polling interval) and inefficiency, and it is not event-driven; it also requires custom logic to compare image digests, making it brittle and harder to maintain.

Practice this question →
27
MCQmedium

A company uses Cloud Source Repositories and wants automatic builds on pull requests to the main branch. Which Cloud Build trigger type should they configure?

A.Pull request (comment)
B.Push to a branch
C.Pull request (any)
D.Tag push
AnswerC

This trigger runs builds for all pull request events.

Why this answer

A pull request trigger in Cloud Build allows you to run builds automatically when a pull request is opened, synchronized, or updated.

Practice this question →
28
MCQmedium

A company has a monorepo with multiple microservices. They want to only build and deploy the service that changed. What CI/CD practice should they implement?

A.Use a multi-branch pipeline where each branch represents a service.
B.Use git diff to conditionally run steps for changed services.
C.Use Cloud Build triggers with inline substitution for each service.
D.Use separate repositories for each service.
AnswerB

Cloud Build steps can be guarded with bash commands checking git diff output.

Why this answer

Using git diff to detect changes in specific paths allows conditional build steps in Cloud Build, triggering only the affected service.

Practice this question →
29
MCQmedium

A team uses Cloud Build with a Kaniko builder to containerize their application. The build fails with the error: 'failed to push to destination: failed to get credentials: failed to get credential from metadata service: failed to fetch metadata...' What is the most likely cause?

A.Kaniko requires a running Docker daemon in the build step.
B.The base image specified in the Dockerfile is not accessible from the build environment.
C.The Dockerfile has an invalid instruction causing Kaniko to fail.
D.The Cloud Build service account does not have the storage.objectAdmin role on the Container Registry bucket.
AnswerD

Missing push permissions cause credential failures.

Why this answer

The error indicates that Kaniko cannot authenticate to push the built image to Container Registry. Kaniko uses the Cloud Build service account's credentials to authenticate with the registry. By default, the Cloud Build service account has the storage.objectViewer role on the Container Registry bucket, which allows pulling images but not pushing.

To push, the service account needs the storage.objectAdmin or storage.objectCreator role on the bucket. Option D correctly identifies this missing permission as the most likely cause.

Exam trap

Google Cloud often tests the misconception that Kaniko requires a Docker daemon (Option A), but the real issue is almost always a missing IAM permission on the target registry bucket.

How to eliminate wrong answers

Option A is wrong because Kaniko is specifically designed to build container images without requiring a Docker daemon; it runs entirely in userspace. Option B is wrong because the error message is about pushing credentials, not about pulling a base image; an inaccessible base image would produce a 'failed to pull' or 'image not found' error. Option C is wrong because an invalid Dockerfile instruction would cause a build-time syntax or execution error, not a credential failure during the push phase.

Practice this question →
30
Multi-Selectmedium

A company uses Cloud Deploy to manage rollouts to GKE. They need to implement a deployment strategy where a new version receives 10% of traffic for 30 minutes, then automatically rolls forward to 100% if no issues are detected. Which THREE Cloud Deploy features are required? (Choose three.)

Select 3 answers
A.A canary deployment strategy with a 10% phase.
B.An automated promotion policy that promotes after the wait phase.
C.A manual approval gate before the 100% phase.
D.An Istio VirtualService configuration for traffic splitting.
E.A 30-minute wait phase in the canary strategy.
AnswersA, B, E

Canary enables traffic splitting.

Why this answer

A canary deployment strategy in Cloud Deploy allows you to define phases that gradually shift traffic to a new revision. A 10% phase is the first step in this strategy, ensuring only a small subset of users experience the new version initially, which aligns with the requirement to start with 10% traffic.

Exam trap

Google Cloud often tests the distinction between required Cloud Deploy features and optional external tools like Istio, leading candidates to mistakenly include Istio-specific configurations when Cloud Deploy's native traffic management suffices.

Practice this question →
31
Multi-Selectmedium

Which TWO deployment strategies are directly supported by Cloud Deploy for GKE?

Select 2 answers
A.Rolling update
B.A/B testing
C.Canary
D.Shadow
E.Blue-green
AnswersC, E

Cloud Deploy supports canary with incremental traffic shifting.

Why this answer

Options C and E are correct. Cloud Deploy for GKE directly supports canary (C) and blue-green (E) deployment strategies. Option A (Rolling update) is incorrect because rolling updates are managed natively by GKE itself, not as a Cloud Deploy strategy.

Option B (A/B testing) is incorrect; A/B testing is a traffic management technique but not a built-in deployment strategy in Cloud Deploy. Option D (Shadow) is incorrect; shadow deployments are not supported by Cloud Deploy.

Practice this question →
32
Multi-Selectmedium

Which TWO practices are recommended for implementing CI/CD pipelines on Google Cloud?

Select 2 answers
A.Store service account keys in the build configuration file for authentication.
B.Deploy to production directly after a successful build without any approval gate.
C.Create a single build pipeline that handles all microservices to reduce complexity.
D.Use a Dockerfile to define the build process for containerized applications.
E.Use Cloud Build substitutions to parameterize build configurations for different environments.
AnswersD, E

Dockerfile is the standard way to define container builds.

Why this answer

Using a Dockerfile to define the build process for containerized applications is a recommended practice in CI/CD pipelines on Google Cloud. It ensures that the application is built consistently across all environments, leveraging Cloud Build's native support for Dockerfiles to produce container images that can be stored in Container Registry or Artifact Registry.

Exam trap

Google Cloud often tests the misconception that a single monolithic pipeline is simpler and thus better, but the correct approach is to decouple microservices into separate pipelines for isolation and independent release cycles.

Practice this question →
33
MCQhard

A team wants to ensure zero-downtime deployments for a Cloud Run service. They plan to gradually shift traffic from the current revision to the new one. What should they configure?

A.Use Cloud Build to directly replace the revision
B.Set traffic to 100% on the new revision gradually using multiple updates
C.Configure a rolling update strategy in Cloud Deploy
D.Use Cloud Run's traffic splitting feature to slowly increase traffic to the new revision
AnswerD

Cloud Run allows you to assign traffic percentages to revisions, enabling gradual rollouts.

Why this answer

Cloud Run supports traffic splitting, allowing you to gradually send a percentage of traffic to the new revision to monitor health before fully switching.

Practice this question →
34
MCQmedium

A development team is using Cloud Build to build and push Docker images to Artifact Registry. The builds are taking longer than expected, and the team wants to reduce build time and cost. They use a Dockerfile that installs many dependencies. Which approach should they recommend?

A.Increase the machine type to use more vCPUs and memory for the build.
B.Use Kaniko cache in Cloud Build with a persistent volume claim to cache base layers.
C.Switch to Docker build with --privileged flag and use a local Docker daemon.
D.Reduce the number of steps in the Cloud Build config to a single step that installs and builds everything.
AnswerB

Kaniko's cache stores intermediate layers in a persistent volume, dramatically reducing build time for unchanged dependencies.

Why this answer

Using Kaniko with a persistent volume claim allows caching of base layers across builds, significantly reducing build time by reusing previously downloaded layers. Option A increases cost by using more resources without addressing caching inefficiency. Option C uses Docker with privileged mode, which is slower and less secure than Kaniko.

Option D reduces parallelism by consolidating steps, which can increase build time rather than reduce it.

Practice this question →
35
MCQmedium

A DevOps engineer is setting up a CI/CD pipeline for a Python application using Cloud Build. The build takes too long because pip install is downloading packages every time. What is the best approach to speed up the build?

A.Use a custom base image that includes all dependencies pre-installed.
B.Increase the machine type to a higher CPU and memory instance.
C.Use Kaniko cache in Cloud Build with a remote cache location.
D.Configure a volume mount to a Cloud Storage bucket for pip cache and set PIP_CACHE_DIR.
AnswerD

Caching pip downloads across builds is the most direct optimization.

Why this answer

Configuring a volume mount to a Cloud Storage bucket for pip cache and setting PIP_CACHE_DIR allows packages to be cached across builds, significantly reducing download time. Option A is incorrect: custom base images require maintenance and may not cover all dependencies. Option B is incorrect: increasing machine type does not address the network-bound pip download bottleneck.

Option C is incorrect: Kaniko cache is for Docker image layer caching, not for pip package caching.

Practice this question →
36
MCQmedium

Refer to the exhibit. A team uses this cloudbuild.yaml to deploy a service to Cloud Run. They notice that the deployment fails intermittently with a 'permission denied' error. Which is the most likely cause?

A.The image tag $SHORT_SHA is invalid because it contains a variable
B.The Cloud Build service account does not have the `roles/run.admin` or `roles/run.developer` role
C.The region in the gcloud run deploy command does not match the region where Cloud Run is enabled
D.The Cloud Build service account does not have permission to push images to Artifact Registry
AnswerB

These roles grant permission to deploy Cloud Run services.

Why this answer

The Cloud Build service account (default or custom) must have the `roles/run.admin` or `roles/run.developer` IAM role to execute `gcloud run deploy`. Without these roles, the deployment fails with a 'permission denied' error because the service account lacks the `run.services.create` and `run.services.update` permissions required to deploy or update a Cloud Run service. The intermittent nature suggests the service account may have been granted the role after some failures, or the error only surfaces when the service account's cached credentials expire.

Exam trap

Google Cloud often tests the distinction between permissions needed for different stages of a CI/CD pipeline; the trap here is that candidates assume the error is about image pushing (Artifact Registry) rather than the deployment step (Cloud Run), because both involve 'permission denied' but at different phases.

How to eliminate wrong answers

Option A is wrong because `$SHORT_SHA` is a valid Cloud Build substitution variable that resolves to the short commit SHA; it does not cause a 'permission denied' error. Option C is wrong because if the region in the `gcloud run deploy` command does not match where Cloud Run is enabled, the error would be a region mismatch or 'not found', not a 'permission denied' error. Option D is wrong because the Cloud Build service account typically has the `roles/artifactregistry.writer` role by default in many setups, and even if it lacked push permission, the error would occur during the `docker push` step, not during the `gcloud run deploy` step.

Practice this question →
37
MCQmedium

During a Cloud Build execution, the step fails with 'Error: could not find a valid 'Dockerfile' in context '.''. The build configuration file is located in a subdirectory called 'build/' and the Dockerfile is in the root of the repository. How should the team fix this?

A.Create a symbolic link.
B.Move the Cloud Build configuration file to the root.
C.Specify the 'dir' field in the build step to point to the root.
D.Use the 'substitutions' to change context.
AnswerC

Setting 'dir: '.' or 'dir: '/' will make Docker use the root context.

Why this answer

The Cloud Build step's `dir` field explicitly sets the working directory for the step. By specifying `dir: '.'` (or the repository root), Cloud Build will look for the Dockerfile in the root context, even though the build configuration file (`cloudbuild.yaml`) resides in the `build/` subdirectory. This ensures the Docker build context points to the correct location where the Dockerfile exists.

Exam trap

Google Cloud often tests the misconception that the build configuration file's location dictates the Docker build context, leading candidates to incorrectly choose moving the config file or using substitutions, when the `dir` field is the correct and intended mechanism to control the working directory for a step.

How to eliminate wrong answers

Option A is wrong because creating a symbolic link is an unnecessary workaround that adds complexity and fragility; Cloud Build does not require or recommend symlinks for context resolution. Option B is wrong because moving the Cloud Build configuration file to the root is not required and would break the intended project structure; the `dir` field exists precisely to decouple the config file location from the build context. Option D is wrong because substitutions in Cloud Build are used for variable replacement (e.g., `$_TAG`), not for changing the build context or working directory of a step.

Practice this question →
38
Multi-Selectmedium

A DevOps team wants to implement a CI/CD pipeline for a microservices application deployed on Google Kubernetes Engine (GKE). They need to ensure that each service is built, tested, and deployed independently with minimal manual intervention. Which TWO practices should they implement?

Select 2 answers
A.Use Cloud Deploy to manage progressive delivery (e.g., canary, blue/green) to GKE clusters.
B.Use Cloud Source Repositories integrated with Cloud Build for version control and triggering builds.
C.Use a monolithic repository and deploy all services simultaneously to ensure consistency.
D.Use Cloud Build triggers to build and test each service independently on pull request.
E.Use a single Cloud Build configuration file for all services with conditional steps to handle different services.
AnswersA, D

Cloud Deploy provides deployment strategies that reduce risk and allow independent releases.

Why this answer

Uses Cloud Deploy to manage progressive delivery (canary, blue/green) to GKE, enabling safe and gradual rollouts. Option D uses Cloud Build triggers to build and test each service independently on pull request, ensuring isolation and minimal manual intervention. Option B is not correct because Cloud Source Repositories is just a source control repository; it does not directly enable CI/CD independence.

Option C is wrong because a monolithic repository with simultaneous deployment contradicts microservices independence. Option E is not best practice as a single config file with conditional steps becomes complex and hard to maintain.

Practice this question →
39
Multi-Selecteasy

Which THREE of the following are best practices for securing a CI/CD pipeline using Cloud Build? (Choose 3.)

Select 3 answers
A.Configure Cloud Build triggers to run only from protected branches (e.g., main, release).
B.Store secrets and credentials in Secret Manager and access them via the 'availableSecrets' field.
C.Grant the Cloud Build service account the Storage Admin role for the project to allow pushing images.
D.Enable Container Analysis on the Artifact Registry repository to automatically scan images for vulnerabilities after build.
E.Disable build cache to ensure fresh builds and avoid using potentially compromised cached layers.
AnswersA, B, D

This prevents injection of malicious code from feature branches.

Why this answer

Restricting Cloud Build triggers to protected branches (e.g., main, release) prevents unauthorized or untested code changes from initiating builds, which is a fundamental security control for CI/CD pipelines. This ensures that only code that has passed review and is merged into stable branches can trigger automated builds, reducing the risk of malicious or erroneous code being deployed.

Exam trap

Google Cloud often tests the principle of least privilege by including overly broad IAM roles (like Storage Admin) as distractors, and candidates may mistakenly think granting full access is acceptable for simplicity, when in fact specific roles like Artifact Registry Writer or Cloud Build Service Account should be used.

Practice this question →
40
Multi-Selecteasy

Which TWO are benefits of using Cloud Build triggers to implement CI/CD pipelines?

Select 2 answers
A.Start a build automatically when changes are pushed to a repository
B.Deploy to a specific Google Cloud region based on the trigger
C.Support only a single branch per trigger
D.Integrate with Cloud Source Repositories, GitHub, and Bitbucket
E.Automatically provision infrastructure as part of the build
AnswersA, D

Triggers automate builds on source code changes.

Why this answer

Cloud Build triggers can be configured to automatically start a build in response to events such as a push to a repository branch or the creation of a pull request. This event-driven automation is the foundation of a CI/CD pipeline, eliminating the need for manual build initiation and ensuring that every code change is validated immediately.

Exam trap

Google Cloud often tests the misconception that triggers can directly control deployment regions or infrastructure provisioning, when in fact triggers only respond to events and start builds, with all deployment logic residing in the build configuration file.

Practice this question →
41
MCQhard

You are a DevOps engineer for a large e-commerce platform running on Google Kubernetes Engine (GKE). The platform consists of 15 microservices, each with its own code repository. Your team uses Cloud Build for CI and Cloud Deploy for CD. Recently, the deployment to production has been failing intermittently because the new version of the 'payment' service is not compatible with the current version of the 'order' service. This causes a production outage every few weeks. The team wants to implement a strategy to catch such incompatibilities before promoting to production, without slowing down development velocity. Currently, the pipeline builds each service independently, runs unit tests, deploys to a shared staging environment, runs integration tests, and then promotes to production after manual approval. What should you do?

A.Define strict version compatibility matrices between services and enforce them in the pipeline by locking versions.
B.Implement canary deployments in staging: deploy the new payment service alongside the current version, route a percentage of test traffic to the new version, and run integration tests before promoting. If tests pass, promote to production.
C.Add a manual testing phase after staging deployment where QA engineers manually test the integration before production promotion.
D.Combine all microservice builds into a single pipeline that builds and tests all services together before deploying to staging.
AnswerB

Canary deployments in staging catch incompatibilities early without slowing development.

Why this answer

It introduces canary deployments in the staging environment, allowing the new payment service to be tested with a subset of realistic traffic alongside the current order service. This catches incompatibilities early by running integration tests against the canary, without blocking the pipeline or slowing development velocity. Cloud Deploy supports canary deployment strategies natively, making this a practical and automated solution.

Exam trap

The trap here is that candidates may choose option A (version locking) because it seems like a straightforward dependency management solution, but it ignores the need for dynamic testing under realistic traffic patterns and the requirement to maintain development velocity.

How to eliminate wrong answers

Option A is wrong because locking versions with strict compatibility matrices reduces flexibility and slows development velocity, contradicting the requirement to avoid slowing down the team. Option C is wrong because adding a manual QA testing phase introduces human delay and does not scale, failing to maintain development velocity. Option D is wrong because combining all 15 microservices into a single pipeline creates a monolithic build that increases build times, reduces parallelism, and violates the principle of independent service deployment, which is a core tenet of microservices architecture.

Practice this question →
42
MCQmedium

A team is using Cloud Build to build and deploy to multiple environments (dev, staging, prod) using Cloud Deploy. They want to ensure that only builds from the main branch are promoted to prod. How should they configure this?

A.Use Cloud Build tags to mark builds from the main branch and filter in Cloud Deploy.
B.Set IAM policies on the Container Registry or Artifact Registry to restrict access to the prod image.
C.Set the Cloud Build trigger to only run on the main branch.
D.Configure a Cloud Deploy promotion with an approval gate required for the prod target.
AnswerD

Approval gating prevents automatic promotion to prod.

Why this answer

Cloud Deploy's approval gate feature allows you to require manual approval before a release is promoted to a specific target, such as prod. By configuring an approval gate on the prod target, you ensure that only builds from the main branch (which can be verified via the release metadata or source) are manually approved for promotion, providing a controlled, auditable gate. This approach directly enforces the branch-based promotion policy without relying on build-time filtering or IAM restrictions.

Exam trap

Google Cloud often tests the misconception that a Cloud Build trigger restriction alone is sufficient to control promotions, but the trigger only controls build creation, not the subsequent deployment promotion, which requires a separate gate like an approval gate in Cloud Deploy.

How to eliminate wrong answers

Option A is wrong because Cloud Build tags are metadata attached to builds, but Cloud Deploy does not have a native filter to promote releases based on tags; tags are not propagated or evaluated during promotion. Option B is wrong because IAM policies on Container Registry or Artifact Registry control who can pull or push images, not which builds are promoted to prod; they cannot enforce a branch-based promotion policy. Option C is wrong because setting the Cloud Build trigger to only run on the main branch ensures that only main branch builds are created, but it does not prevent a release from that build from being promoted to prod; the trigger alone does not gate the promotion step.

Practice this question →
43
MCQeasy

A development team wants to automatically run unit tests and static code analysis on every push to a Cloud Source Repository, but only run integration tests on merges to the main branch. Which Cloud Build trigger configuration should they use?

A.Use a single trigger with a substitution variable like '_BRANCH' and set it to 'main' for integration tests.
B.Create one trigger with a build config that uses the 'branchName' substitution to conditionally skip integration test steps.
C.Create two triggers: one with a branch filter for '^main$' that runs integration tests, and another with a branch filter for '^.*$' that runs unit tests.
D.Configure one trigger with no branch filter and rely on developers to manually trigger integration tests.
AnswerC

Correct: separate triggers with branch filters allow different pipelines per branch.

Why this answer

Cloud Build triggers allow you to define separate triggers with branch filters to execute different build configurations based on the branch. By creating one trigger with a branch filter of '^main$' for integration tests and another with '^.*$' for unit tests, you ensure unit tests run on every push to any branch, while integration tests run only on merges to main. This approach directly maps the desired behavior without requiring conditional logic or manual intervention.

Exam trap

The trap here is that candidates mistakenly think a single trigger with conditional steps or substitution variables can handle branch-specific logic, but Cloud Build triggers are designed to be event-filtered at the trigger level, not at the build step level.

How to eliminate wrong answers

Option A is wrong because a single trigger with a substitution variable like '_BRANCH' cannot conditionally skip steps based on the branch at trigger time; substitution variables are resolved at build time and do not control trigger execution. Option B is wrong because the 'branchName' substitution is not a valid Cloud Build trigger property for conditional step skipping; Cloud Build triggers use branch filters to determine which events fire the trigger, not to conditionally execute steps within a single build config. Option D is wrong because relying on developers to manually trigger integration tests defeats the purpose of automation and introduces human error, violating CI/CD best practices.

Practice this question →
44
MCQhard

A company is migrating from Jenkins to Cloud Build for their CI/CD pipeline. They have a large Java monorepo with multiple modules that take over 2 hours to build and test sequentially. They want to reduce build time by running module builds in parallel. The current Jenkins pipeline uses a single Jenkinsfile that builds all modules. They have a Cloud Build config that runs 'mvn clean package' for the entire project, which is slow. They have a 2-hour Cloud Build timeout. The architecture requires that some modules depend on others. Which approach should they take to minimize build time while correctly handling dependencies?

A.Break the monolith into separate Cloud Build triggers per module and run them independently on every push.
B.Create a single build config that defines parallel steps for independent modules, using 'waitFor' to sequence dependent modules, and uses Maven's incremental compilation with caching.
C.Use a build step that runs 'mvn -pl moduleA,moduleB -am' to build only changed modules and their dependencies.
D.Increase the Cloud Build timeout to 4 hours and keep a single build step.
AnswerB

This models the dependency graph and runs independent modules in parallel, plus caching speeds up subsequent builds.

Why this answer

Using Cloud Build's parallel steps with 'waitFor' allows independent modules to build concurrently while respecting dependencies, significantly reducing build time. Option A is incorrect because running each module independently without handling dependencies would cause dependent modules to fail or build with outdated artifacts. Option C is incorrect because 'mvn -pl' with '-am' still runs sequentially on a single build machine and doesn't leverage Cloud Build's parallelism.

Option D is incorrect because increasing the timeout does not address the sequential build issue; the long build time is due to lack of parallelism, not timeout.

Practice this question →
45
MCQmedium

A multinational corporation has multiple development teams working on microservices deployed to GKE clusters. They want to implement a CI/CD pipeline that ensures every container image is scanned for vulnerabilities, passes unit tests, and gets a security approval before deployment to production. They are using Cloud Build for CI and Cloud Deploy for CD. The current pipeline triggers on code push to any branch. The security team requires that all production deployments be reviewed and approved by the security team. Which set of actions best meets these requirements?

A.Run all tests and scans in a single Cloud Build step and use Cloud Build's built-in approval feature to require a reviewer before pushing to Artifact Registry.
B.Run vulnerability scans in the Cloud Build step before building the image, and add a security team member to the project as an editor to approve deployments.
C.Configure Cloud Build triggers only for the main branch. Use Cloud Build to build and push images, then rely on Artifact Registry's automatic Container Analysis scanning. In Cloud Deploy, add a manual approval gate for the production phase.
D.Use Cloud Build to run tests and scans, then have Cloud Build send a notification to a Cloud Pub/Sub topic that triggers a Cloud Function to approve the deployment.
AnswerC

This meets all requirements: scanning, tests in Cloud Build, and approval in Cloud Deploy.

Why this answer

Configuring Cloud Build triggers only for the main branch reduces unnecessary builds; using Cloud Build to build and push images, then relying on Artifact Registry's automatic Container Analysis scanning, ensures vulnerability scanning occurs after image push. Cloud Deploy's manual approval gate for the production phase satisfies the security team's requirement for review and approval before deployment. Option A is incorrect because Cloud Build's built-in approval feature applies to the build process, not to deployments, and it doesn't integrate with Container Analysis; plus, running all steps in a single step is inefficient.

Option B is incorrect because granting editor role to a security team member is not a proper approval mechanism; it would give too many permissions and doesn't enforce a review process. Option D is incorrect because using a Cloud Function triggered by Pub/Sub for approval bypasses proper deployment pipelines and lacks the structured approval workflow provided by Cloud Deploy.

Practice this question →
46
Multi-Selectmedium

Which TWO are benefits of using Cloud Build private pools?

Select 2 answers
A.Lower cost
B.Dedicated VMs for builds
C.Custom machine types
D.No internet access
E.Faster builds compared to public pools
AnswersB, C

Private pools use VMs not shared with other projects.

Why this answer

Cloud Build private pools provide dedicated VMs that are not shared with other Google Cloud projects. This isolation ensures consistent performance and eliminates the 'noisy neighbor' effect that can occur in public pools, where build resources are shared across multiple tenants.

Exam trap

Google Cloud often tests the misconception that private pools are always faster or cheaper than public pools, but the real benefits are isolation, custom machine types, and network control, not performance or cost.

Practice this question →
47
MCQhard

Your team manages a CI/CD pipeline for a microservices application deployed on Google Kubernetes Engine (GKE). The pipeline uses Cloud Build to build container images and push them to Artifact Registry, then uses a Cloud Build step with kubectl to apply Kubernetes manifests stored in a separate 'manifests' repository. Recently, the team has experienced issues: sometimes a new image is deployed to production even though the corresponding pull request (PR) has not been merged into the main branch of the manifests repository. Also, rollbacks are slow because the previous image tag is overwritten. The team wants to ensure that only code that passes all tests and is merged to main is deployed, and that each deployment uses a unique immutable image tag. What should the team do?

A.Keep the current architecture but modify Cloud Build triggers to only run on the main branch of both repositories. Use the short SHA ($SHORT_SHA) as the image tag.
B.Consolidate application code and Kubernetes manifests into a single repository. Configure Cloud Build triggers to build and run tests on all branches, but only deploy to GKE when changes are merged to the main branch. Use the full commit SHA as the image tag.
C.Move all source code and manifests into a single repository. Use Cloud Build triggers to build and test on every push, and deploy only on pushes to the main branch. Use the commit SHA ($COMMIT_SHA) as the image tag.
D.Keep application and manifests in separate repositories. Use Cloud Build triggers to build on changes to the app repo, and use a separate trigger on the manifests repo to deploy. Use the 'latest' tag for the image.
AnswerB

This ensures that only merged code triggers deployments, and the full commit SHA provides an immutable unique tag for easy rollback.

Why this answer

Consolidating the application code and Kubernetes manifests into a single repository ensures that the image tag (full commit SHA) is uniquely tied to the exact code and manifest changes that passed all tests. By configuring Cloud Build triggers to deploy only on merges to the main branch, the team guarantees that only fully tested, merged code reaches production. Using the full commit SHA as the image tag provides immutability and enables fast, precise rollbacks by referencing the exact image from Artifact Registry.

Exam trap

Google Cloud often tests the misconception that separate repositories with branch-based triggers are sufficient for deployment integrity, when in reality the atomicity of code and manifest changes in a single repository is required to prevent untested code from reaching production.

How to eliminate wrong answers

Option A is wrong because keeping separate repositories with triggers on the main branch of both does not solve the root cause: a PR merged into the manifests repo could reference an image tag (short SHA) that was built from unmerged app code, leading to deployment of untested code. Option C is wrong because deploying on every push to main (rather than only on merges) could still deploy code that hasn't passed all tests if the trigger is misconfigured or if tests are run in parallel; also, using $COMMIT_SHA is correct but the trigger condition is insufficiently strict. Option D is wrong because using the 'latest' tag violates immutability and makes rollbacks impossible, and separate repositories with separate triggers do not enforce the atomicity of code and manifest changes, allowing mismatched deployments.

Practice this question →
48
MCQmedium

A team uses Cloud Build with a trigger on Cloud Source Repository. The build fails intermittently with error 'Failed to pull builder image 'gcr.io/cloud-builders/gcloud'' but sometimes succeeds. What is the most likely cause?

A.The Cloud Build worker pool is in a different region.
B.The builder image is too large.
C.Network egress from Cloud Build is throttled due to high concurrency.
D.The build service account lacks permissions to access Container Registry.
AnswerC

When many builds run concurrently, Cloud Build may throttle egress, causing timeouts pulling images. Reducing concurrency or using a private pool can resolve this.

Why this answer

The intermittent failure to pull the builder image 'gcr.io/cloud-builders/gcloud' indicates a transient network issue rather than a permanent misconfiguration. Cloud Build uses a shared pool of network resources, and under high concurrency, egress traffic to Container Registry can be throttled, causing pull operations to time out or fail. This explains why the build sometimes succeeds and sometimes fails, as throttling depends on the current load.

Exam trap

Google Cloud often tests the distinction between consistent misconfiguration errors (e.g., permissions, region) and transient network throttling issues, where the 'intermittent' keyword is the critical hint to choose throttling over permanent configuration problems.

How to eliminate wrong answers

Option A is wrong because Cloud Build worker pools are regional resources, but the region does not affect the ability to pull a public image from gcr.io; the error is intermittent, not a permanent region mismatch. Option B is wrong because the size of the builder image is not the cause of intermittent failures; if the image were too large, it would consistently fail or time out, not succeed sometimes. Option D is wrong because if the build service account lacked permissions to access Container Registry, the failure would be consistent (e.g., a 403 Forbidden error), not intermittent.

Practice this question →
49
MCQmedium

Refer to the exhibit. The build fails with error: 'invalid tag format' for the image. What is the issue?

A.The project ID substitution is not present.
B.The substitution $SHORT_SHA is not defined and the tag becomes empty.
C.The build step must explicitly push the image.
D.The image name must include a tag.
AnswerB

If $SHORT_SHA is empty, the tag becomes 'myimage:', which is invalid. Substitutions must be defined when running the build.

Why this answer

The substitution $SHORT_SHA is not defined in the build configuration or in the substitution variables, so it resolves to an empty string, resulting in an invalid tag format. Option A is incorrect because the issue is not the absence of project ID substitution; the tag itself becomes empty due to undefined $SHORT_SHA. Option C is incorrect because the `images` field in the cloudbuild.yaml automatically pushes the image; no explicit push step is required.

Option D is incorrect because a tag is provided in the form of `:$SHORT_SHA`, but since the substitution is empty, the tag becomes empty.

Practice this question →
50
MCQhard

An organization uses Cloud Deploy with Skaffold to manage progressive delivery on GKE. After a rollout, the new revision shows a higher error rate in Stackdriver, but the Cloud Deploy pipeline did not automatically roll back. What is the most likely cause?

A.The rollout strategy includes a manual approval step before advancing to the next phase.
B.The release was created with a '--disable-rollback' flag.
C.The Cloud Deploy pipeline does not have a stackdriverMetrics verification job defined to check error rates.
D.The rollout has not yet reached 100% traffic, so Cloud Deploy waits for full completion before evaluating health.
AnswerC

Correct. Without a stackdriverMetrics verification job, Cloud Deploy cannot monitor error rates and trigger automatic rollback.

Why this answer

Cloud Deploy relies on verification jobs to evaluate metrics like error rate from Stackdriver. Without a stackdriverMetrics verification job configured in the delivery pipeline, Cloud Deploy has no mechanism to assess the error rate and trigger an automatic rollback. Option A is incorrect because manual approval steps only gate progression between phases; they do not affect automatic rollback decisions within a phase.

Option B is incorrect because the '--disable-rollback' flag would prevent rollbacks entirely, but the question describes a scenario where automatic rollback is expected but did not happen; the most likely cause is the absence of the required verification job. Option D is incorrect because Cloud Deploy can evaluate metrics during the rollout, not only after full traffic shift.

Practice this question →
51
MCQhard

A DevOps team is troubleshooting a Cloud Build pipeline that fails intermittently when building a container image. The build step uses a custom build step that runs a vulnerability scan. The error log shows: 'Step #1: Error: failed to scan image: context deadline exceeded'. The build configuration includes 'timeout: 600s'. Which is the most likely cause and solution?

A.The scan tool requires a specific dependency; add an installation step before scanning.
B.There is network latency between Cloud Build and the container registry; use VPC Service Controls.
C.The build step is running out of memory; increase the machine type to e2-highcpu-8.
D.The scan step is taking longer than the build timeout; increase the timeout value in the build configuration.
AnswerD

The error 'context deadline exceeded' indicates the step timed out.

Why this answer

The error 'context deadline exceeded' indicates that the custom vulnerability scan step is taking longer than the build's configured timeout of 600 seconds. Cloud Build enforces a hard timeout for the entire build; if any step exceeds this duration, the build is terminated. Increasing the timeout value in the build configuration provides more time for the scan to complete, directly addressing the root cause.

Exam trap

Google Cloud often tests the distinction between resource exhaustion (memory/CPU) and timeout errors, leading candidates to mistakenly select machine type upgrades when the error message explicitly indicates a deadline exceeded.

How to eliminate wrong answers

Option A is wrong because the error is a timeout, not a missing dependency; a missing dependency would produce a 'command not found' or similar error. Option B is wrong because network latency would typically cause connection timeouts or retries, not a 'context deadline exceeded' from the scan tool itself; VPC Service Controls address data exfiltration risks, not latency. Option C is wrong because an out-of-memory error would manifest as an OOM kill or exit code 137, not a 'context deadline exceeded' message.

Practice this question →
52
MCQhard

A financial services firm is implementing a CI/CD pipeline with Cloud Build and Artifact Registry. Their security policy requires all data to remain within a VPC Service Controls perimeter. They have configured Cloud Build to use a private worker pool with no external IP addresses and have set up VPC-SC to allow traffic between Cloud Build and Artifact Registry within the perimeter. However, builds that push Docker images to Artifact Registry fail with the error: 'denied: Unauthenticated request. Push access to the repository is denied.' The build configuration includes the step: 'steps: - name: gcr.io/cloud-builders/docker args: [push, us-central1-docker.pkg.dev/myproject/my-repo/myimage]' The Cloud Build service account has been granted roles/artifactregistry.writer on the repository. What is the most likely cause?

A.The Cloud Build service account does not have permissions to authenticate to Artifact Registry when using a private pool.
B.The VPC-SC perimeter does not allow egress to the Artifact Registry API endpoint.
C.The Docker push is failing because the image tag is missing a version.
D.The Artifact Registry repository is in a different region than the Cloud Build worker pool.
AnswerB

VPC-SC can restrict access to APIs; the Artifact Registry endpoint must be explicitly allowed in the perimeter.

Why this answer

VPC Service Controls can block access to Artifact Registry API endpoints if they are not explicitly allowed within the perimeter, resulting in an 'Unauthenticated request' error despite correct IAM permissions. Option A is incorrect because the service account permissions are sufficient; the issue is network-level access. Option C is incorrect because missing a version tag would not cause an authentication error.

Option D is incorrect because private worker pools and Artifact Registry can be in different regions.

Practice this question →
53
Multi-Selecthard

A DevOps team uses Cloud Build and Cloud Deploy to deploy to GKE. They want to implement a gated deployment where a manual approval is required before promoting from staging to production. What two resources should they configure? (Select TWO)

Select 2 answers
A.A Cloud Pub/Sub topic to notify approvers
B.A Cloud Deploy rollout with a pre-deploy hook
C.A Cloud Deploy approval rule in the delivery pipeline
D.A Cloud Deploy target with a requireApproval attribute set to true
E.A Cloud Build trigger with a manual approval step
AnswersC, D

Approval rules define stages where manual approval is needed.

Why this answer

A Cloud Deploy approval rule in the delivery pipeline defines a manual gate that pauses the pipeline at a specific stage (e.g., before promoting to production) and requires explicit approval to proceed. Option D is correct because setting the `requireApproval` attribute to `true` on a Cloud Deploy target enforces that any rollout targeting that environment must receive manual approval before the deployment proceeds.

Exam trap

Google Cloud often tests the distinction between Cloud Deploy's native approval mechanism (approval rules and `requireApproval` on targets) and Cloud Build's manual approval steps, which are separate and apply to build pipelines, not deployment pipelines.

Practice this question →
54
MCQeasy

A company uses Cloud Source Repositories and Cloud Build to build and deploy a Node.js application to Google Kubernetes Engine (GKE). The build step fails intermittently with an error 'npm ERR! network timeout'. What is the most efficient way to reduce build failures?

A.Configure npm to use a proxy and increase the timeout in the build step.
B.Use Artifact Registry to cache npm packages and change npm registry url.
C.Set the build to retry on failure in the Cloud Build trigger configuration.
D.Increase the machine type to e2-highmem-4 in the cloudbuild.yaml.
AnswerA

A longer timeout reduces failures due to temporary network issues.

Why this answer

Configuring npm to use a proxy and increasing the timeout directly addresses network timeouts during package downloads. Option B is incorrect because using Artifact Registry to cache npm packages changes the registry URL but does not mitigate intermittent network timeouts; the npm client still needs to reach the registry. Option C is incorrect because setting the build to retry on failure in Cloud Build trigger only retries the entire build, which is inefficient and still may fail repeatedly due to the same timeout.

Option D is incorrect because increasing the machine type does not resolve network timeouts; it only provides more CPU/memory.

Practice this question →
55
MCQmedium

An organization uses Cloud Build with a private pool to build container images that require access to on-premises Artifactory. After moving to a new VPC, builds fail with 'Connection refused' when fetching dependencies. What is the best step to troubleshoot?

A.Verify that VPC Network Peering is established between the Cloud Build private pool's service producer VPC and the customer VPC, and that routes to on-premises are present.
B.Verify that the Cloud Build service account has the dns.networks.bindPrivateZone permission.
C.Check that the Cloud Build service account has the storage.objectViewer role on the Artifactory bucket.
D.Ensure that Cloud NAT is configured in the private pool's VPC.
AnswerA

Private pools require peering; missing peering stops traffic.

Why this answer

The error 'Connection refused' indicates that the Cloud Build private pool's worker VMs cannot reach the on-premises Artifactory server. Private pools are deployed in a Google-managed service producer VPC that must be connected to the customer VPC via VPC Network Peering. Without this peering and the correct routes to the on-premises network (e.g., via Cloud VPN or Dedicated Interconnect), traffic from the private pool is dropped, causing the connection refusal.

Exam trap

The trap here is that candidates confuse connectivity issues with IAM permissions or misapply Cloud NAT, thinking it provides outbound access to on-premises, when in reality private pools require VPC peering and proper routing to reach non-Google Cloud endpoints.

How to eliminate wrong answers

Option B is wrong because the dns.networks.bindPrivateZone permission is used for binding a private DNS zone to a VPC network, which is unrelated to the connectivity issue causing 'Connection refused'. Option C is wrong because Artifactory is an on-premises service, not a Google Cloud Storage bucket; the storage.objectViewer role applies to GCS buckets, not to on-premises HTTP/HTTPS endpoints. Option D is wrong because Cloud NAT provides outbound internet access for private VMs, but the private pool's VPC is the service producer VPC managed by Google, not the customer's VPC; Cloud NAT in the customer VPC does not affect the private pool's connectivity to on-premises.

Practice this question →
56
MCQhard

A company uses Cloud Deploy for continuous delivery to GKE. They have a delivery pipeline with a rollout strategy: canary (25% for 30m) then full. The canary rollout fails because the new revision's health check errors. The team wants to automatically rollback the canary and notify. What native GCP feature can achieve this?

A.Configure Cloud Monitoring alerting policy on deployment errors that triggers a Cloud Function to rollback.
B.Set up a Cloud Build trigger that detects deployment failure and runs a rollback.
C.Configure a Cloud Deploy rollout strategy with an automated rollback policy.
D.Use a Cloud Deploy rollout strategy with a post-deploy hook that calls Cloud Run jobs to revert.
AnswerC

Cloud Deploy's rollbackPolicy enables automated rollback on failure, making it a native and integrated solution.

Why this answer

Cloud Deploy supports automated rollback through its rollbackPolicy configuration in the delivery pipeline. When a rollout fails health checks, the rollbackPolicy can automatically initiate a rollback to the previous successful revision. Additionally, Cloud Deploy can integrate with Cloud Monitoring or Pub/Sub to send notifications.

Option A is incorrect because while you can set up an alert and Cloud Function, that is not a native feature of Cloud Deploy and requires custom implementation. Option B is incorrect because Cloud Build triggers are meant for building and testing, not for rollback automation. Option D is incorrect because post-deploy hooks are for custom actions after deployment, not for automatic rollback on failure.

Practice this question →
57
Multi-Selectmedium

A team is setting up CI/CD for a microservices architecture. They want to ensure each service is independently buildable and deployable. What practices should they adopt? (Select THREE)

Select 3 answers
A.Use Artifact Registry with separate repositories per service
B.Use Cloud Deploy's multi-target pipeline
C.Use a single repository with separate Cloud Build triggers per service
D.Use separate repositories per service
E.Use Cloud Build's build config with substitutions to build multiple services
AnswersA, C, D

Separate repositories provide isolation and access control per service.

Why this answer

Options A, C, and D are correct. Option A: Using separate Artifact Registry repositories per service ensures artifact isolation. Option C: Using a single repository (monorepo) with separate Cloud Build triggers per service allows each service to be built independently.

Option D: Using separate repositories per service provides clear boundaries and independent build pipelines. Option B is incorrect because Cloud Deploy's multi-target pipeline is for deployment, not builds. Option E is incorrect because using a single build config with substitutions to build multiple services reduces build independence, as a change in one service could affect the others.

Practice this question →
58
MCQmedium

A team uses a monorepo with multiple microservices in separate directories. They want to build only the changed service(s) when a push occurs to the repo. How can they achieve this efficiently?

A.Use a single Cloud Build trigger with a Dockerfile build step that builds all services.
B.Use Cloud Functions to invoke Cloud Build per changed directory.
C.Create multiple Cloud Build triggers, each with a different includeFiles filter matching the service directory.
D.Use a Cloud Build trigger with a build config that dynamically detects changes using git diff.
AnswerC

includeFiles and excludeFiles allow triggering only when files in specific paths change.

Why this answer

Cloud Build triggers can be configured with includeFiles filters to trigger only when files in a specific directory change, allowing each microservice to build independently. Option A builds all services, which is inefficient for a monorepo with multiple microservices. Option B uses Cloud Functions to invoke Cloud Build, adding unnecessary complexity and overhead.

Option D relies on dynamic detection with git diff, which is not a built-in feature of Cloud Build triggers and would require custom scripting.

Practice this question →
59
MCQhard

Refer to the exhibit. A DevOps engineer is debugging a Cloud Build pipeline that fails after the second step. The error indicates that the docker push fails with a permission denied error. The service account used by Cloud Build has the roles/storage.objectAdmin role on the project. What is the most likely cause of the failure?

A.The docker push command uses an incorrect repository path.
B.The service account does not have permission to push to Artifact Registry.
C.The Cloud Build service account needs the roles/artifactregistry.writer role.
D.The gcloud auth configure-docker step must be run for Artifact Registry.
AnswerC

Artifact Registry requires specific roles; storage.objectAdmin is insufficient for pushing images.

Why this answer

The service account has storage.objectAdmin which grants access to Cloud Storage, not Artifact Registry. Pushing to Artifact Registry requires the roles/artifactregistry.writer (or admin) role. Option A is too vague.

Option D is already performed in the first step. Option B is less likely as the path appears correct. Option C correctly identifies the missing role.

Practice this question →
60
MCQhard

A company uses Spinnaker for continuous delivery across multiple GKE clusters. After a recent infrastructure change, the 'Canary' deployment strategy fails during the 'disable' phase of the old version. The error log shows: 'Unable to disable server group: Not authorized to perform compute.instanceGroups.update.' What is the most likely root cause?

A.The GKE cluster has reached its maximum node quota.
B.The Cloud Deploy pipeline is missing the required IAM role for the Spinnaker service account.
C.The Spinnaker service account lacks the compute.instanceGroups.update permission on the project.
D.The Kayenta canary analysis service is not configured correctly.
AnswerC

Correct: Spinnaker uses this permission to disable old server groups.

Why this answer

The error 'Unable to disable server group: Not authorized to perform compute.instanceGroups.update' directly indicates an IAM permissions issue. In Spinnaker, the service account used to interact with GCP must have the compute.instanceGroups.update permission to manage instance groups during the disable phase of a canary deployment. Option C correctly identifies that the Spinnaker service account lacks this specific permission on the project.

Exam trap

Google Cloud often tests the distinction between permissions errors and resource quota errors, leading candidates to incorrectly select quota-related options when the error message explicitly states 'Not authorized'.

How to eliminate wrong answers

Option A is wrong because reaching the maximum node quota would cause a failure to provision new nodes, not a permissions error during the disable phase. Option B is wrong because Cloud Deploy is a separate Google Cloud service; the error is from Spinnaker's own service account, not from a Cloud Deploy pipeline. Option D is wrong because Kayenta handles canary analysis and metric evaluation, not the disabling of server groups; the error is an IAM authorization failure, not a configuration issue with Kayenta.

Practice this question →
61
MCQmedium

A company uses Cloud Build to deploy a microservices application to Google Kubernetes Engine (GKE). They want to integrate Container Analysis to scan images for vulnerabilities before deployment. What is the minimal set of changes needed to achieve this?

A.Enable the Container Analysis API; no changes to the build configuration are needed.
B.Migrate images from Container Registry to Artifact Registry and enable vulnerability scanning there.
C.Add a build step to run a vulnerability scanner CLI tool before pushing the image.
D.Enable Binary Authorization to block deployment of vulnerable images.
AnswerA

Cloud Build automatically pushes images to defined registry, and Container Analysis scans them when API is enabled.

Why this answer

Enabling the Container Analysis API allows Cloud Build to automatically scan container images for vulnerabilities when they are pushed to Container Registry or Artifact Registry. No additional build steps or configuration changes are required. Option B is incorrect because migrating to Artifact Registry is not minimal; Container Analysis works with both registries.

Option C is incorrect because Cloud Build already integrates with Container Analysis, so adding a separate scanner is unnecessary. Option D is incorrect because Binary Authorization is a policy enforcement tool that uses scan results but does not perform scanning itself.

Exam trap

Candidates may mistakenly think they need to add a separate vulnerability scan step (like Trivy or Aqua) in the Cloud Build configuration, but Cloud Build's native integration with Container Analysis makes this automatic once the API is enabled.

Practice this question →
62
MCQeasy

A team uses Cloud Build to deploy a Cloud Run service. The build fails with: 'ERROR: (gcloud.run.services.update) PERMISSION_DENIED: Permission 'run.services.update' denied on resource.' The Cloud Build service account has the Cloud Run Admin role. What is missing?

A.The build config must use the Cloud Run deployer step instead of the gcloud command.
B.The Cloud Build service account should have the Owner role on the project.
C.The Cloud Run service must be deployed in the same region as the build.
D.The Cloud Build service account needs the 'run.services.update' permission or the Cloud Run Admin role.
AnswerA

Correct: The Cloud Run deployer step is designed to handle permissions correctly and is the recommended method for deploying Cloud Run services from Cloud Build. Using gcloud directly can lead to permission errors despite having the correct roles.

Why this answer

The error occurs because using the gcloud command directly in a Cloud Build step does not automatically handle IAM permissions as the Cloud Run deployer step does. Although the Cloud Build service account has the Cloud Run Admin role, the gcloud command may fail due to missing resource-level permissions or because it uses a different service account context. The Cloud Run deployer step is designed to properly authenticate and apply the necessary permissions for deploying to Cloud Run.

Exam trap

A common misconception is that any step type can be used interchangeably for Cloud Run deployments. However, the Cloud Run deployer step is required to correctly manage IAM permissions and service account impersonation, while the gcloud command may fail even with correct role assignments.

How to eliminate wrong answers

Option A is wrong because the Cloud Run deployer step is a convenience wrapper that still requires the same underlying IAM permissions; using it instead of the gcloud command does not bypass permission checks. Option B is wrong because the Owner role is overly permissive and unnecessary; the Cloud Run Admin role (roles/run.admin) already includes all required Cloud Run permissions, including 'run.services.update'. Option C is wrong because Cloud Run deployments are not region-restricted by the build's region; the service can be deployed to any region regardless of where Cloud Build runs.

Practice this question →
63
Multi-Selecthard

Which TWO are best practices for implementing CI/CD on Google Cloud?

Select 2 answers
A.Use Cloud Run for all services.
B.Use Artifact Registry for storing container images.
C.Use Cloud Build for all deployments, including infrastructure changes.
D.Use Cloud Deploy for Kubernetes deployments.
E.Use GitHub Actions instead of Cloud Build.
AnswersB, D

Artifact Registry is the recommended registry for Google Cloud.

Why this answer

Artifact Registry is the recommended service for storing, managing, and securing container images and other artifacts in Google Cloud. It integrates natively with Cloud Build, Cloud Run, and Kubernetes, providing vulnerability scanning and IAM-based access control, which are essential for a secure CI/CD pipeline.

Exam trap

Google Cloud often tests the distinction between CI/CD tools and compute services, so candidates mistakenly select Cloud Run as a CI/CD best practice because it is a popular Google Cloud service, but it is a runtime environment, not a pipeline component.

Practice this question →
64
Multi-Selecteasy

What security checks can be integrated into a Cloud Build CI/CD pipeline? (Select TWO)

Select 2 answers
A.Manual code review
B.Container scanning with Artifact Analysis
C.Network penetration testing
D.Dynamic application security testing (DAST)
E.Static application security testing (SAST) with Cloud Build custom steps
AnswersB, E

Artifact Analysis can scan container images for vulnerabilities as part of the pipeline.

Why this answer

Options B and E are correct. Container scanning with Artifact Analysis (B) is a native security check in Cloud Build. Static application security testing (SAST) can be added via custom steps (E).

Option A (manual code review) is a process, not a tool that can be integrated programmatically. Option C (network penetration testing) is an external activity not typically integrated into CI/CD. Option D (DAST) is for running applications, not during build.

Practice this question →
65
MCQeasy

During a Cloud Build pipeline, a build step fails because the Docker image tag already exists in Container Registry. The team wants to avoid overwriting tags. What is the best practice to resolve this?

A.Use the commit SHA as the image tag in the build step.
B.Specify the :latest tag and always push to that tag.
C.Add a step to pull the image before building to ensure it's present.
D.Configure the build to retry on failure with a backoff.
AnswerA

Commit SHA is unique per change, avoiding collisions.

Why this answer

Using the commit SHA as the image tag guarantees uniqueness because each commit produces a distinct SHA. This prevents tag collisions in Container Registry without overwriting, as the SHA is immutable for that commit. It also provides traceability back to the exact source code version that produced the image.

Exam trap

Google Cloud often tests the misconception that retries or pulling images can resolve tag conflicts, when in fact only a unique tag strategy (like commit SHA) prevents the collision at the source.

How to eliminate wrong answers

Option B is wrong because using the :latest tag encourages overwriting, which directly violates the team's requirement to avoid overwriting tags. Option C is wrong because pulling an image before building does not prevent tag conflicts; it only ensures the image is cached locally, and the build step will still fail if the tag already exists in the registry. Option D is wrong because retrying with backoff does not resolve the underlying tag collision; it will simply fail again on each retry since the tag still exists.

Practice this question →
66
MCQhard

Refer to the exhibit. A rollout to dev succeeds, but when promoting to prod, it fails with 'Target 'prod' not found'. What is the issue?

A.The prod target does not have a required approval rule.
B.The prod target has not been created in the same region.
C.The prod target exists but is in a different project.
D.The delivery pipeline must be redeployed to include the prod target.
AnswerB

This is correct. The prod target must exist in the same region as the delivery pipeline. If it was created in a different region, it will not be found.

Why this answer

The error 'Target 'prod' not found' indicates that the prod target does not exist in the Cloud Deploy pipeline. In Google Cloud Deploy, targets must be created in the same region as the delivery pipeline to be referenced. If the prod target was not created in the same region as the pipeline, it will not be found during promotion.

Practice this question →
67
MCQhard

A Cloud Deploy pipeline fails during a rollout with: 'FAILED_PRECONDITION: The release is not in a state that can be promoted.' The Cloud Build service account has the IAM roles shown in the exhibit. What is the missing role or permission?

A.The service account is missing the 'roles/clouddeploy.jobRunner' role.
B.The service account is missing the 'roles/cloudbuild.builds.builder' role.
C.The service account is missing the 'roles/clouddeploy.operator' role.
D.The service account is missing the 'roles/clouddeploy.approver' role, which includes the 'clouddeploy.releases.promote' permission.
AnswerD

Approver role is needed for promotion.

Why this answer

The error 'FAILED_PRECONDITION: The release is not in a state that can be promoted' occurs when a Cloud Deploy pipeline attempts to promote a release but the service account lacks the `clouddeploy.releases.promote` permission. This permission is included in the `roles/clouddeploy.approver` role, which is required to trigger a promotion from one target to the next in the pipeline. Without this role, the release cannot be promoted even if other deployment permissions are present.

Exam trap

Google Cloud often tests the distinction between the `clouddeploy.operator` role (which manages releases and rollouts) and the `clouddeploy.approver` role (which specifically allows promotion), leading candidates to mistakenly choose the operator role for promotion actions.

How to eliminate wrong answers

Option A is wrong because the `roles/clouddeploy.jobRunner` role is used for executing deployment jobs (e.g., running Skaffold render/apply) and does not include the `clouddeploy.releases.promote` permission needed for promotion. Option B is wrong because the `roles/cloudbuild.builds.builder` role is for Cloud Build execution, not for Cloud Deploy release promotion; it does not grant `clouddeploy.releases.promote`. Option C is wrong because the `roles/clouddeploy.operator` role provides broader management permissions (e.g., creating releases, rollbacks) but does not include the `clouddeploy.releases.promote` permission, which is exclusive to the `roles/clouddeploy.approver` role.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Cicd Pipelines questions.

Start 20-question session