Knowledge + Practice

CCNA Pcde Cicd Pipelines Questions

75 of 135 questions · Page 1/2 · Pcde Cicd Pipelines topic · Answers revealed

Practice these questions Exam hub All questions

1

Multi-Selectmedium

An organization uses Cloud Build to build and deploy applications. They need to ensure that build secrets (e.g., API tokens) are securely injected into build steps without being exposed in the build logs. Which two actions should they take?

Select 2 answers

A.Use the 'env' field to pass the secret as a build substitution variable

B.Use the 'secretEnv' field in the build step to reference a secret from Secret Manager

C.Encrypt the entire cloudbuild.yaml using Cloud KMS

D.Store the secret in Secret Manager and assign appropriate permissions to the Cloud Build service account

E.Store the secret value directly in the cloudbuild.yaml file

AnswersB, D

secretEnv injects the secret as an environment variable without logging it.

Why this answer

Option B is correct because the `secretEnv` field in a Cloud Build step allows you to inject a secret from Secret Manager into the build environment as an environment variable, without the secret value being written to build logs. This ensures the secret is available to the step at runtime but never exposed in log output.

Exam trap

Cisco often tests the misconception that encrypting the build configuration file or using plain environment variables is sufficient for secret management, when in fact only Secret Manager with `secretEnv` prevents log exposure.

Practice this question →

2

MCQeasy

A team uses Kustomize to manage environment-specific configurations for their GKE deployments. They have a base overlay and overlays for dev, staging, and prod. Which command should they use to generate the final Kubernetes manifests for the staging environment?

A.kubectl kustomize staging/

B.kustomize build staging/

C.skaffold build --kustomize staging/

D.kubectl apply -k staging/

AnswerB

This outputs the final YAML for the staging overlay.

Why this answer

The `kustomize build staging/` command processes the Kustomize overlay located in the `staging/` directory, which includes a `kustomization.yaml` file that references the base overlay and applies environment-specific patches, configMapGenerator entries, and namespace settings. This generates the final Kubernetes manifests for the staging environment without applying them to a cluster. The `kustomize` CLI tool is the standard way to render Kustomize overlays, and it is the correct command for generating manifests as part of a CI/CD pipeline.

Exam trap

Candidates often confuse `kustomize build` (generates manifests) with `kubectl apply -k` (applies manifests). For Google exams, remember that `kustomize build` is used to render final YAML in CI/CD pipelines without applying.

How to eliminate wrong answers

Option A is wrong because `kubectl kustomize staging/` is not a valid kubectl command; kubectl does not have a `kustomize` subcommand. Option C is wrong because `skaffold build --kustomize staging/` is not a valid Skaffold command; Skaffold uses `skaffold run` or `skaffold build` with a `skaffold.yaml` configuration, and the `--kustomize` flag does not exist. Option D is wrong because `kubectl apply -k staging/` applies the rendered manifests directly to a Kubernetes cluster, but the question asks for generating the final manifests, not applying them.

Practice this question →

3

MCQeasy

An engineer wants to automatically build a Docker image in Cloud Build whenever code is pushed to the main branch of a repository. Which configuration is correct?

A.Create a Cloud Build trigger with event 'pull_request', source 'repository', branch filter 'main'

B.Create a Cloud Build trigger with event 'push', source 'repository', branch filter '.*'

C.Create a Cloud Build trigger with event 'manual', source 'repository', branch filter 'main'

D.Create a Cloud Build trigger with event 'push', source 'repository', branch filter '^main$'

AnswerD

Correct: push event with branch filter for main triggers on push to main.

Why this answer

The `push` trigger with a branch filter for `main` ensures builds are triggered on pushes to the main branch.

Practice this question →

4

MCQmedium

A team wants to adopt GitOps for a GKE cluster. They need a solution that automatically syncs their Kubernetes manifests from a Git repository to the cluster and ensures the cluster state matches the repo. Which Google Cloud service should they use?

A.Config Connector

B.Config Sync

C.Cloud Deploy

D.Argo CD on GKE

AnswerB

Config Sync syncs Git repos with GKE clusters, enforcing desired state.

Why this answer

Config Sync is the correct choice because it is the native GitOps agent within Google Cloud's Anthos platform, designed specifically to continuously reconcile the state of a GKE cluster with Kubernetes manifests stored in a Git repository. It automatically detects changes in the configured source of truth and applies them to the cluster, ensuring drift is corrected without manual intervention.

Exam trap

Cisco often tests the distinction between native Google Cloud managed services and third-party or open-source tools that can be deployed on GKE, leading candidates to pick Argo CD because it is a popular GitOps tool, even though the question explicitly asks for a 'Google Cloud service'.

How to eliminate wrong answers

Option A is wrong because Config Connector is a tool for managing Google Cloud resources (like Cloud SQL instances or IAM policies) via Kubernetes custom resources, not for syncing Kubernetes manifests from a Git repository to the cluster. Option C is wrong because Cloud Deploy is a continuous delivery service that orchestrates rollouts across multiple targets (e.g., dev, staging, prod) but does not automatically sync cluster state from a Git repo; it requires explicit delivery pipeline definitions and does not provide continuous drift reconciliation. Option D is wrong because Argo CD on GKE is a valid GitOps tool, but the question asks for a 'Google Cloud service' — Argo CD is an open-source project, not a managed Google Cloud service, and while it can be deployed on GKE, it is not a first-party Google offering like Config Sync.

Practice this question →

5

MCQeasy

A developer wants to use a pre-existing Docker image from Artifact Registry in a Cloud Build step. How should they authenticate the build step to pull the image?

A.Run 'gcloud auth configure-docker' in a build step.

B.Set the environment variable 'ARTIFACT_REGISTRY_KEY' in the build step.

C.Store a service account key in Secret Manager and activate it in the build step.

D.Use a Docker step with the image specified directly; Cloud Build automatically uses its service account.

AnswerD

Cloud Build pulls images using its service account credentials.

Why this answer

Option D is correct because Cloud Build's default service account is automatically granted the Artifact Registry Reader role (roles/artifactregistry.reader) when the Cloud Build API is enabled in a project. This means any build step that references an image from Artifact Registry can pull it without explicit authentication, as Cloud Build uses its own service account credentials to authenticate the pull request to the registry.

Exam trap

A common misconception is that explicit authentication (like running 'gcloud auth configure-docker' or using a service account key) is always needed to pull images from Artifact Registry. However, Cloud Build's default service account is automatically granted the Artifact Registry Reader role, so no explicit authentication is required.

How to eliminate wrong answers

Option A is wrong because 'gcloud auth configure-docker' configures Docker to use user or service account credentials for authentication, but it is unnecessary in Cloud Build since the environment already uses the Cloud Build service account automatically; running it in a build step would be redundant and could cause confusion. Option B is wrong because there is no standard environment variable named 'ARTIFACT_REGISTRY_KEY' in Cloud Build or Docker; Artifact Registry authentication relies on OAuth2 tokens or service account keys, not a single environment variable. Option C is wrong because while storing a service account key in Secret Manager and activating it in a build step is a valid pattern for other scenarios, it is unnecessary overhead for pulling images from Artifact Registry in Cloud Build, as the default service account already has the required permissions.

Practice this question →

6

MCQmedium

A company is using Cloud Deploy with a delivery pipeline that has dev, staging, and prod targets. They want to require manual approval before deploying to prod. What should they add?

A.Set up a Cloud Function to send approval email

B.Use Binary Authorization

C.Configure a 'requireApproval' property on the prod target

D.Add a rollout policy

AnswerC

Setting requireApproval to true on a target makes the pipeline pause for manual approval before deploying to that target.

Why this answer

Cloud Deploy supports approval gates: you can define a manual approval step in the delivery pipeline that must be approved before proceeding to the next target.

Practice this question →

7

Multi-Selecthard

A team uses Cloud Deploy to manage deployments to GKE across dev, staging, and prod. They want to implement a canary deployment strategy that automatically progresses based on latency metrics and includes a manual approval step before the full rollout. Which three Cloud Deploy features should they use together?

Select 3 answers

A.Blue/green strategy

B.Canary deployment strategy

C.SLO-based verification

D.Automated rollback

E.Manual approval gate

AnswersB, C, E

Required for the progressive rollout pattern.

Why this answer

Option B is correct because Cloud Deploy's canary deployment strategy allows you to progressively shift traffic to a new version, which aligns with the requirement for a gradual rollout. Option C is correct because SLO-based verification uses latency metrics (e.g., from Cloud Monitoring) to automatically determine whether the canary should progress, meeting the need for automated progression based on latency. Option E is correct because a manual approval gate can be inserted before the final full rollout, satisfying the requirement for a manual approval step.

Exam trap

The trap here is that candidates confuse 'automated rollback' (a reactive failure-handling feature) with 'automated progression' (a proactive verification step), and they may incorrectly select blue/green because they think it supports canary-like traffic shifting, whereas Cloud Deploy's blue/green does not support phased traffic increases.

Practice this question →

8

Multi-Selecthard

A company uses Cloud Deploy to deploy to multiple GKE clusters (dev, staging, prod). They want to implement a canary deployment strategy for the prod target. The canary should deploy 10% of pods initially, then after 30 minutes and a manual approval, promote to 100%. Which configurations are necessary? (Choose THREE).

Select 3 answers

A.Set the canary percentage to 10% and the promotion interval to 30m.

B.Add an approval gate on the prod target.

C.Define a canary strategy in the prod target within the delivery pipeline.

D.Set the strategy to 'blue/green' with a 10% initial pool.

E.Create a separate delivery pipeline for canary deployments.

AnswersA, B, C

This defines the initial canary percentage and the wait time before promotion.

Why this answer

Option A is correct because setting the canary percentage to 10% and the promotion interval to 30m directly implements the required behavior: initially 10% of pods receive traffic, and after 30 minutes the deployment automatically attempts promotion. This matches the canary deployment strategy in Cloud Deploy where the `canaryDeployment` configuration specifies `percentages` and `verify` intervals.

Exam trap

Cisco often tests the distinction between canary and blue/green strategies, trapping candidates who confuse 'initial pool' percentages with canary incremental percentages, or who think separate pipelines are required for different deployment strategies.

Practice this question →

9

MCQhard

A company uses Cloud Deploy to manage deployments to multiple GKE clusters across environments. They want to implement a canary deployment strategy where 10% of traffic goes to the new version initially, and after manual approval, the remaining 90% rolls out. What should be included in the delivery pipeline configuration?

A.Configure a 'canary' strategy with a single phase of 10% and rely on external traffic management

B.Define a 'canary' strategy with a first phase of 10% and a second phase of 90% with an approval gate

C.Set the rollout strategy to 'standard' and use skaffold.yaml for traffic splitting

D.Use a 'blueGreen' strategy with a 10% preview phase

AnswerB

Canary strategy in Cloud Deploy allows multiple phases. An approval gate can be placed before proceeding to the next phase.

Why this answer

Option B is correct because Cloud Deploy's 'canary' strategy allows defining multiple phases with incremental traffic percentages, and an approval gate can be inserted between phases to require manual sign-off before proceeding. This directly matches the requirement: a first phase sending 10% traffic to the new version, then a manual approval, followed by a second phase rolling out the remaining 90%.

Exam trap

