Prepare and test your skills
Prepare and test your skills
Free sample question, answered and explained below. The Professional Cloud DevOps Engineer practice bank has 1,455 more like it. Try 10 free: instant score, no account.
A DevOps engineering team is designing a continuous delivery architecture using Google Cloud Build, Google Cloud Deploy, and Google Kubernetes Engine (GKE). The application requires distinct manifest configurations across development, staging, and production environments using Kustomize.
The pipeline must satisfy the following technical requirements:
skaffold.yaml configuration file for both local development and remote CI/CD execution.Which configuration and workflow strategy should the team implement?
deploy.helm. In Cloud Build, execute skaffold render --output=rendered.yaml and pass --manifests=rendered.yaml to gcloud deploy releases create.This approach configures dynamic Skaffold modules to partition deployment definitions and attempts to pre-render the entire Kubernetes manifest in Cloud Build, uploading the static hydrated YAML directly to Cloud Deploy via a --manifests flag.
--manifests flag during release creation. Instead, Cloud Deploy requires the rendering source files and image references so its internal execution environment can execute skaffold render per stage.The organization used an external continuous delivery engine that required static, pre-hydrated Kubernetes manifests pushed directly into a GitOps repository.
skaffold.yaml with lifecycle hooks under each profile to invoke kustomize edit set image. In Cloud Build, execute standard docker build commands and specify individual image URIs using the --images flag during gcloud deploy releases create.This approach attempts to use Skaffold lifecycle hooks within target profiles to dynamically mutate local kustomization.yaml files via kustomize edit set image before pushing builds with standard Docker CLI commands.
kustomize edit inside CI jobs mutates source files in place, leading to non-reproducible builds and configuration drift between environments.--images is error-prone for multi-artifact builds compared to automated --build-artifacts JSON metadata exchange.The pipeline relied solely on custom shell scripts within a bespoke Jenkins or GitLab runner that manipulated raw files directly without using Cloud Deploy's managed rendering engine.
skaffold.yaml with artifact definitions and environment-specific profiles referencing Kustomize paths. In Cloud Build, run skaffold build with --file-output=artifacts.json --push=true --default-repo=[REPO], and pass --build-artifacts=artifacts.json to gcloud deploy releases create.This solution orchestrates a seamless continuous delivery workflow by coupling Skaffold artifact management and environment profiles directly with Google Cloud Deploy release management. Skaffold serves as the declarative configuration layer that bridges local developer workflows and automated cloud delivery pipelines.
skaffold.yaml containing root artifact configurations and target-specific profiles allows developers to test locally with skaffold dev or skaffold run while Cloud Deploy invokes the defined profiles during pipeline progression.skaffold build with the --file-output=artifacts.json flag produces a structured metadata file capturing the exact image repository tags and immutable sha256 digests published to Artifact Registry.--build-artifacts=artifacts.json into gcloud deploy releases create enables Cloud Deploy (via internal Cloud Build execution) to run skaffold render and swap placeholder image references across all target profiles deterministically.sed or kustomize edit in CI jobs.This architecture represents the native Google Cloud best practice for continuous delivery. It allows Cloud Deploy to manage release progression and target rendering through standard Skaffold CLI contracts without requiring custom synchronization scripts or fragile intermediate storage steps.
skaffold.yaml with deploy.kustomize and set the build execution to googleCloudBuild. In Cloud Build, run skaffold apply --offline=true and upload the resulting manifests to a Cloud Storage bucket linked to Cloud Deploy.This strategy attempts to invoke skaffold apply with an --offline=true flag within the CI build step to output rendered manifests into a Google Cloud Storage bucket, intending for Cloud Deploy to read pre-applied configurations.
skaffold apply is designed to deploy already-rendered manifests directly to an active Kubernetes cluster using kubectl. It does not support an --offline=true flag for generating rendered output (that functionality belongs to skaffold render).skaffold apply inside its own worker pool when a rollout is promoted to a target. Injecting raw output into Cloud Storage bypasses Cloud Deploy's release progression model.manifests.kustomize rather than within deploy.kustomize.skaffold apply in a CI environment without cluster credentials will fail.You were using a custom continuous integration script that directly managed cluster deployment without leveraging Google Cloud Deploy.
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
Keep the momentum going with these hand-picked practice scenarios
Last updated Validated