The trap here is that candidates confuse the 'canary' strategy with a single-phase deployment or mistakenly think 'standard' or 'blueGreen' strategies can achieve incremental traffic splitting with manual approval, when only a multi-phase canary with an approval gate satisfies the requirement.

How to eliminate wrong answers

Option A is wrong because a single-phase canary strategy cannot implement a two-step rollout with a manual approval gate; it would deploy the 10% phase and then automatically complete the rollout without waiting for approval. Option C is wrong because the 'standard' rollout strategy in Cloud Deploy does not support traffic splitting or phased canary deployments; it simply replaces all pods at once, and skaffold.yaml is used for building and deploying artifacts, not for traffic management. Option D is wrong because a 'blueGreen' strategy does not support incremental traffic percentages like 10%; it switches all traffic from the old version to the new version in one step, optionally with a preview phase that does not serve live traffic.

Practice this question →

10

MCQmedium

You are deploying a containerized application to Cloud Run using gcloud run deploy. You need to ensure that revisions are tagged with a custom identifier for testing purposes, without allocating any traffic to them. Which flag should you use?

A.--no-traffic

B.--tag=test

C.--traffic=test=0

D.--revision-suffix=test

AnswerB

Assigns the tag 'test' to the revision, allowing access via a test URL.

Why this answer

The `--tag` flag in `gcloud run deploy` assigns a custom tag (e.g., `test`) to a specific revision, allowing it to be accessed via a dedicated URL without receiving any live traffic. This is the correct way to create a tagged revision for testing or staging purposes while keeping the primary revision serving user requests.

Exam trap

The trap here is that candidates confuse the `--tag` flag (which creates a named, traffic-free endpoint) with `--no-traffic` (which only prevents traffic but does not provide a custom identifier) or with `--revision-suffix` (which only renames the revision without creating a separate access point).

How to eliminate wrong answers

Option A is wrong because `--no-traffic` prevents the new revision from receiving any traffic but does not assign a custom identifier or tag; it simply deploys the revision with 0% traffic allocation. Option C is wrong because `--traffic=test=0` is syntactically invalid; the `--traffic` flag expects a revision name or tag with a percentage (e.g., `--traffic=latest=100`), not a tag name as a key. Option D is wrong because `--revision-suffix=test` appends a suffix to the revision name (e.g., `my-service-test`) but does not create a tag or a dedicated URL for testing; it only renames the revision.

Practice this question →

11

Multi-Selectmedium

A company uses Cloud Deploy to manage deployments to multiple GKE clusters. They want to implement a canary deployment strategy where the new revision receives 10% of traffic initially, and after 5 minutes with no errors, it receives 100%. Which TWO actions are required to achieve this?

Select 2 answers

A.Integrate with Cloud Monitoring for metric-based canary analysis

B.Use a blue/green deployment strategy instead

C.Enable rollback on failure in the pipeline definition

D.Configure a manual approval gate for the canary phase

E.Configure a canaryDeployment strategy with multiple phases and wait times

AnswersA, E

Metric analysis can automatically verify health and progress the rollout.

Why this answer

Cloud Deploy supports canary deployments using the `canaryDeployment` strategy, which allows defining multiple phases with traffic percentages and wait times. In this scenario, the first phase sends 10% traffic, and after 5 minutes with no errors (detected via Cloud Monitoring integration), it progresses to 100%. Thus, configuring the `canaryDeployment` strategy with phases and wait times (E) is required.

Additionally, integrating with Cloud Monitoring (A) is necessary to automatically detect errors and trigger the progression or rollback. Option D (manual approval) is not automated and does not fit the 'no errors' requirement.

Practice this question →

12

Multi-Selectmedium

A DevOps team wants to use Cloud Deploy to promote releases across multiple targets. They need to define a delivery pipeline that includes a canary deployment for a GKE cluster and a standard deployment for Cloud Run. Which two strategies can they use in the same pipeline?

Select 2 answers

A.Progressive delivery strategy with manual approval

B.Blue/green strategy for Cloud Run

C.Rolling update strategy for GKE

D.Canary strategy for GKE

E.Standard strategy for Cloud Run

AnswersD, E

Canary is supported for GKE targets.

Why this answer

Cloud Deploy allows different deployment strategies per target. You can mix 'canary' for GKE and 'standard' for Cloud Run in the same delivery pipeline. 'Blue/green' is also supported but not required.

Practice this question →

13

MCQhard

A team uses Cloud Build to deploy to Cloud Run via gcloud run deploy. They need to perform a canary deployment where 10% of traffic goes to the new revision for 10 minutes before shifting to 100%. The deployment must be automated without manual steps. What approach should they take?

A.Use Cloud Deploy with a canary strategy targeting Cloud Run

B.Use Cloud Build with a substitution variable to control traffic percentage across two builds

C.Use two separate Cloud Build steps: first deploy with --no-traffic, then second step after 10 minutes with --to-revisions

D.Use a single gcloud run deploy with --traffic flags to set 10% initially, then manually update traffic later

AnswerA

Cloud Deploy supports canary deployments to Cloud Run, automatically managing traffic splitting with metrics.

Why this answer

Cloud Run supports traffic splitting via the --no-traffic flag (deploy without serving traffic) and then gradually updating traffic with update-traffic. This can be automated in a Cloud Build step with a sleep or using Cloud Deploy's canary strategy.

Practice this question →

14

Multi-Selectmedium

An organization wants to enforce security policies on container images before deployment. They need to scan images for vulnerabilities and ensure only images that pass the scan can be deployed. Which TWO services should they use? (Select TWO)

Select 2 answers

A.Container Analysis

B.Artifact Registry

C.Cloud Build

D.Cloud Deploy

E.Binary Authorization

AnswersA, E

Container Analysis provides vulnerability scanning.

Why this answer

Container Analysis scans images for vulnerabilities. Binary Authorization enforces policies that require images to have attestations (e.g., from Container Analysis) before deployment.

Practice this question →

15

MCQmedium

A team uses Cloud Deploy to manage deployments to GKE. They want to automatically roll back to the previous revision if a canary deployment fails health checks. What should they configure?

A.Configure a manual approval gate before promotion

B.Set the deployment strategy to blue/green

C.Set 'rollback-on-failure: true' in the delivery pipeline definition

D.Use a Cloud Build step to run kubectl rollout undo

AnswerC

This enables automatic rollback if the canary deployment fails.

Why this answer

Cloud Deploy supports automatic rollback on failure for canary deployments by setting `rollback-on-failure: true` in the delivery pipeline definition. When a canary deployment fails health checks, Cloud Deploy automatically reverts to the previous stable revision without manual intervention, ensuring minimal downtime and consistent release governance.

Exam trap

The trap here is that candidates confuse manual approval gates or alternative deployment strategies (like blue/green) with Cloud Deploy's specific `rollback-on-failure` configuration, which is the only built-in mechanism for automatic rollback on canary health check failures.

How to eliminate wrong answers

Option A is wrong because a manual approval gate before promotion only pauses the pipeline for human sign-off; it does not trigger an automatic rollback on health check failure. Option B is wrong because blue/green deployment strategy is a different deployment pattern that does not inherently provide automatic rollback on canary health check failures; Cloud Deploy's rollback-on-failure is a separate configuration. Option D is wrong because using a Cloud Build step to run kubectl rollout undo is a manual, scripted workaround that bypasses Cloud Deploy's built-in rollback automation and does not integrate with the delivery pipeline's health check failure detection.

Practice this question →

16

MCQeasy

A team is using Skaffold for local development and CI/CD. They want to use Skaffold profiles to handle differences between local and production environments. In the CI pipeline (Cloud Build), they want Skaffold to build and deploy using the production profile. How should they invoke Skaffold in the cloudbuild.yaml?

A.skaffold run --profile production

B.skaffold deploy --profile production

C.skaffold dev --profile production

D.skaffold build --profile production

AnswerA

skaffold run builds and deploys once, suitable for CI/CD.

Why this answer

Skaffold profiles can be selected with the --profile flag. In a CI environment, use skaffold run --profile production.

Practice this question →

17

Multi-Selectmedium

An organization uses GitOps with Config Sync to manage multiple GKE clusters. They want to ensure that any change to the Git repository is automatically applied to the clusters, and that no manual kubectl apply commands are used. Which TWO resources should they configure?

Select 2 answers

A.A Cloud Build trigger that runs kubectl apply on push

B.A Kustomize overlay for each cluster

C.RepoSync resource pointing to the Git repository

D.RootSync resource pointing to the Git repository

E.An Argo CD Application resource

AnswersC, D

RepoSync syncs namespace-scoped resources. Both can be used together.

Why this answer

Option C is correct because a RepoSync resource is used in Config Sync to synchronize a non-root namespace-level repository with the cluster, ensuring that any changes pushed to the Git repository are automatically applied without manual kubectl commands. Option D is correct because a RootSync resource is used to synchronize the root-level configuration (e.g., cluster-scoped resources) from a Git repository, providing the same automated GitOps workflow. Together, they cover both namespace and cluster-scoped resources, fulfilling the requirement of no manual kubectl apply.

Exam trap

Cisco often tests the distinction between RootSync and RepoSync, and the trap here is that candidates may confuse RepoSync (namespace-scoped) with RootSync (cluster-scoped) or incorrectly assume that any GitOps tool like Argo CD or Cloud Build is equivalent to Config Sync's native resources.

Practice this question →

18

MCQeasy

A team wants to use Cloud Build to build a Maven application and store the artifact in Artifact Registry. Which repository format should they use?

A.Python repository

B.npm repository

C.Docker repository

D.Maven repository

AnswerD

Correct: Maven repository stores Java jars and pom files.

Why this answer

The team is building a Maven application, which produces a JAR or WAR artifact. Artifact Registry supports a Maven repository format specifically designed to store and serve Maven artifacts, including pom.xml and JAR files, using the Maven repository layout. This allows Cloud Build to push the artifact directly to a Maven repository in Artifact Registry for dependency management and deployment.

Exam trap

Google often tests the candidate's ability to match the artifact type to the correct repository format, and the trap here is that candidates may confuse 'Maven' as a build tool with 'Docker' as a container format, or assume any artifact can go into any repository, ignoring the protocol-specific requirements.

How to eliminate wrong answers

Option A is wrong because a Python repository stores Python packages (e.g., .whl, .tar.gz) and uses the PyPI protocol, not Maven artifacts. Option B is wrong because an npm repository stores Node.js packages (e.g., .tgz) and uses the npm registry protocol, not Maven artifacts. Option C is wrong because a Docker repository stores container images (e.g., OCI-compliant layers) and uses the Docker Registry HTTP API, not Maven artifacts.

Practice this question →

19

Multi-Selecteasy

A developer is using Cloud Build to build a Docker image and wants to use build substitutions to dynamically set the image tag. Which built-in substitutions can they use? (Choose 2)

Select 2 answers

A.$TAG_NAME

B.$SHORT_SHA

C.$_IMAGE_NAME

D.$BRANCH_NAME

E.$_CUSTOM_TAG

AnswersB, D

Short SHA of the commit that triggered the build.

Why this answer

Cloud Build provides built-in substitutions like $SHORT_SHA (short commit SHA) and $BRANCH_NAME. $TAG_NAME is not a built-in substitution; $_USER_DEFINED is a custom substitution with underscore prefix.

Practice this question →

20

MCQmedium

A company uses Config Sync to manage GKE clusters in a GitOps fashion. They need to ensure that resources are automatically synced from a Git repository to the cluster, and that any drift from the desired state is corrected. Which Config Sync mode should they enable?

A.Dry-run mode

B.Sync mode

C.Monitor mode

D.Policy mode

AnswerB

Sync mode applies the manifests and continuously reconciles to the desired state.

Why this answer

Config Sync supports a 'sync' mode that automatically applies the manifests from the repository and continuously reconciles to correct drift. The 'monitor' mode only detects drift but does not correct it.

Practice this question →

21

MCQmedium

An engineer is configuring Cloud Build to use a substitution variable for the Docker image tag. They want the tag to be the short commit SHA. Which built-in substitution should they use?

A.$TAG_NAME

B.$SHORT_SHA

C.$COMMIT_SHA

D.$REVISION_ID

AnswerB

$SHORT_SHA is the built-in substitution for the short commit SHA.

Practice this question →

22

MCQhard

A team uses GitOps with Config Sync to manage multiple GKE clusters. They want to ensure that if a cluster's state drifts from the desired state in the Git repository, it is automatically corrected. Config Sync is installed with the default settings. What else must be configured?

A.Enable the 'drift correction' option in Config Sync

B.Set up a Cloud Scheduler to run 'kubectl apply' periodically

C.Install Anthos Config Management with the 'policy controller' enabled

D.No additional configuration is required; drift correction is automatic

AnswerD

Config Sync automatically reconciles the cluster state with the Git repository, correcting any drift.

Why this answer

Config Sync, by default, operates in a continuous reconciliation loop. It periodically compares the live state of the cluster against the desired state defined in the Git repository. If any drift is detected, Config Sync automatically applies the necessary changes to revert the cluster back to the desired state.

Therefore, no additional configuration is needed for automatic drift correction.

Exam trap

The trap here is that candidates may assume a separate 'drift correction' feature must be enabled, not realizing that Config Sync's core design already includes automatic drift correction as a fundamental behavior of its continuous reconciliation loop.

How to eliminate wrong answers

Option A is wrong because Config Sync does not have a separate 'drift correction' option; drift correction is an inherent behavior of its reconciliation loop, not a toggleable feature. Option B is wrong because using Cloud Scheduler to run 'kubectl apply' is an external, manual workaround that duplicates Config Sync's built-in functionality and introduces unnecessary complexity and potential race conditions. Option C is wrong because Anthos Config Management's 'policy controller' (based on OPA/Gatekeeper) is for enforcing policy constraints, not for correcting configuration drift; drift correction is handled by the Config Sync component itself.

Practice this question →

23

MCQmedium

A team uses Cloud Deploy with a canary deployment strategy to GKE. They want to automatically promote the canary to full production if the error rate is below 1% for 10 minutes. What should they configure?

A.Use a Cloud Build step to check error rates

B.Use a manual approval gate

C.Set the deployment strategy to blue/green

D.Configure a canary deployment with a metric threshold in clouddeploy.yaml

AnswerD

Cloud Deploy can be configured to automatically promote based on metrics.

Why this answer

Option D is correct because Cloud Deploy supports canary deployments with automated promotion based on metric thresholds defined in the `clouddeploy.yaml` configuration. By specifying a metric threshold (e.g., error rate < 1% for 10 minutes) under the `canaryDeployment` strategy, Cloud Deploy can automatically promote the canary to full production without manual intervention or external scripts.

Exam trap

The trap here is that candidates confuse Cloud Build's ability to run scripts with the need for a continuous metric evaluation, leading them to choose Option A, when in fact Cloud Deploy's native metric threshold configuration is the correct and simpler approach.

How to eliminate wrong answers

Option A is wrong because Cloud Build is a CI/CD execution service, not a monitoring or decision engine; checking error rates would require integrating with a monitoring service like Cloud Monitoring, and Cloud Build steps are not designed for continuous metric evaluation over a 10-minute window. Option B is wrong because a manual approval gate requires human intervention to promote, contradicting the requirement for automatic promotion based on a metric threshold. Option C is wrong because blue/green deployment is a different strategy that typically involves switching traffic between two environments, not a canary with phased rollout and metric-based promotion.

Practice this question →

24

MCQmedium

A DevOps engineer is setting up Docker credential helper for Artifact Registry on a Cloud Build worker. They want the build steps to authenticate to Artifact Registry without storing service account keys. What is the recommended approach?

A.Use a custom builder that includes Docker with Artifact Registry credentials.

B.Store a service account key in Cloud Secret Manager and load it in a build step.

C.Set environment variable ARTIFACT_REGISTRY_KEY in cloudbuild.yaml.

D.Run gcloud auth configure-docker as a build step; Cloud Build's service account will be used automatically.

AnswerD

This command configures Docker to use gcloud as a credential helper, which uses the environment's service account.

Why this answer

Option D is correct because `gcloud auth configure-docker` configures Docker to use `gcloud` as a credential helper, which automatically uses the Cloud Build worker's attached service account to obtain short-lived access tokens for Artifact Registry. This avoids storing any long-lived service account keys, aligning with Google Cloud's security best practices for CI/CD pipelines.

Exam trap

The trap here is that candidates may think a custom builder or secret injection is necessary for authentication, when in fact Cloud Build's default service account can be used directly with `gcloud auth configure-docker` to avoid storing any keys.

How to eliminate wrong answers

Option A is wrong because a custom builder does not inherently solve authentication; it would still need credentials to be injected or configured, and it adds unnecessary complexity without leveraging Cloud Build's built-in identity. Option B is wrong because storing a service account key in Secret Manager and loading it in a build step introduces a long-lived secret that must be managed and rotated, violating the principle of avoiding static keys in CI/CD. Option C is wrong because there is no standard `ARTIFACT_REGISTRY_KEY` environment variable in Cloud Build or Artifact Registry; authentication requires OAuth2 tokens or JSON key files, not a single environment variable.

Practice this question →

25

Multi-Selecthard

A team is designing a CI/CD pipeline for a microservice that requires canary deployments with metrics-based rollback. They want to use Cloud Deploy and Cloud Run. Which three features must they configure? (Choose 3)

Select 3 answers

A.Canary deployment strategy with canary percentage and metric thresholds

B.Delivery pipeline with dev, staging, and prod targets

C.Cloud Run as the deployment target

D.Binary Authorization policy

E.Manual approval gate on the prod target

AnswersA, B, C

This defines the canary rollout and rollback conditions.

Why this answer

Cloud Deploy's canary strategy requires a delivery pipeline with stages, targets using Cloud Run, and a canary deployment strategy with percentage and metrics. Approval gates are optional.

Practice this question →

26

MCQmedium

An engineer is building a CI/CD pipeline for a microservice that uses feature flags via LaunchDarkly. They want to automatically enable a new feature flag in a staging environment after deployment, but not in production. How should they integrate this into Cloud Deploy?

A.Use a Cloud Build step after deployment to call LaunchDarkly API

B.Enable the flag manually in LaunchDarkly after deployment

C.Configure a postDeploy hook in Cloud Deploy that invokes a Cloud Run Job to enable the flag

D.Use a Kubernetes ConfigMap to hold flag state, and have the app read it

AnswerC

postDeploy hooks run after a deployment succeeds, allowing environment-specific actions.

Why this answer

Option C is correct because Cloud Deploy's postDeploy hooks allow you to run a Cloud Run Job after a rollout completes, which can call the LaunchDarkly REST API to enable the flag specifically for the staging target. This integrates flag management directly into the pipeline without manual steps or exposing production flags.

Exam trap

The trap here is that candidates confuse Cloud Build steps (which run before deployment) with Cloud Deploy hooks (which run after deployment), and fail to recognize that postDeploy hooks can be scoped per environment to avoid affecting production.

How to eliminate wrong answers

Option A is wrong because a Cloud Build step runs during the build phase, not after deployment, and cannot conditionally target only staging environments; it would run for all deployments. Option B is wrong because manual flag enabling defeats the purpose of automated CI/CD and introduces human error risk, especially in staging where repeatable automation is expected. Option D is wrong because a Kubernetes ConfigMap is a static configuration mechanism that cannot dynamically toggle feature flags at runtime via LaunchDarkly, and it bypasses the flag management system entirely.

Practice this question →

27

MCQeasy

A company uses Artifact Registry to store Docker images. They want to enforce that only images signed by a trusted authority can be deployed to their GKE cluster. Which service should they use with Artifact Registry?

A.Binary Authorization

B.Identity and Access Management (IAM)

C.Container Analysis

D.Cloud Build

AnswerA

Binary Authorization ensures only signed images are deployed, integrating with Artifact Registry.

Why this answer

Binary Authorization enforces deployment-time policy based on image signatures. Container Analysis scans for vulnerabilities, not enforcements; IAM controls access; Cloud Build is the CI service.

Practice this question →

28

MCQhard

A company is deploying a microservice to Cloud Run. They need to ensure that the service can handle sudden traffic spikes without cold starts. The service has a memory requirement of 2 GB and CPU usage is bursty. What should they configure?

A.Set --min-instances to 2 and --cpu-throttling to false.

B.Set --ingress to all and --vpc-connector to a Serverless VPC Access connector.

C.Set --max-instances to 100 and --concurrency to 80.

D.Set --memory to 2Gi and --cpu to 2.

AnswerA

min-instances keeps at least 2 instances warm. Setting cpu-throttling to false ensures CPU is always available, but that's optional. The key is min-instances.

Why this answer

Option A is correct because setting --min-instances to 2 ensures that at least two container instances are always warm, eliminating cold starts during traffic spikes. Setting --cpu-throttling to false disables CPU throttling, allowing the service to use burst CPU capacity immediately without waiting for allocation, which is ideal for bursty CPU workloads.

Exam trap

Cisco often tests the distinction between resource allocation (memory/CPU) and operational settings (min-instances, CPU throttling) that directly impact cold starts and burst handling, leading candidates to mistakenly choose resource sizing options.

How to eliminate wrong answers

Option B is wrong because configuring ingress and a VPC connector addresses network access control and private connectivity, not cold starts or CPU burst handling. Option C is wrong because setting --max-instances and --concurrency controls scaling limits and request concurrency, but does not prevent cold starts or manage CPU throttling. Option D is wrong because setting --memory and --cpu defines resource allocation, but does not keep instances warm or disable CPU throttling to handle sudden spikes without cold starts.

Practice this question →

29

MCQeasy

An organization wants to store Docker images in a private Google Cloud repository with vulnerability scanning enabled. Which service should they use?

A.Container Registry

B.Cloud Build

C.Artifact Registry

D.Cloud Storage

AnswerC

Artifact Registry supports Docker repositories with integrated vulnerability scanning via Container Analysis.

Practice this question →

30

MCQeasy

An engineer wants to use Skaffold for local development and for CI/CD on Google Cloud. Which feature allows Skaffold to run on Cloud Build and deploy to GKE?

A.Skaffold dev loop

B.Skaffold init command

C.Skaffold delete command

D.Skaffold run command

AnswerD

skaffold run executes a single build-and-deploy cycle, ideal for CI/CD pipelines.

Why this answer

The `skaffold run` command is the correct answer because it performs a one-shot build and deploy, which is the exact behavior needed for CI/CD pipelines. When integrated with Cloud Build, `skaffold run` executes the entire workflow (build, test, deploy) in a non-interactive, headless mode, making it suitable for automated deployments to GKE without requiring a continuous dev loop.

Exam trap

In the Google Cloud PCDE exam, a common trap is confusing `skaffold dev` (interactive, continuous loop) with `skaffold run` (one-shot, CI/CD-ready). Candidates may incorrectly choose `skaffold dev` because it sounds like development, but it is not suitable for automated pipelines like Cloud Build.

How to eliminate wrong answers

Option A is wrong because the `skaffold dev` loop is designed for continuous local development with file watching and automatic redeployment, not for a single CI/CD pipeline execution on Cloud Build. Option B is wrong because `skaffold init` is used to generate an initial `skaffold.yaml` configuration file, not to run a deployment. Option C is wrong because `skaffold delete` is used to clean up deployed resources (e.g., deleting Kubernetes manifests), not to build and deploy.

Practice this question →

31

MCQhard

A DevOps engineer is configuring a Cloud Build pipeline that needs to deploy to a Cloud Run service in a VPC Service Controls perimeter. The build must access resources within the VPC. What should they use?

A.Configure Cloud Build to use a private pool in the same VPC

B.Use Cloud Build with a Shared VPC

C.Use Cloud Build public pool with a service account

D.Add a NAT gateway to the project

AnswerA

Private pools run inside your VPC and can access VPC-protected resources.

Why this answer

Cloud Build private pools run in your VPC, allowing access to internal resources. This is required when the build needs to interact with resources protected by VPC Service Controls.

Practice this question →

32

MCQhard

A team uses GitOps with Config Sync to manage multiple GKE clusters. They want to ensure that if a configuration change is applied to the git repository, it is automatically synced to all clusters within minutes. What must be configured?

A.Use Anthos Service Mesh to distribute configurations

B.Set the `syncWait` parameter in the Config Sync operator to 1 second

C.Configure Config Sync with a webhook from Cloud Source Repositories or GitHub to trigger re-sync

D.Set up a Cloud Build trigger that runs `gcloud container clusters update` on each cluster

AnswerC

Webhook triggers immediate sync, achieving near-real-time.

Why this answer

Option C is correct because Config Sync relies on a polling mechanism by default, which can introduce delays. Configuring a webhook from Cloud Source Repositories or GitHub triggers an immediate re-sync when changes are pushed to the repository, ensuring that configurations are applied to all GKE clusters within minutes without waiting for the next polling interval.

Exam trap

Cisco often tests the misconception that Config Sync automatically syncs changes instantly via polling, leading candidates to overlook the need for a webhook to achieve near-real-time synchronization.

How to eliminate wrong answers

Option A is wrong because Anthos Service Mesh is a service mesh platform for traffic management and observability, not a configuration distribution mechanism; it does not replace or enhance Config Sync's sync trigger. Option B is wrong because `syncWait` is not a valid parameter in Config Sync; the correct parameter for controlling sync frequency is `SYNC_REPO_SECS` or the `--sync-period` flag, and setting it to 1 second would be impractical and unsupported. Option D is wrong because `gcloud container clusters update` is used to modify cluster-level settings (e.g., add-ons, maintenance windows), not to apply Kubernetes resource configurations from a Git repository; it does not integrate with Config Sync's reconciliation loop.

Practice this question →

33

MCQmedium

A company uses Cloud Run and wants to deploy a new revision that initially receives 5% of traffic, and only if it's healthy, gradually increase to 100%. Which gcloud command should they use?

A.gcloud run deploy --image ... --canary-percent=5

B.gcloud run deploy --image ... --traffic=5

C.gcloud run deploy --image ... --to-revisions=REVISION_1=95,REVISION_2=5

D.gcloud run deploy --image ... --min-instances=1 --max-instances=10

AnswerC

Correct: uses `--to-revisions` to split traffic.

Why this answer

Option C is correct because the `gcloud run deploy` command with the `--to-revisions` flag allows you to specify the exact traffic split between existing revisions and the new revision. By setting `REVISION_1=95,REVISION_2=5`, the new revision (REVISION_2) initially receives 5% of traffic, and Cloud Run's built-in gradual rollout mechanism will automatically increase its traffic share to 100% only if it remains healthy, based on the configured health checks.

Exam trap

The trap here is that candidates confuse the `--traffic` flag (which sets the overall traffic percentage for the service, not per-revision) with the `--to-revisions` flag (which is the correct way to specify per-revision traffic splits for canary deployments). Additionally, note that the command only sets the initial traffic split; the gradual increase to 100% must be managed separately by updating the traffic configuration over time.

How to eliminate wrong answers

Option A is wrong because `--canary-percent` is not a valid flag for `gcloud run deploy`; Cloud Run does not support a direct canary percentage parameter in the deploy command. Option B is wrong because `--traffic=5` would set the entire service's traffic to 5% of the original, not allocate 5% to a new revision, and it does not support gradual rollout. Option D is wrong because `--min-instances` and `--max-instances` control instance scaling, not traffic routing or canary deployment, and have no effect on traffic allocation.

Practice this question →

34

MCQmedium

An engineer needs to build a Docker image using Cloud Build and ensure the image is cached across builds to speed up subsequent runs. The build uses Kaniko. What should the engineer add to the cloudbuild.yaml to enable layer caching?

A.Use the 'kaniko' builder and set '--cache=true' and '--cache-repo'

B.Configure a build pool with a persistent disk for caching

C.Add step using 'docker build' with '--cache-from'

D.Set the 'images' field in cloudbuild.yaml to enable automatic caching

AnswerA

Kaniko supports caching via --cache=true and --cache-repo to specify where cached layers are stored in Artifact Registry or Container Registry.

Why this answer

Cloud Build with Kaniko supports caching by specifying a destination for cached layers. The --cache=true flag enables caching, and --cache-repo sets the repository where cached layers are stored. --destination is used for the final image but not for cache configuration alone.

Practice this question →

35

MCQmedium

A team uses Cloud Build to build a container image using Kaniko. They want to cache layers to speed up subsequent builds. What should they configure in their cloudbuild.yaml to enable Kaniko layer caching?

A.Use Docker layer caching with docker build --cache-from

B.Set substitution variable _KANIKO_CACHE=true

C.Enable Cloud Build cache via the caching service

D.Set --cache=true and specify --cache-repo in the Kaniko builder step

AnswerD

Kaniko caching is enabled by passing --cache=true and --cache-repo to point to a remote repository.

Why this answer

Kaniko does not rely on Docker's layer caching mechanism. Instead, it uses its own remote caching system where layers are pushed to a container registry. To enable this, you must pass `--cache=true` to the Kaniko builder to instruct it to cache intermediate layers, and `--cache-repo` to specify the target repository (e.g., a registry path) where those cached layers will be stored.

This allows subsequent builds to reuse previously built layers, significantly reducing build time.

Exam trap

The trap here is that candidates confuse Cloud Build's generic caching service (which caches build artifacts like Maven dependencies) with Kaniko's specific layer caching mechanism, leading them to select Option C, or they mistakenly assume Docker's `--cache-from` works with Kaniko (Option A), not realizing Kaniko is a daemonless builder.

How to eliminate wrong answers

Option A is wrong because `docker build --cache-from` is a Docker-specific caching mechanism that relies on the Docker daemon, which Kaniko does not use; Kaniko runs entirely in userspace without a Docker daemon. Option B is wrong because `_KANIKO_CACHE` is not a recognized substitution variable in Cloud Build; Kaniko caching is controlled via builder arguments (`--cache`), not environment variables or substitutions. Option C is wrong because Cloud Build's caching service is designed for storing build artifacts (e.g., Maven/Gradle dependencies) and is not integrated with Kaniko's layer caching; Kaniko requires its own `--cache-repo` to store layers in a container registry.

Practice this question →

36

MCQmedium

A company uses Cloud Build to deploy to Cloud Run. They want to use a custom service account for the deployment step, not the default Cloud Build service account. How should they configure this?

A.Set the service account in the build trigger's service account field

B.Specify 'serviceAccount' in the step definition in cloudbuild.yaml

C.Use 'gcloud config set account' in the step's entrypoint

D.Use 'impersonate-service-account' flag in gcloud commands

AnswerB

The step-level serviceAccount field allows using a specific service account for that step.

Why this answer

In cloudbuild.yaml, you can specify a service account for each step using the 'serviceAccount' field. This overrides the default build service account for that step.

Practice this question →

37

MCQmedium

A team is using Helm charts to deploy to GKE. They want to manage environment-specific values (dev, staging, prod) while keeping a single chart. Which approach is recommended?

A.Use --values flags with environment-specific value files

B.Store all environment values in a single values.yaml and use --set to override

C.Use Kustomize overlays to manage Helm values

D.Create separate Helm charts for each environment

AnswerA

This is the standard Helm pattern: default values.yaml plus environment overrides.

Why this answer

Helm supports multiple values files; you can use --values to specify environment-specific files, overriding default values. This keeps one chart and separate configs.

Practice this question →

38

MCQmedium

A team uses Cloud Deploy with a delivery pipeline that has dev, staging, and prod targets. They want to automatically deploy to staging after a successful deployment to dev, but require manual approval before promoting to prod. How should they configure this?

A.Set the prod target to require approval in Cloud Deploy

B.Create a Cloud Build trigger that runs after dev promotion

C.Configure Cloud Deploy with a canary strategy for prod

D.Use a scheduled Cloud Build to check dev status and then deploy to staging

AnswerA

Approval gate on prod target blocks promotion until manually approved.

Why this answer

Option A is correct because Cloud Deploy supports a 'require approval' setting on delivery pipeline targets. By enabling this on the prod target, the pipeline will automatically promote from dev to staging (since no approval is required there) but will pause before promoting to prod, waiting for a manual approval action in the Cloud Deploy console or via the API.

Exam trap

Cisco often tests the distinction between deployment strategies (canary, blue/green) and pipeline approval gates, causing candidates to confuse a canary strategy with a manual approval requirement.

How to eliminate wrong answers

Option B is wrong because creating a Cloud Build trigger that runs after dev promotion adds unnecessary complexity and bypasses the built-in promotion mechanism of Cloud Deploy, which already handles sequential target promotions automatically. Option C is wrong because a canary strategy controls how traffic is shifted during a deployment (e.g., percentage-based rollout), not whether a promotion requires manual approval; approval is a separate pipeline gate. Option D is wrong because using a scheduled Cloud Build to check dev status and then deploy to staging is an anti-pattern—Cloud Deploy already provides automatic promotion between targets without requiring external polling or scheduling.

Practice this question →

39

MCQmedium

A team is using Cloud Build to build Docker images and push them to Artifact Registry. They want to speed up builds by caching the Docker layers. Which approach is recommended for caching in Cloud Build?

A.Configure Cloud Build to use Kaniko cache with a destination in Artifact Registry

B.Use Google Cloud Storage as a layer cache for Docker builds

C.Use 'gcloud builds submit --cache-from' with a local cache

D.Set up a Docker registry proxy in Compute Engine to cache images

AnswerA

Kaniko with --cache=true and --cache-repo stores layers in Artifact Registry for reuse.

Why this answer

Cloud Build supports Kaniko caching for Docker images. Kaniko can cache layers in a registry, significantly reducing build times by reusing cached layers when the Dockerfile hasn't changed.

Practice this question →

40

MCQhard

A company uses Cloud Build with GitHub triggers. The build pipeline runs tests, builds a Docker image, and pushes it to Artifact Registry. Recently, builds started failing with '403 Forbidden' when pushing to Artifact Registry. The Cloud Build service account has the Artifact Registry Writer role. What else could be causing the failure?

A.The Docker credential helper is not configured in the build step.

B.The repository is in a different region than the Cloud Build worker.

C.The Cloud Build service account does not have the 'iam.serviceAccountUser' role on the Compute Engine default service account.

D.The Artifact Registry API is not enabled in the project.

AnswerD

The API must be enabled for any API calls to succeed.

Why this answer

Option D is correct because if the Artifact Registry API is not enabled for the project, any attempt to push a Docker image to Artifact Registry will fail with a 403 Forbidden error, regardless of the service account's IAM roles. The Cloud Build service account may have the Artifact Registry Writer role, but without the underlying API enabled, the service cannot interact with the Artifact Registry service at all. Enabling the `artifactregistry.googleapis.com` API is a prerequisite for any API calls to succeed.

Exam trap

Google Cloud often tests the distinction between IAM roles and API enablement, trapping candidates who assume that granting a role automatically enables the underlying service API.

How to eliminate wrong answers

Option A is wrong because the Docker credential helper (e.g., `gcloud auth configure-docker`) is automatically configured by Cloud Build when using the default builder images or the `docker` step with the `-c` flag; a missing credential helper would cause authentication failures (e.g., 'denied: Unauthenticated'), not a 403 Forbidden. Option B is wrong because Cloud Build workers can push to Artifact Registry repositories in any region; cross-region pushes are supported and do not cause 403 errors—only latency or egress costs may differ. Option C is wrong because the `iam.serviceAccountUser` role is required only when Cloud Build needs to impersonate a user-managed service account (e.g., to deploy to Compute Engine); pushing to Artifact Registry does not require impersonation, and the Cloud Build service account already has direct permissions via the Artifact Registry Writer role.

Practice this question →

41

MCQmedium

A company uses Helm charts to manage Kubernetes deployments. They want to integrate Skaffold into their CI/CD pipeline for local development and continuous deployment to GKE. Which Skaffold feature is MOST relevant for applying environment-specific configurations?

A.skaffold run with --profile flag

B.Skaffold's built-in Kustomize renderer

C.Helm charts with values files per environment

D.Skaffold's artifact dependency graph

AnswerB

Kustomize overlays modify base YAMLs for each environment, perfect for environment-specific configs.

Why this answer

Option B is correct because Skaffold's built-in Kustomize renderer allows you to apply environment-specific overlays and patches directly within the Skaffold pipeline, enabling declarative configuration management without modifying the underlying Helm charts. This is the most relevant feature for applying environment-specific configurations when using Helm charts, as Kustomize can override Helm-generated manifests with environment-specific patches, such as different replica counts or resource limits, without requiring separate Helm values files per environment.

Exam trap

Cisco often tests the distinction between Skaffold-native features and external tool integrations; the trap here is that candidates may choose Helm values files (Option C) because they are familiar with environment-specific configurations in Helm, but the question explicitly asks for a Skaffold feature, and the Kustomize renderer is the Skaffold-native mechanism for applying such configurations within the Skaffold pipeline.

How to eliminate wrong answers

Option A is wrong because the `--profile` flag in `skaffold run` is used to select a predefined set of configuration overrides within the skaffold.yaml file, not to apply environment-specific configurations to Helm charts; it is a Skaffold-level feature that controls which pipeline steps run, not a mechanism for customizing Kubernetes manifests per environment. Option C is wrong because while Helm charts with values files per environment are a valid approach for environment-specific configurations, the question specifically asks for a Skaffold feature, and using Helm values files is a Helm-native capability, not a Skaffold feature; Skaffold can pass values files, but the feature most relevant for applying environment-specific configurations within Skaffold is its Kustomize renderer. Option D is wrong because Skaffold's artifact dependency graph is used to determine the build and deploy order of artifacts based on their dependencies, not for applying environment-specific configurations; it optimizes the pipeline execution but does not modify Kubernetes manifests.

Practice this question →

42

Multi-Selecteasy

An organization wants to use Cloud Build to automatically build and test code changes when a developer pushes to any branch in a Cloud Source Repositories repository. Which two configurations are needed?

Select 2 answers

A.A pull request trigger

B.A cloudbuild.yaml file in the repository

C.A scheduled trigger with cron

D.A manual trigger with webhook

E.A push trigger with a branch regex of '.*'

AnswersB, E

Cloud Build requires a build configuration file to define the steps.

Why this answer

A push trigger monitors branch pushes. To capture all branches, the trigger should use a regex pattern like '.*'. Additionally, the cloudbuild.yaml file must be present in the repository to define the build steps.

Practice this question →

43

Multi-Selectmedium

A team uses Helm charts to deploy applications to GKE. They want to use Kustomize to manage environment-specific overlays for different clusters. Which two tools or approaches can they combine to achieve this?

Select 2 answers

A.Use Skaffold to run Helm and Kustomize in sequence

B.Use Config Sync to apply Kustomize overlays directly

C.Use 'kubectl apply -k' to apply Helm charts without overlays

D.Use Kustomize's 'helmCharts' plugin to render Helm charts and apply overlays

E.Use Cloud Build's built-in Helm support only

AnswersA, D

Skaffold can run a Helm deploy and then a Kustomize deploy, or vice versa, in a CI/CD pipeline.

Why this answer

Option A is correct because Skaffold can orchestrate both Helm and Kustomize in a single pipeline, allowing you to first render Helm charts and then apply Kustomize overlays for environment-specific customizations. Option D is correct because Kustomize's 'helmCharts' plugin can directly render Helm charts and apply overlays in one step, providing an alternative approach. Both methods enable combining Helm's templating with Kustomize's overlays.

Exam trap

A common trap is assuming that Kustomize cannot work with Helm charts. The 'helmCharts' plugin (Option D) is a valid, though experimental, feature that allows direct integration. Additionally, candidates may overlook Skaffold's orchestration capability (Option A) as a stable alternative.

Practice this question →

44

Multi-Selecthard

Which TWO actions should be taken to enable layer caching for Docker builds using Kaniko in Cloud Build? (Choose two.)

Select 2 answers

A.Add `--cache-repo` specifying an Artifact Registry repository

B.Use the `docker` builder instead of Kaniko

C.Set the `CACHE_LAYERS` substitution variable

D.Add `--cache=true` to the Kaniko builder arguments

E.Enable Cloud Build's built-in caching by adding `cache: true`

AnswersA, D

Specifies where to store cache layers.

Why this answer

Option A is correct because Kaniko requires the `--cache-repo` flag to specify an Artifact Registry repository where cached layers will be stored and retrieved. This enables layer caching across builds, reducing build time by reusing unchanged layers. Without this flag, Kaniko does not know where to push or pull cached layers from.

Exam trap

A common pitfall is confusing Cloud Build's built-in caching (which caches the final image) with Kaniko's layer caching (which caches intermediate layers). Candidates may incorrectly select `cache: true` thinking it enables layer caching, but that is not how Kaniko works.

Practice this question →

45

MCQmedium

An engineer is configuring a Cloud Build trigger for a Java application. The build step uses Maven to compile and test, then builds a Docker image. Which cloudbuild.yaml step configuration is CORRECT for specifying the Maven command?

A.steps: - name: 'maven:3' args: ['mvn', 'clean', 'package']

B.steps: - name: 'maven:3' entrypoint: 'bash' args: ['mvn', 'clean', 'package']

C.steps: - name: 'maven:3' script: 'mvn clean package'

D.steps: - name: 'maven:3' entrypoint: 'mvn' args: ['clean', 'package']

AnswerA

Correct: 'name' sets the image, 'args' passes the command and its arguments.

Why this answer

Option A is correct because Cloud Build expects the `args` field to contain the command and its arguments when the default entrypoint of the container image is used. The `maven:3` image has `mvn` as its default entrypoint, so specifying `args: ['mvn', 'clean', 'package']` correctly invokes Maven to compile, test, and package the Java application.

Exam trap

Cisco often tests the distinction between the default entrypoint of a container image and the need to include the command in `args` when overriding the entrypoint, leading candidates to incorrectly select Option D because they think explicitly setting `entrypoint: 'mvn'` is required.

How to eliminate wrong answers

Option B is wrong because it overrides the default entrypoint with `bash`, which would interpret `args: ['mvn', 'clean', 'package']` as a command to run a script named `mvn` rather than the Maven binary, causing a failure. Option C is wrong because the `script` field is not a valid field in `cloudbuild.yaml`; Cloud Build uses `args` or `entrypoint` with `args` to specify commands. Option D is wrong because it redundantly sets `entrypoint: 'mvn'` when the image already uses `mvn` as the default entrypoint, and the `args` array omits the `mvn` command itself, resulting in only `['clean', 'package']` being passed as arguments to `mvn`, which would fail as `mvn clean package` expects the `mvn` binary to be invoked first.

Practice this question →

46

MCQmedium

An engineer is configuring a cloudbuild.yaml file. They want two build steps (unit tests and linting) to run simultaneously, and after both complete, a third step (package) should run. How should they configure waitFor in the package step?

A.Set waitFor: ['-'] on the unit tests and linting steps, and waitFor: ['unit-tests', 'linting'] on the package step.

B.Do not set waitFor on any step.

C.Set waitFor: ['-'] on the package step.

D.Set waitFor: ['unit-tests', 'linting'] on all three steps.

AnswerA

This correctly runs unit tests and linting in parallel, then package after both complete.

Why this answer

Option A is correct because in Cloud Build, steps run sequentially by default. To run unit tests and linting in parallel, you set `waitFor: ['-']` on each of those steps, which tells Cloud Build they have no dependencies and can start immediately. Then, setting `waitFor: ['unit-tests', 'linting']` on the package step ensures it only runs after both parallel steps have completed successfully.

Exam trap

Cisco often tests the misconception that `waitFor: ['-']` is used to make a step wait for nothing, but candidates confuse it with making a step wait for all previous steps, or they think omitting `waitFor` enables parallelism.

How to eliminate wrong answers

Option B is wrong because if you do not set `waitFor` on any step, all steps will run sequentially in the order they are defined, not in parallel. Option C is wrong because setting `waitFor: ['-']` on the package step would cause it to start immediately, without waiting for the unit tests and linting steps to finish. Option D is wrong because setting `waitFor: ['unit-tests', 'linting']` on all three steps would create a circular dependency (each step waiting for the other two), causing the build to hang or fail.

Practice this question →

47

MCQhard

An organization uses Binary Authorization with Container Analysis to enforce that only images that have passed vulnerability scanning and have been signed by an approved authority can be deployed to GKE. A DevOps engineer notices that an unsigned image is still being deployed. What is the most likely cause?

A.The Build service account does not have the signer role.

B.The image is stored in a different project than the one where Binary Authorization is configured.

C.The Container Analysis API is not enabled in the project.

D.The Binary Authorization admission controller is not enabled on the GKE cluster.

AnswerD

Without the admission controller, the BinAuthz policy is not enforced.

Why this answer

Option D is correct because Binary Authorization enforcement requires the admission controller to be enabled on the GKE cluster. Without the admission controller, the cluster will not intercept pod creation requests to verify image attestations, so unsigned images can be deployed regardless of the Binary Authorization policy configuration.

Exam trap

Cisco often tests the misconception that configuring a Binary Authorization policy alone is sufficient, when in fact the admission controller must be enabled on the GKE cluster for enforcement to take effect.

How to eliminate wrong answers

Option A is wrong because the Build service account lacking the signer role would prevent images from being signed, but it does not cause an unsigned image to bypass enforcement—the admission controller would still block it. Option B is wrong because Binary Authorization policies can be applied across projects using the same Container Analysis notes and attestors; storing the image in a different project does not inherently bypass enforcement. Option C is wrong because the Container Analysis API must be enabled for vulnerability scanning and attestation storage, but its absence would cause scanning or attestation failures, not allow unsigned images to be deployed if the admission controller is active.

Practice this question →

48

MCQmedium

A developer wants to use Cloud Build to deploy a container to Cloud Run. They have written a cloudbuild.yaml file with a step that runs gcloud run deploy. The build fails with a permission error. What is the most likely cause?

A.The gcloud command is incorrect

B.The Cloud Build trigger is misconfigured

C.The Cloud Run API is not enabled in the project

D.The Cloud Build service account does not have the Cloud Run Admin role

AnswerD

Cloud Build uses a service account to perform actions; it needs roles/run.admin to deploy to Cloud Run.

Practice this question →

49

MCQmedium

A company uses Cloud Build to build Docker images. They want to cache intermediate layers to speed up subsequent builds. The build runs on a private pool with access to Artifact Registry. Which caching approach should they use?

A.Use Google Cloud Build's built-in image optimization feature.

B.Enable Cloud Build's automatic caching by setting cache: true in cloudbuild.yaml.

C.Configure Docker cache import/export steps in cloudbuild.yaml.

D.Use Kaniko with the --cache-repo flag pointing to an Artifact Registry repository.

AnswerD

Kaniko's layer caching with --cache-repo stores cache in a remote registry, which is the recommended approach.

Why this answer

Kaniko is the recommended tool for building Docker images in Cloud Build when using private pools, as it does not require a Docker daemon and supports layer caching via the `--cache-repo` flag. By pointing this flag to an Artifact Registry repository, Kaniko can push and pull cached intermediate layers, significantly speeding up subsequent builds. This approach works seamlessly with private pools and Artifact Registry, unlike the other options which are either invalid or not supported.

Exam trap

The trap here is that candidates assume Cloud Build has a simple built-in caching toggle (like `cache: true`) or that Docker's native cache-from/cache-to is directly usable in Cloud Build, when in reality Kaniko is the standard solution for caching in daemonless environments like private pools.

How to eliminate wrong answers

Option A is wrong because Cloud Build does not have a built-in 'image optimization feature' that caches intermediate layers; this is a generic term not tied to any actual Cloud Build capability. Option B is wrong because `cache: true` is not a valid field in `cloudbuild.yaml`; Cloud Build does not support an automatic caching flag of that nature. Option C is wrong because Docker cache import/export steps (e.g., `--cache-from` and `--cache-to`) require a Docker daemon, which is not available in Cloud Build's default execution environment, especially on private pools, and they are not natively supported as build steps without custom scripting.

Practice this question →

50

MCQmedium

A company wants to enforce that only container images signed by their CI/CD pipeline can be deployed to GKE. Which two services should they use together?

A.Binary Authorization and Container Analysis

B.Cloud Build and Artifact Registry

C.Security Command Center and Artifact Registry

D.Cloud Deploy and Cloud Run

AnswerA

Binary Authorization enforces policies, Container Analysis stores attestations.

Why this answer

Binary Authorization enforces that only container images signed by trusted authorities (like a CI/CD pipeline) can be deployed to GKE. Container Analysis (now part of Artifact Analysis) scans images for vulnerabilities and stores attestations, which Binary Authorization uses to verify signatures before allowing deployment. Together, they provide a complete enforcement chain: signing during CI/CD and verification at deploy time.

Exam trap

Cisco often tests the misconception that image storage (Artifact Registry) or build automation (Cloud Build) alone can enforce deployment security, when in fact a separate attestation and admission control service (Binary Authorization) is required.

How to eliminate wrong answers

Option B is wrong because Cloud Build and Artifact Registry handle building and storing images, but neither enforces deployment policies based on image signatures; they lack the attestation verification component. Option C is wrong because Security Command Center provides threat detection and compliance monitoring, not image signing or deployment enforcement; Artifact Registry stores images but does not verify signatures at deploy time. Option D is wrong because Cloud Deploy is a continuous delivery service for GKE and Cloud Run, but it does not natively enforce image signing; Cloud Run is a serverless compute platform, not a signing or attestation service.

Practice this question →

51

MCQhard

A company uses Cloud Build to deploy to Cloud Run. They need to test a new revision with a specific tag without serving any live traffic. After validation, they want to shift 10% of traffic to the new revision. Which two gcloud commands should they use?

A.gcloud run deploy --image ... --no-traffic --tag=test; gcloud run services update-traffic ... --to-revisions=test=10

B.gcloud run deploy --image ... --no-traffic; gcloud run services update-traffic ... --to-latest=10

C.gcloud run deploy --image ... --traffic=10%; gcloud run revisions delete

D.gcloud run deploy --image ... --tag=test; gcloud run services update-traffic ... --to-revisions=test=100

AnswerA

Correct sequence: deploy without traffic and tag, then update traffic split.

Why this answer

Option A is correct because the `--no-traffic` flag deploys the new revision without routing any live traffic to it, while `--tag=test` assigns a specific tag (e.g., 'test') that allows direct URL-based validation. The second command `gcloud run services update-traffic --to-revisions=test=10` then shifts exactly 10% of traffic to that tagged revision, enabling a gradual rollout. This two-step approach ensures the revision is validated before receiving production traffic.

Exam trap

Cisco often tests the distinction between deploying with `--no-traffic` (zero traffic) versus `--traffic=X%` (immediate traffic), and the requirement to use `--tag` for URL-based validation before traffic shifting.

How to eliminate wrong answers

Option B is wrong because `--to-latest=10` is not a valid syntax; `--to-latest` expects a percentage but it would route traffic to the latest deployed revision (which might not be the tagged one) and does not use a tag for validation. Option C is wrong because `--traffic=10%` deploys the revision and immediately sends 10% of traffic to it, bypassing the requirement to test without any live traffic first; `gcloud run revisions delete` is unrelated and would remove revisions, not shift traffic. Option D is wrong because `--to-revisions=test=100` sends 100% of traffic to the tagged revision, not the required 10% shift.

Practice this question →

52

Multi-Selecthard

A company wants to implement Binary Authorization for containers deployed to GKE. They need to ensure that only images signed by their internal CI system are allowed to run. Which three components are required?

Select 3 answers

A.An attestor in Binary Authorization

B.Image signing using a private key

C.Cloud Build with privilege escalation mode

D.Binary Authorization policy configured to require attestations

E.Container Registry with vulnerability scanning enabled

AnswersA, B, D

The attestor verifies the signature and creates an attestation that the policy uses.

Why this answer

Binary Authorization requires images to be signed (e.g., using Cloud Key Management Service or Signify), an attestor that verifies signatures, and an admission controller (Binary Authorization) that enforces the policy on the cluster.

Practice this question →

53

Multi-Selecthard

A team uses Cloud Build to build and deploy a Go application to GKE. They need to inject the Git commit SHA as an environment variable in the deployment. Which THREE steps should they take?

Select 3 answers

A.Grant the Cloud Build service account permission to update the Deployment

B.Use Cloud Deploy instead of kubectl

C.Run kubectl set env deployment/myapp COMMIT_SHA=$SHORT_SHA after the image is deployed

D.Create a new Docker image tag with the commit SHA

E.Use the built-in substitution $SHORT_SHA in a cloudbuild.yaml step

AnswersA, C, E

Needed to run kubectl set env or patch.

Why this answer

Option A is correct because the Cloud Build service account needs the `container.deployments.update` permission (or a role like `roles/container.developer`) to modify the Deployment object in GKE. Without this IAM permission, the `kubectl set env` command in the build step will fail with a forbidden error, even if the image was successfully deployed.

Exam trap

Cisco often tests the misconception that you must rebuild and retag the Docker image to pass the commit SHA, when in fact you can inject it at deployment time using `kubectl set env` without modifying the image.

Practice this question →

54

MCQmedium

A company uses Cloud Deploy to manage deployments to GKE. They want to automatically roll back a release if a deployment fails. How should they configure this?

A.Set up a Cloud Monitoring alert that triggers a rollback via Cloud Functions

B.Configure a postDeploy hook that checks deployment status and triggers a rollback

C.Set the 'rollback-policy' in the delivery pipeline YAML

D.Use the --auto-rollback flag in the gcloud deploy release command

AnswerB

PostDeploy hooks in Cloud Deploy can run scripts that verify deployment status and initiate a rollback if needed.

Practice this question →

55

MCQhard

A team uses Cloud Deploy with a delivery pipeline that has multiple targets (dev, staging, prod). They want to automatically roll back to the previous release if the new release fails a post-deployment health check. Which configuration should they use?

A.Configure a postDeploy hook that runs a health check and uses 'gcloud deploy releases rollback' if it fails

B.Set 'rollbackOnFailure: true' in the pipeline definition

C.Use a canary deployment with metric analysis to trigger rollback

D.Enable 'auto-rollback' in the target configuration

AnswerA

PostDeploy hooks can run arbitrary Cloud Run jobs; a script can check health and initiate rollback via the API.

Why this answer

Option A is correct because Cloud Deploy does not have a built-in 'rollbackOnFailure' or 'auto-rollback' property for post-deployment health checks. Instead, you must implement a custom postDeploy hook that runs a health check script; if the health check fails, the script can invoke 'gcloud deploy releases rollback' to programmatically trigger a rollback to the previous release. This gives you full control over the rollback logic and conditions.

Exam trap

The trap here is that candidates assume Cloud Deploy has a built-in 'rollbackOnFailure' or 'auto-rollback' property similar to other CI/CD tools, but Cloud Deploy requires explicit custom logic via postDeploy hooks for health check-driven rollbacks.

How to eliminate wrong answers

Option B is wrong because 'rollbackOnFailure: true' is not a valid property in Cloud Deploy's pipeline definition; Cloud Deploy does not support an automatic rollback flag for post-deployment failures. Option C is wrong because canary deployments with metric analysis are used for progressive delivery and automated promotion/rollback based on metrics, but they are not the mechanism for a simple post-deployment health check rollback; the question specifically asks for a post-deployment health check, not a canary strategy. Option D is wrong because 'auto-rollback' is not a configurable setting in Cloud Deploy's target configuration; Cloud Deploy targets do not have a built-in auto-rollback property for health checks.

Practice this question →

56

Multi-Selectmedium

An organization wants to implement feature flags to gradually roll out new features in production. Which TWO approaches can they use on Google Cloud?

Select 2 answers

A.Store feature flags in Cloud Storage and have the application poll for changes

B.Use Cloud Build substitutions to inject feature flags at build time

C.Use Cloud Run traffic splitting to route users to different application versions

D.Integrate a third-party feature flag service like LaunchDarkly into the application

E.Use Cloud Functions to toggle feature flags via HTTP calls

AnswersC, D

Traffic splitting can be used to gradually expose new features by directing user segments to different revisions.

Why this answer

Option C is correct because Cloud Run's traffic splitting feature allows you to gradually route a percentage of traffic to a new revision of a service, enabling canary deployments or gradual rollouts of new features without requiring code changes or external services. This is a native Google Cloud approach that leverages the underlying Knative serving layer to manage traffic routing at the request level.

Exam trap

The trap here is that candidates may confuse build-time injection (Option B) with runtime feature toggles, or think that polling Cloud Storage (Option A) is a valid pattern for real-time flag updates, when in fact Google Cloud's native traffic splitting or a dedicated feature flag service is required for gradual rollouts.

Practice this question →

57

MCQhard

An organization is implementing GitOps using Config Sync. They have a Git repository containing Kubernetes manifests for multiple GKE clusters. They want to ensure that only authorized engineers can modify the configuration and that changes are automatically applied to clusters. What is the recommended way to secure Config Sync?

A.Store the Git repository in Cloud Source Repositories and use IAM to control access. Use branch protection rules to require pull request approvals before merging to the main branch.

B.Use a public Git repository and rely on Kubernetes RBAC to control who can modify Config Sync objects.

C.Use a separate Git repository for each cluster and restrict access via SSH keys.

D.Encrypt the Kubernetes secrets in the repo and use a KMS key to decrypt them in the cluster.

AnswerA

IAM controls who can access the repo. Branch protection ensures only reviewed changes are merged. Config Sync automatically applies the main branch.

Why this answer

Config Sync uses a Git repo. The best practice is to use a private repo and grant least-privilege access. To prevent unauthorized changes, enforce branch protection rules (e.g., require PR approvals) and use a service account with read-only access to the repo.

Config Sync's reconciler runs in the cluster with read-only permissions.

Practice this question →

58

MCQeasy

A company wants to deploy a containerized application to Cloud Run and gradually shift traffic from the current revision to a new revision. They want to send 10% of traffic to the new revision initially. Which command should they use?

A.gcloud run revisions update-traffic ... --to-revisions=NEW=10

B.gcloud run deploy --image ... --to-revisions=NEW=10

C.gcloud run deploy --image ... --no-traffic; then gcloud run services update-traffic ... --to-revisions=NEW=10,OLD=90

D.gcloud run deploy --image ... --traffic=10

AnswerC

This two-step approach first deploys without traffic, then adjusts traffic percentages.

Why this answer

Option C is correct because it first deploys the new revision without any traffic using `--no-traffic`, then uses `gcloud run services update-traffic` to explicitly set 10% traffic to the new revision and 90% to the old revision. This two-step approach is required when you want to gradually shift traffic to a new revision without immediately serving any traffic to it, as Cloud Run does not support setting a specific traffic percentage directly in the `gcloud run deploy` command.

Exam trap

The trap here is that candidates assume `gcloud run deploy` can directly set a traffic percentage via a `--traffic` or `--to-revisions` flag, but Cloud Run requires a separate traffic update command after a no-traffic deployment to achieve gradual traffic shifting.

How to eliminate wrong answers

Option A is wrong because `gcloud run revisions update-traffic` operates on a specific revision, not on a service, and the `--to-revisions` flag is not valid for that command; it should be `--to-revisions=NEW=10` but the command itself is incorrect. Option B is wrong because `gcloud run deploy` does not accept a `--to-revisions` flag; it deploys a new revision and by default sends 100% of traffic to it unless `--no-traffic` is used. Option D is wrong because `gcloud run deploy --traffic=10` is invalid; the `--traffic` flag is not supported in `gcloud run deploy` and would cause a syntax error.

Practice this question →

59

Multi-Selectmedium

A company is adopting GitOps for their GKE clusters using Config Sync. They need to meet the following requirements: (1) automatically sync the cluster state to a Git repository every 5 minutes, (2) ensure that any changes made directly to the cluster are reverted to the desired state defined in Git. Which Config Sync settings should they configure? (Choose TWO).

Select 2 answers

A.Set spec.driftManagement to false.

B.Set spec.sync to '5m' in the RootSync or RepoSync object.

C.Set spec.override to true.

D.Enable drift management by setting spec.driftManagement to true.

E.Set spec.syncInterval to '5m' in the RootSync or RepoSync object.

AnswersB, D

This sets the sync interval to every 5 minutes.

Why this answer

Option B is correct because `spec.sync` in a RootSync or RepoSync object defines the sync interval for Config Sync. Setting it to `'5m'` ensures the cluster state is automatically reconciled against the Git repository every 5 minutes. Option D is correct because enabling drift management (`spec.driftManagement: true`) ensures that any manual changes made directly to the cluster are detected and reverted to the desired state defined in Git, meeting the second requirement.

Exam trap

The trap here is confusing the `spec.sync` field (which sets the sync interval) with the non-existent `spec.syncInterval` field, and assuming that `spec.driftManagement` is disabled by default or that setting it to `false` would meet the requirements.

Practice this question →

60

MCQmedium

A team uses Cloud Deploy to manage deployments to multiple GKE clusters in different environments. They need to ensure that only a specific service account can promote releases to the production target. What should they configure?

A.Grant the service account the 'roles/clouddeploy.releaser' role on the production target

B.Restrict the service account's permissions via a VPC Service Controls perimeter

C.Grant the service account the 'roles/clouddeploy.operator' role on the delivery pipeline

D.Use a manual approval gate for the production stage

AnswerA

The releaser role on a target allows promoting releases to that target, and can be scoped per target.

Why this answer

Cloud Deploy uses IAM roles on targets to control who can promote. By granting the roles/clouddeploy.releaser role to the service account on the production target, only that account can promote releases to that target.

Practice this question →

61

Multi-Selectmedium

A company uses Cloud Deploy for a CD pipeline to Cloud Run. They want to implement a canary deployment that automatically rolls back if the error rate increases by more than 5% during the canary phase. Which TWO actions should they take?

Select 2 answers

A.Use a blue/green strategy instead, as it supports automatic rollback

B.Configure a canary deployment strategy in the delivery pipeline with phases and metrics

C.Delegate rollback to the developer who must manually approve or reject

D.Create a Cloud Monitoring alert policy that triggers a Cloud Deploy rollback via a webhook

E.Set up a preDeploy hook to run a load test

AnswersB, D

This sets up the canary with metric thresholds.

Why this answer

Option B is correct because Cloud Deploy's canary strategy allows you to define phases with specific metrics (e.g., error rate) that are evaluated during the rollout. If the error rate exceeds the defined threshold (e.g., 5% increase), Cloud Deploy automatically rolls back the canary without manual intervention. This is configured in the delivery pipeline YAML under the `strategy` section with `canary` and `phases`.

Exam trap

Cisco often tests the misconception that blue/green strategies support automatic rollback based on metrics, but in Cloud Deploy, canary strategies are the only ones that natively integrate with Cloud Monitoring for automated rollback decisions.

Practice this question →

62

MCQmedium

A team uses Cloud Build to build a Docker image and push it to Artifact Registry. They need to cache Docker layers to speed up subsequent builds. The build runs on a private pool with access to a VPC. Which caching approach should they implement in cloudbuild.yaml?

A.Build images with --no-cache flag to ensure consistency

B.Docker cache import/export with a GCS bucket

C.Use BuildKit with inline cache

D.Kaniko layer caching with cache repository in Artifact Registry

AnswerD

Kaniko supports --cache-repo to cache layers in Artifact Registry, which is efficient and works with Cloud Build.

Why this answer

Kaniko layer caching with a cache repository in Artifact Registry is the recommended method for Cloud Build. It stores intermediate layers and reuses them when unchanged. Docker cache import/export requires a persistent volume, which is not native to Cloud Build.

Practice this question →

63

MCQmedium

A team uses Cloud Build with a cloudbuild.yaml that builds a Docker image. They want to speed up builds by caching the Docker layers using Kaniko cache in Artifact Registry. Which configuration change is required?

A.Add a step that runs 'docker build --cache-from' pointing to an Artifact Registry repo

B.Enable Cloud Build's built-in cache feature in the build configuration

C.Add a 'docker push' step after build to store layers in Artifact Registry

D.Use the '--cache' and '--cache-repo' flags in the kaniko builder step

AnswerD

Kaniko's --cache and --cache-repo flags enable layer caching to a remote repository.

Why this answer

Kaniko supports caching layers to a remote repository. In cloudbuild.yaml, the step using kaniko should set --cache=true and specify the --cache-repo pointing to an Artifact Registry Docker repository.

Practice this question →

64

MCQmedium

An organization uses Cloud Build and wants to inject a secret API key into a build step without exposing it in the cloudbuild.yaml. Which approach should they use?

A.Use `secretEnv` to reference a Secret Manager secret

B.Store the key in a Cloud Build substitution variable

C.Pass the key via `args` with a substitution

D.Store the key in a Cloud Storage bucket and download it in the build

AnswerA

Correct: `secretEnv` injects secrets securely.

Why this answer

Option A is correct because Cloud Build's `secretEnv` field allows you to reference a secret stored in Secret Manager and inject it as an environment variable into a build step. This approach ensures the secret value is never exposed in the `cloudbuild.yaml` file or build logs, as Cloud Build retrieves it securely at runtime using the Secret Manager API.

Exam trap

The trap here is that candidates often confuse substitution variables with secure injection, not realizing that substitution variables are resolved and visible in logs, while `secretEnv` is specifically designed to keep secrets out of logs and configuration files.

How to eliminate wrong answers

Option B is wrong because Cloud Build substitution variables are defined in the `cloudbuild.yaml` or passed at build time, and their values are visible in the build logs and the YAML file, which defeats the purpose of keeping the API key secret. Option C is wrong because passing the key via `args` with a substitution still exposes the value in the build logs and the YAML file, as substitutions are resolved and logged. Option D is wrong because storing the key in a Cloud Storage bucket and downloading it in the build step would require the bucket to be publicly accessible or the build service account to have permissions, and the key could be exposed in the build logs or the bucket's access logs, plus it adds unnecessary complexity compared to using Secret Manager.

Practice this question →

65

MCQmedium

An engineer uses Cloud Build with a private pool to build an application that needs to connect to a Cloud SQL database. The build step fails with a connection timeout. What is the most likely cause?

A.The Cloud Build service account lacks permissions to connect to Cloud SQL

B.The database name is incorrect

C.The private pool is not peered with the VPC that contains the Cloud SQL instance

D.The Cloud SQL instance requires SSL

AnswerC

Without VPC peering, the build cannot reach Cloud SQL, causing timeout.

Why this answer

A private Cloud Build pool runs in a customer-managed VPC, so it must be peered with the VPC hosting the Cloud SQL instance to establish network connectivity. Without VPC peering, the build step cannot reach the Cloud SQL private IP, resulting in a connection timeout. This is the most likely cause because the error is a timeout, not an authentication or configuration issue.

Exam trap

Cisco often tests the distinction between network connectivity failures (timeouts) and authentication/configuration errors (access denied, SSL errors) to see if candidates understand that a timeout points to a routing or firewall issue, not a permissions or SQL syntax problem.

How to eliminate wrong answers

Option A is wrong because a connection timeout indicates the network path is blocked, not that the service account lacks permissions; permissions would cause an access denied error, not a timeout. Option B is wrong because an incorrect database name would produce a database-specific error (e.g., 'unknown database') from the SQL client, not a connection timeout. Option D is wrong because SSL enforcement would cause a TLS handshake failure or an SSL-specific error, not a generic timeout; the build step could still establish a TCP connection before the SSL negotiation fails.

Practice this question →

66

MCQmedium

A DevOps engineer wants to automatically trigger a Cloud Build pipeline when a pull request is opened against the main branch. The pipeline should run unit tests and provide results as a status check on the PR. Which type of trigger should they configure?

A.Pull request trigger

B.Scheduled trigger

C.Manual trigger

D.Push to branch trigger

AnswerA

Pull request triggers are designed for PR events and can report status checks.

Why this answer

A pull request trigger is the correct choice because it is specifically designed to initiate a Cloud Build pipeline in response to PR events, such as when a PR is opened or updated. This allows the pipeline to run unit tests and report results as a status check on the PR, providing immediate feedback to developers. The trigger can be configured to fire only for PRs targeting the main branch, ensuring the pipeline runs exactly when needed.

Exam trap

Cisco often tests the distinction between push-to-branch triggers and pull request triggers, where candidates mistakenly choose push triggers because they think 'opening a PR is like pushing to a branch,' but a PR event is a separate webhook that requires a dedicated trigger type.

How to eliminate wrong answers

Option B is wrong because a scheduled trigger runs the pipeline at fixed times (e.g., daily or hourly), not in response to a pull request event, so it cannot provide real-time status checks on a PR. Option C is wrong because a manual trigger requires a user to explicitly start the pipeline via the console or API, which defeats the goal of automatic triggering when a PR is opened. Option D is wrong because a push to branch trigger fires when commits are pushed directly to a branch, not when a pull request is opened; it would run tests on the branch itself but not tie results to a PR status check.

Practice this question →

67

Multi-Selectmedium

Which TWO options are valid ways to authenticate to Artifact Registry from a CI/CD pipeline? (Choose two.)

Select 2 answers

A.Configure Workload Identity federation for the CI provider

B.Use the Docker credential helper (gcloud auth configure-docker)

C.Set the GOOGLE_APPLICATION_CREDENTIALS environment variable to a service account key

D.Use gcloud auth login with user credentials

E.Use a service account JSON key in the pipeline

AnswersA, B

Workload Identity allows external workloads to impersonate a service account.

Why this answer

Workload Identity federation allows non-GCP CI systems to authenticate, and the Docker credential helper is used for Docker authentication.

Practice this question →

68

MCQhard

A team uses Cloud Build with a private pool to build a Docker image that requires access to a Cloud SQL instance. The build fails because the builder cannot connect to the database. The network configuration uses VPC Service Controls. What is the MOST likely cause and solution?

A.Cloud SQL requires public IP; change to public IP and allowlist the builder's IP.

B.The Cloud Build service account lacks the Cloud SQL Client role; grant the role.

C.The private pool is in a different region; move the pool or Cloud SQL to the same region.

D.The private pool is not peered with the VPC containing Cloud SQL; set up VPC peering.

AnswerD

Private pools require VPC peering to access resources in the same VPC.

Why this answer

The most likely cause is that the private pool's underlying VPC is not peered with the VPC that hosts the Cloud SQL instance. Cloud Build private pools run in a Google-managed VPC, and to access resources in your own VPC (such as Cloud SQL), you must establish VPC peering between the two. Without this peering, the builder cannot route traffic to the Cloud SQL instance, even if VPC Service Controls are configured correctly.

Exam trap

Cisco often tests the distinction between IAM permissions (who can connect) and network connectivity (how to reach the resource), leading candidates to mistakenly choose a missing IAM role when the actual issue is a missing VPC peering or network route.

How to eliminate wrong answers

Option A is wrong because Cloud SQL can use private IP (RFC 1918) when connected via VPC peering, and requiring public IP would defeat the purpose of VPC Service Controls; also, allowlisting a builder's IP is not applicable for private pools. Option B is wrong because the Cloud SQL Client role grants permission to connect to the instance, but if the network path is blocked (no peering), IAM permissions alone cannot establish connectivity. Option C is wrong because private pools and Cloud SQL instances can be in different regions as long as VPC peering is configured and global routing is enabled; region mismatch is not the root cause here.

Practice this question →

69

MCQhard

A team uses Cloud Build private pools to build Docker images that need access to on-premises resources via VPC peering. The build step fails with a 'connection refused' error. What is the most likely missing configuration?

A.The build step is using a wrong Docker image

B.The private pool does not have a route to the on-premises network

C.The Cloud Build service account lacks permissions to use the private pool

D.The on-premises firewall is blocking egress from GCP

AnswerB

Private pools use VPC networks; without proper routing (e.g., VPC peering or Cloud VPN), the on-premises network is unreachable.

Practice this question →

70

MCQeasy

A DevOps engineer wants to automatically trigger a Cloud Build pipeline whenever a pull request is created against the main branch of a repository. Which type of build trigger should they use?

A.Push to branch trigger

B.Pull request trigger

C.Scheduled trigger

D.Manual trigger

AnswerB

Pull request triggers are designed to fire when a PR is created or updated.

Why this answer

Option B is correct because a pull request trigger in Cloud Build is specifically designed to initiate a build when a pull request is created or updated against a target branch, such as main. This trigger type evaluates the PR event and automatically runs the pipeline, enabling validation of proposed changes before merging.

Exam trap

Cisco often tests the distinction between push triggers (which react to commits) and pull request triggers (which react to PR events), trapping candidates who confuse a push to a branch with the creation of a pull request.

How to eliminate wrong answers

Option A is wrong because a push to branch trigger fires on direct commits or merges to a branch, not on pull request creation events; it would run the build only after code is already pushed to main, missing the pre-merge validation. Option C is wrong because a scheduled trigger runs builds at specified times (e.g., cron-based), independent of any code changes or pull request events, so it cannot respond to PR creation. Option D is wrong because a manual trigger requires explicit user invocation via the console or API, providing no automation for PR-based events.

Practice this question →

71

MCQhard

An engineer needs to deploy an application to Cloud Run with a canary traffic split: 95% to the stable revision and 5% to a new revision. They also want to test the new revision with specific headers without affecting user traffic. Which approach meets these requirements?

A.Deploy the new revision with a tag and use traffic splitting with --to-revisions

B.Use Cloud Load Balancing with URL maps to route 5% of traffic

C.Deploy the new revision without any tag and use gcloud run services update-traffic

D.Use a separate Cloud Run service for the canary and split traffic via HTTP redirects

AnswerA

Deploy with a tag allows testing via the tag URL, and traffic splitting can route a percentage of traffic to the new revision.

Practice this question →

72

MCQhard

A company uses Argo CD on GKE for GitOps deployments. They want to ensure that when a developer pushes a change to a Kubernetes manifest, Argo CD automatically syncs the cluster. What must be configured?

A.Use a Cloud Build trigger to run `argocd app sync`

B.Configure a webhook in the git repository that notifies Argo CD of changes

C.Set the sync policy to Automatic with Prune

D.Enable Config Sync instead of Argo CD for automatic sync

AnswerB

Webhook triggers immediate sync.

Why this answer

Option B is correct because Argo CD can be configured to automatically sync a cluster when a developer pushes a change to a Kubernetes manifest by setting up a webhook in the Git repository. The webhook notifies Argo CD of the push event, triggering a sync operation without manual intervention or polling. This is the standard GitOps pattern for event-driven synchronization.

Exam trap

Cisco often tests the misconception that setting the sync policy to 'Automatic' alone enables real-time sync, but candidates must remember that automatic sync relies on polling (default 3 minutes) unless a webhook is configured for immediate notification.

How to eliminate wrong answers

Option A is wrong because using a Cloud Build trigger to run `argocd app sync` introduces an unnecessary external CI step that bypasses Argo CD's native webhook mechanism, adding latency and complexity. Option C is wrong because setting the sync policy to Automatic with Prune only enables periodic polling (default 3 minutes) or manual sync, not real-time event-driven sync from a Git push. Option D is wrong because Config Sync is a separate Google Cloud tool for GitOps on GKE, not a configuration within Argo CD, and the question specifically asks about using Argo CD.

Practice this question →

73

MCQeasy

An engineering team wants to automatically build a Docker image every time a developer pushes code to the main branch of their GitHub repository. They are using Cloud Build. Which configuration should they use?

A.Cloud Build trigger with manual invocation

B.Cloud Build trigger with push event and branch pattern 'main'

C.Cloud Build trigger with scheduled event

D.Cloud Build trigger with pull request event

AnswerB

This is the correct way to trigger builds on push to main branch.

Why this answer

Cloud Build build triggers can be configured to respond to push events on a branch. The trigger is created in the Cloud Console or via gcloud and specifies the repository and branch pattern.

Practice this question →

74

MCQeasy

An engineer wants to trigger a Cloud Build pipeline whenever a new pull request(PR) is opened against the 'main' branch of a repository. Which type of build trigger should they configure?

A.Pull Request trigger

B.Manual trigger

C.Scheduled trigger (cron)

D.Push trigger on branch

AnswerA

Pull Request triggers automatically run builds when a PR is created or updated.

Why this answer

Cloud Build supports pull request triggers that automatically run a build when a PR is created or updated. This is specifically called a 'Pull Request' trigger.

Practice this question →

75

MCQhard

A company uses Cloud Build to build a multi-module Maven project. They want to run unit tests for module A and integration tests for module B in parallel. In cloudbuild.yaml, how should they configure the steps to run in parallel?

A.steps: - id: 'unit' waitFor: ['-'] ... - id: 'integration' waitFor: ['-'] ...

B.steps: - id: 'unit' ... - id: 'integration' waitFor: ['-'] ...

C.steps: - id: 'unit' waitFor: ['previous'] ... - id: 'integration' waitFor: ['unit'] ...

D.Steps run sequentially by default; parallelism is not supported.

AnswerA

Both steps with waitFor: ['-'] start simultaneously (parallel).

Why this answer

Option A is correct because in Cloud Build, setting `waitFor: ['-']` on a step makes it start immediately without waiting for any other step, effectively allowing both the 'unit' and 'integration' steps to run in parallel. This configuration meets the requirement to run unit tests for module A and integration tests for module B concurrently.

Exam trap

Cisco often tests the misconception that Cloud Build does not support parallelism or that `waitFor: ['-']` is only for the first step, leading candidates to choose sequential execution options or invalid syntax like `waitFor: ['previous']`.

How to eliminate wrong answers

Option B is wrong because the 'unit' step does not have `waitFor: ['-']`, so it will wait for the default previous step (if any) or run sequentially, preventing true parallelism. Option C is wrong because `waitFor: ['previous']` is not a valid Cloud Build syntax; the correct way to reference the previous step is by its ID, and here the 'integration' step waits for 'unit', forcing sequential execution. Option D is wrong because Cloud Build does support parallel execution by using `waitFor: ['-']` on multiple steps, so the claim that parallelism is not supported is incorrect.

Practice this question →

Page 1 of 2 · 135 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Pcde Cicd Pipelines questions.

Start 20-question session